Understanding CSRF Attacks: How They Work and How to Defend Against Them

What Is a CSRF Attack?

Cross‑Site Request Forgery (CSRF) enables an attacker to forge a request that the victim’s browser submits to a web application using the victim’s credentials (e.g., cookies), even across origins.

CSRF Background

Web browsers originally served static documents; later they added interactivity with HTML elements such as <form> and support for cookies to maintain state.

CSRF exploits three web properties: cookies store credentials, HTML elements can issue cross‑origin requests, and browsers automatically attach all cookies to every request.

An attacker creates a malicious site containing HTML elements that submit requests to the victim’s target site. When the victim visits the malicious site, the browser attaches the victim’s cookies, making the forged request appear legitimate.

How It Works

It only succeeds when the potential victim is authenticated.

The attacker can bypass the authentication process by forcing the victim’s browser to send a forged request.

CSRF is useful when the victim has privileges the attacker lacks, such as online banking operations.

Two Main Steps of a CSRF Attack

Step 1: Lure the user to click a link or load a malicious page, often via social engineering.

Step 2: The malicious page sends a forged request to the target site, appearing legitimate because the browser includes the victim’s cookies.

Key Concepts

The attacker sends a malicious request to a site where the victim is already authenticated.

The victim’s browser automatically includes authentication cookies with the request.

The vulnerable site, not the victim’s browser, is the primary point of failure.

How to Prevent CSRF

Common mitigation techniques include:

Log out of web applications when not in use.

Protect usernames and passwords.

Avoid saving passwords in the browser.

Do not browse while authenticated to sensitive applications.

Anti‑CSRF Token

The most widely used defense is to embed a random token tied to the user session in hidden form fields and also send it as a cookie.

1. CSRF Token Workflow

The client requests an HTML page containing a form.

The server generates two random tokens: one stored in a cookie, the other placed in a hidden form field.

When the form is submitted, both tokens are sent back; the server verifies that they match.

If either token is missing or mismatched, the request is rejected.

2. SameSite Cookie

Setting the SameSite attribute on cookies instructs browsers not to send the cookie on cross‑origin requests, thereby blocking many CSRF attempts.

3. SameSite Cookie Limitations

Modern browsers support the attribute, but older browsers may not, limiting its effectiveness for some users.

CSRF Example

Assume a banking site banking.com performs sensitive actions via GET requests. An attacker can embed an image tag that silently triggers the request:

<img src="http://banking.com/app/transferFunds?amount=2500&destination=56789">

Other techniques include sending malicious HTML emails or injecting scripts that auto‑submit forms using POST requests; POST does not inherently prevent CSRF because attackers can create auto‑submitting forms.

Conclusion

Cookies are automatically sent with every request, making them easy targets for CSRF attacks. The impact depends on the victim’s privileges, and the attacker’s request carries the victim’s cookies.

Although data retrieval is not the primary goal of CSRF, state‑changing actions can have severe consequences, so implementing the discussed prevention methods is strongly recommended.