How CSRF Attacks Exploit Cookies and How to Defend Against Them

CSRF Attack Overview

Cross‑Site Request Forgery (CSRF) exploits the fact that browsers automatically include authentication cookies when a user visits a target site. An attacker hosts a malicious page on a different origin, embeds a request (e.g., a password‑change URL) that the victim’s browser will send with the victim’s valid session cookie, and tricks the victim into triggering the request.

Typical CSRF Attack Flow

The victim logs in to the target application (WEB A). The server issues a session cookie (either a memory‑only session cookie or a persistent third‑party cookie).

The attacker controls a second site (WEB B) and places a hidden form, button, image, or hyperlink that points to a privileged endpoint on WEB A (for example https://web-a.example.com/account/password with the new password as a POST parameter).

Through social engineering (e.g., a convincing message), the victim clicks the malicious element. The browser automatically attaches the stored cookie to the request sent to WEB A.

WEB A validates the cookie, assumes the request originates from the authenticated user, and processes the action without requiring additional confirmation, such as re‑entering the password or a CSRF token.

The victim’s password is changed, locking the original account.

Conditions Required for a Successful CSRF

The victim has an active authenticated session and a valid cookie for the target site.

The targeted request does not require extra authentication (e.g., a one‑time token, CAPTCHA, or password re‑entry).

The attacker knows the exact request method, endpoint, and required parameters.

The victim is induced to issue the request (typically via social engineering).

Server‑Side Request Forgery (SSRF) Overview

SSRF is a related class of attack where the vulnerable server, not the client, is forced to make HTTP requests to internal resources. The attacker supplies a URL (often through an image‑fetch or file‑upload feature). If the server does not properly validate the URL, it will fetch the attacker‑controlled address, potentially exposing internal services, metadata, or allowing command execution.

Typical SSRF Attack Flow

The attacker discovers that a server accepts a user‑supplied URL (e.g., https://vulnerable.example.com/fetch?url=).

The attacker supplies an internal address such as http://127.0.0.1:8080/admin or a file:// URL.

The server resolves the URL, makes the request from its own network, and returns the response to the attacker.

Conditions Required for a Successful SSRF

The attacker knows an internal address reachable from the vulnerable server.

The server does not adequately filter, whitelist, or restrict the supplied URL.

Mitigation Strategies

Parse incoming URLs, resolve them to IP addresses, and reject any that fall within private‑network ranges (e.g., 10.0.0.0/8, 192.168.0.0/16, 127.0.0.0/8) using regular expressions or IP‑range checks.

Maintain a strict whitelist of allowed external domains and reject all others.

Implement a blacklist of internal IPs or CIDR blocks to explicitly deny requests to those addresses.

Filter or sanitize response bodies before forwarding them to the client to avoid leaking sensitive data.

Restrict allowed URL schemes to safe protocols (http, https) and block dangerous schemes such as file://, gopher://, ftp://, etc.

For CSRF specifically, embed anti‑CSRF tokens in state‑changing forms, enforce SameSite cookie attributes, and require re‑authentication for critical actions.