Topic 33

CSRF and SSRF

CSRF / SSRF

Two request-forgery flaws share a name and nothing else. CSRF tricks a logged-in user's browser into sending an unwanted request to a site that trusts the user's cookie; SSRF tricks the server into making a request to somewhere it should not, often reaching internal systems the attacker cannot. Both exploit misplaced trust in where a request came from, and each has a distinct defense.

This topic covers each attack against app.meridian.example and api.meridian.example — because despite the rhyming names, they have different victims and different fixes.

CSRF — Abusing the User's Session

Because browsers automatically attach cookies to requests, a malicious page can make the victim's browser POST to Meridian while the victim is logged in — and the server sees a valid session and performs the action. The attack rides the user's authenticated trust: the request is genuinely from the user's browser, just not from the user's intent.

Defending Against CSRF

The defenses are anti-CSRF tokens — a per-session secret the attacker's page cannot know — the SameSite cookie attribute, which stops cross-site cookie attachment, and checking the Origin and Referer headers. Modern SameSite=Lax defaults blunt CSRF considerably, but they do not fully replace tokens for sensitive state-changing actions.

SSRF — Abusing the Server's Trust

When the app fetches a URL the user supplies — a webhook, an image proxy, a link preview, a PDF renderer — an attacker points it at internal addresses the server can reach and they cannot: internal admin services, or the cloud metadata endpoint at 169.254.169.254. The server, trusted inside the network, dutifully retrieves it. SSRF has become a top cloud-breach vector precisely because that metadata endpoint hands out the instance's credentials.

Defending Against SSRF

Allow-list the destinations the server may fetch, block internal and link-local ranges and the metadata endpoint, resolve-and-validate the address before connecting (to defeat DNS rebinding), and isolate the fetching component so a successful SSRF reaches as little as possible. In the cloud, use hardened metadata (IMDSv2-style) so SSRF cannot trivially lift instance credentials (Chapter 13).

CSRF vs SSRF

CSRF — the client's browser is tricked into a request to your server; it exploits cookie-based trust in the user, and is fixed with tokens and SameSite.

SSRF — your server is tricked into a request to an attacker-chosen, often internal destination; it exploits the network's trust of the server, and is fixed with destination allow-lists and metadata blocking. Different victim, different fix.

Common Mistakes

Protecting state-changing actions with cookies alone and no CSRF token or SameSite, so any site can trigger them in a logged-in user.
Assuming SameSite=Lax fully solves CSRF, when some flows and top-level navigations still need tokens for sensitive actions.
Fetching user-supplied URLs without restriction, letting SSRF reach cloud metadata and internal services — a direct path to cloud credential theft.
Validating the URL once but being defeated by redirects or DNS rebinding, because the check and the connection use different resolutions.
Running the URL-fetching feature with the app's full network access and credentials.

Best Practices

Use anti-CSRF tokens for state-changing requests and set SameSite on session cookies; never change state on a GET.
For any server-side fetch, allow-list destinations, block link-local and internal ranges and cloud metadata, and validate after final DNS resolution.
Isolate URL-fetching features — separate egress, no credentials — so a successful SSRF reaches as little as possible.
In the cloud, use hardened metadata endpoints (IMDSv2-style) so SSRF cannot lift instance credentials (Chapter 13).
Check Origin or Referer on sensitive requests as an added CSRF layer.

Comparable toolsCSRF framework CSRF middleware · SameSite · Origin checksSSRF egress allow-lists · IMDSv2 · metadata blockingReference OWASP CSRF & SSRF cheat sheets — Ch 13 metadata

Knowledge Check

What is the key difference between CSRF and SSRF?

CSRF tricks the browser; SSRF tricks the server
They are two names for the same attack
CSRF targets the database; SSRF targets the CPU
CSRF only works over HTTP and SSRF only over HTTPS

Why is SSRF such a dangerous vector in cloud environments?

It can point the server at the metadata endpoint for credentials
It lets the attacker read the user's browser cookies and local storage
It automatically encrypts the attacker's traffic
It only affects on-premises servers, never cloud

What actually defends against SSRF reaching internal services?

Allow-listing destinations and blocking internal ranges
An anti-CSRF token attached to every outbound fetch request
Setting SameSite on the session cookie
Encoding the fetched response as HTML

You got correct