CSRF, SSRF, and Request Forgery

CAP, ACID vs BASE, latency numbers, back-of-envelope estimation, single points of failure — the vocabulary every system designer thinks in.

Core Philosophy: Some attacks don’t break into a system — they trick something trusted into acting on the attacker’s behalf. Request forgery is exactly this: making a request that appears legitimate because it comes from a trusted source. Two cousins share the idea — CSRF tricks a victim’s browser into sending a request, SSRF tricks a server into sending one. They sound alike, are constantly confused, and are genuinely different. This page makes the difference clear.

Part 1: The Problem

A request is trusted based on where it comes from. A request from a logged-in user’s browser carries their session and is treated as their legitimate action. A request from inside a company’s own server is treated as trusted internal traffic.

Request forgery attacks abuse those trust assumptions. Instead of stealing credentials or exploiting a parsing bug, the attacker arranges for a trusted entity — the victim’s browser, or the application’s own server — to make a request the attacker wants. The request looks legitimate because, mechanically, it is coming from the trusted source. This section covers the two main forms.

Part 2: CSRF — Cross-Site Request Forgery

The trick: make a victim’s browser send a request to a site where the victim is logged in, performing an action the victim never intended.

The setup that makes CSRF possible: recall from 0.3 that a browser automatically attaches the relevant cookies — including the session cookie — to every request to a site. The browser does this no matter what caused the request. So if an attacker can cause the victim’s browser to fire a request at a target site, that request rides along with the victim’s session and looks completely authentic.

   1. Victim is logged in to bank.com (has an active session).
   2. Victim visits the attacker's page (or opens a crafted
      email/link) while still logged in.
   3. The attacker's page silently makes the victim's browser
      send a request to bank.com — e.g. a funds transfer.
   4. The browser AUTOMATICALLY attaches the victim's bank.com
      session cookie.
   5. bank.com sees a properly-authenticated request and
      performs the action — a transfer the victim never made.

The victim has authentication; CSRF abuses it. The attacker never sees the victim’s password or session — they don’t need to. They just need the victim’s browser to fire the request while the victim is logged in.

Impact: any state-changing action the victim is allowed to do — change their email or password, transfer funds, make a purchase, change settings — can be triggered without consent.

The defenses (built in Phase 4.2):

• CSRF tokens. The app includes a secret, unpredictable, per-session token in its own legitimate forms and verifies it on submission. The attacker’s forged request can’t include a token it doesn’t know, so it’s rejected. This is the primary defense.
• SameSite cookies. A cookie setting telling the browser not to attach the cookie on requests originating from other sites — directly undercutting the CSRF mechanism.
• Re-authentication or confirmation for sensitive actions.

Part 3: SSRF — Server-Side Request Forgery

The trick: make the application’s own server send a request to somewhere the attacker chooses.

Many applications fetch URLs as part of their normal work — loading an image from a URL you give, fetching a webhook, importing data from a link, generating a preview of a link. If the app takes a user-supplied URL and the server goes and requests it, an attacker can supply a URL pointing somewhere they should never be able to reach.

Why that’s powerful: the server often sits inside a trusted network, behind the firewall. The attacker, out on the internet, cannot reach those internal systems — but the server can. SSRF turns the server into a proxy, letting the attacker reach internal-only targets through it.

   The attacker cannot reach internal systems directly:

   Attacker ──✗──► [firewall] ──► internal services

   But with SSRF, the attacker tells the SERVER what to fetch:

   Attacker ──► "fetch this URL" ──► Web Server
                                         │  (the server is
                                         │   trusted & inside)
                                         ▼
                                  internal-only services,
                                  cloud metadata endpoints,
                                  other internal hosts

What SSRF can reach:

• Internal services never meant to be exposed — internal admin panels, databases, dashboards.
• Cloud metadata endpoints. Cloud servers expose an internal-only address holding configuration and, dangerously, credentials. SSRF reaching it has caused major real-world cloud breaches. (This connects directly to Phase 5C, cloud security.)
• Port scanning the internal network — using the server’s responses/timing to map what’s inside.

SSRF is rated severe and has climbed the OWASP Top 10 precisely because modern cloud architectures make its impact so high.

The defenses (built in Phase 4.2):

• Validate and restrict destination URLs — allow only known, intended destinations (an allowlist), not arbitrary user-supplied ones.
• Block requests to internal address ranges and metadata endpoints.
• Network-layer segmentation so the server itself can’t reach sensitive internal systems it has no need to reach (defense in depth — Phase 4.3/4.4).

Part 4: CSRF vs SSRF — Settling the Confusion

The names are similar; the attacks are not. Lock in the difference:

One memory hook: CSRF → the Client (browser) is tricked. SSRF → the Server is tricked. Same idea — forge a request from a trusted source — different trusted source.

Part 5: The Wider Family — Forgery and Trust

CSRF and SSRF are the two you must know cold, but the pattern — abusing trust in the origin of a request — shows up more widely. Briefly, so you recognize the family:

• Open redirects. An app that redirects users to a URL taken from a parameter, without validation, can be abused to send victims to attacker sites under the trusted app’s name — useful for phishing. Minor alone; often a building block.
• Host-header attacks. Some apps trust the Host header (which the attacker controls) to build links or make decisions — you met one example in 2.6’s password-reset poisoning.
• Webhook and callback abuse. Features that call out to user-configured URLs can shade into SSRF.

The unifying lesson — and the bridge to defense: trust must be based on verification, not on appearance. “This request came from the user’s browser” or “this request came from our server” is an appearance of legitimacy. CSRF tokens, URL allowlists, and validating untrusted headers all replace assumed trust with verified trust. That principle — verify, don’t assume — runs through the entire defensive half of the curriculum.

Part 6: Finding Request Forgery

How you test for each:

Finding CSRF:

1. Find STATE-CHANGING actions (change email, transfer,
      update settings) — CSRF only matters for actions that
      DO something.
2. Inspect the request. Does it include an unpredictable
      anti-CSRF token? Is SameSite set on the cookie?
3. If there's no token (or the token isn't validated, or
      it's predictable/reusable), the action may be forgeable.
4. Confirm by crafting a test request from a different
      origin — see if it succeeds.

Finding SSRF:

1. Find features where the SERVER fetches a URL — image-from-
      URL, link previews, webhooks, imports, PDF generators.
2. Supply a URL you control and confirm the SERVER (not your
      browser) makes the request.
3. Test whether you can point it at internal addresses or
      the cloud metadata endpoint.
4. Assess impact carefully and responsibly.

⚖️ Ethics. For CSRF, test against your own lab accounts — don’t perform real unwanted actions on real users. For SSRF, demonstrating that the server fetches an attacker-chosen URL is usually enough to prove the bug; do not use it to actually pull cloud credentials or rummage through a real internal network — that’s a severe crime even on an in-scope program. As always: prove it, don’t exploit it. Page 1.0 governs.

📓 Key Terms

🧪 Hands-On Lab

Only on your own lab or deliberately vulnerable practice apps.

Task 1 — Perform a CSRF attack. On a deliberately vulnerable app, find a state-changing action with no CSRF protection. Craft a simple page or request that triggers that action using your own logged-in lab session. Watch the action happen “as you” without you using the real form.

Task 2 — See a CSRF token defend. Find an app (or app feature) that does use CSRF tokens. Capture a legitimate request in Burp and note the token. Try to replay the request without it, or with a wrong token. See it rejected. That’s the Part 2 defense working.

Task 3 — Inspect SameSite. In your browser dev tools, examine cookies on various sites and look at the SameSite attribute. Connect what you see to how it limits CSRF.

Task 4 — Perform an SSRF attack. On a deliberately vulnerable app, find a feature where the server fetches a URL. Supply a URL you control (or an internal-style address the lab exposes) and confirm the server made the request, not your browser.

Task 5 — Reach the “internal” via SSRF. In a lab designed for it, use SSRF to reach a service that’s only reachable from the server side. Experience how SSRF turns the server into a proxy into places you can’t otherwise reach.

Task 6 — Explain the difference. Write, in your own words, the difference between CSRF and SSRF — who is tricked, whose trust is abused, what the attacker gains. If you can explain it clearly, you’ve beaten the most common confusion in this topic.

⚠️ Common Mistakes

• Confusing CSRF and SSRF. CSRF tricks the client/browser; SSRF tricks the server. Different attacks, different defenses. Know which is which.
• Thinking CSRF matters for read-only actions. CSRF is about state-changing actions. Forging a request that just views a page achieves little.
• Underrating SSRF. “The server fetched a URL” sounds harmless until that URL is the cloud metadata endpoint handing over credentials. In cloud environments SSRF is critical.
• Weaponizing SSRF on real targets. Demonstrate the server fetches your URL; do not pull real credentials or explore a real internal network. That’s a severe crime, in-scope or not.
• Believing obscure URLs/IDs stop SSRF or CSRF. The fixes are real controls — tokens, allowlists, segmentation — not hard-to-guess values.

✅ Recap & What’s Next

• Request forgery abuses the trust placed in where a request comes from — making a trusted entity act for the attacker.
• CSRF tricks a victim’s browser into sending an authenticated request (defended by CSRF tokens and SameSite cookies); SSRF tricks the server into making a request (defended by URL allowlisting and blocking internal ranges).
• The unifying principle, and the bridge to Phase 4: trust must be verified, not assumed.

Next (2.9): Many breaches need no clever exploit at all — just a default password, an exposed file, or a careless setting. We turn to security misconfiguration, the unglamorous category behind a huge share of real incidents.