How CSRF Attacks Exploit Trusted Sessions and How to Defend Them

This article explains the principle and step‑by‑step flow of Cross‑Site Request Forgery attacks, illustrates common exploitation techniques such as forged GET/POST requests and click‑bait links, and outlines practical defenses including POST usage, HttpOnly cookies, CSRF tokens, and double‑submit cookie validation.

Lobster Programming
Lobster Programming
Lobster Programming
How CSRF Attacks Exploit Trusted Sessions and How to Defend Them

What is CSRF?

Cross‑Site Request Forgery (CSRF, also called XSRF) is an attack that tricks a user who is logged into a trusted site into performing unintended actions on that site.

Attack Principle

When a user authenticates, the server issues a session identifier that the browser stores in a cookie. Any other tab or window opened in the same browser can read that cookie and automatically include it in subsequent requests to the same origin. An attacker can cause the victim’s browser to send a request that carries the valid session cookie, thereby acting as the victim.

Typical Attack Flow

User A logs into a banking site and keeps the session active.

The bank implements a money‑transfer operation via a GET request, e.g.

www.longxia.com/transfer?accountName=10000&money=100

An attacker crafts a malicious image URL that performs a transfer to the attacker’s account, e.g.

www.longxia.com/transfer?accountName=10001&money=10000

User A opens the phishing email in another tab and clicks the image (or the image loads automatically). The browser sends the request together with the valid session cookie, causing the bank to transfer the money to the attacker.

CSRF attack flow diagram
CSRF attack flow diagram

Common CSRF Techniques

Forged GET request : embed a malicious <img> tag whose src points to the target URL. The browser loads the image and automatically sends the request.

Forged POST request : create a hidden HTML form that auto‑submits (e.g., via JavaScript form.submit()) when the victim visits the attacker‑controlled page.

Click‑bait link : send a short URL in email or chat; when the victim clicks it, the browser follows the link and issues the request.

Defensive Measures

Defenses aim to make state‑changing requests unpredictable and impossible to forge.

Prefer POST over GET for any operation that changes server state. POST parameters are not transmitted by simply loading an image or following a link.

Set the HttpOnly flag on cookies so that client‑side scripts cannot read them. Example in Node.js:

response.setHeader('Set-Cookie', 'sessionId=abc123; HttpOnly');

CSRF token : the server generates a cryptographically random token per session, embeds it in HTML forms (as a hidden field) or in a custom request header (e.g., X‑CSRF‑Token), and validates the token on every state‑changing request. Frameworks such as Spring Security provide built‑in support.

Double‑submit cookie pattern : the server sends a cookie containing a random value and also requires the same value to be sent as a request parameter or header. Because the attacker’s site cannot read the cookie (same‑origin policy), it cannot reproduce the matching value.

Summary

CSRF exploits the trust relationship between a user's browser and a legitimate site by forcing the browser to send authenticated requests on the user's behalf. Mitigations focus on eliminating unsafe GET‑based state changes, protecting cookies with HttpOnly, and requiring unpredictable tokens (or double‑submit cookies) that the attacker cannot obtain.

CSRFdefenseTokenweb securityCross-Site Request Forgery
Lobster Programming
Written by

Lobster Programming

Sharing insights on technical analysis and exchange, making life better through technology.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.