Cross-Site Request Forgery

The one-line contrast to remember: XSS runs the attacker's code on your site; CSRF makes your browser send a request to your site. XSS is more powerful (it can do everything, including stealing the token and reading data), which is why a site with XSS is in deeper trouble; CSRF is narrower (state-changing actions only) but needs no flaw in the target, only that the target relies on the cookie alone to authenticate a request.

The defences

CSRF is defeated by making an authenticated request require something the attacker's site cannot supply, beyond the automatically-attached cookie.

Anti-forgery tokens (CSRF tokens). The primary defence. The target site includes, in each form or state-changing request, a secret token that is unique to the user's session and unpredictable, and it checks that the token is present and correct before acting. The attacker's site, being on a different origin, cannot read this token (same-origin protections again), so it cannot include it in the forged request, which is therefore rejected. The token is not the session cookie; it is an additional secret that must accompany state-changing requests, and it defeats CSRF because the attacker cannot know it.

SameSite cookies. The attribute from the previous chapter. If the session cookie is set to a restrictive SameSite, the browser does not attach it to cross-site requests, so the forged request arrives without the session cookie and is not authenticated. This closes the attack at the browser level, and modern browsers defaulting to a restrictive SameSite has substantially reduced CSRF's prevalence. It is a strong defence, and combined with anti-forgery tokens it provides defence in depth.

Additional measures:

• Requiring re-authentication or confirmation for the most sensitive actions (re-enter the password to change email or transfer above a threshold), so an automatic request alone cannot perform them.
• Checking the request's origin where reliable, to confirm it came from the site's own pages.
• Not performing state-changing actions on simple requests that are easy to forge, using methods and request shapes that browsers restrict for cross-site use.

The combination to recommend: SameSite cookies plus anti-forgery tokens on all state-changing requests, with re-authentication for the most sensitive, which closes the attack at the browser and at the application.

A worked example, framed defensively

An assessor reviews an application for CSRF, using a test account.

• A change-email action is performed by a simple state-changing request, with no anti-forgery token and the session cookie having no SameSite restriction. Finding: CSRF vulnerability on a sensitive action; a malicious page could change a logged-in victim's email, then trigger a password reset to it. Fix: add anti-forgery tokens and set a restrictive SameSite.
• A funds-transfer action requires an anti-forgery token. Recorded as correctly defended: a forged request lacks the token and is rejected.
• The most sensitive actions do not require re-authentication. Recommendation: add it for changing email and for large transfers, as defence in depth.
• The assessor verifies the fix by confirming that a cross-site request without the token, and (with SameSite set) without the cookie, is rejected.

The report explains the distinction from XSS explicitly, because the client asked "isn't this the same as the scripting issue?", and the answer, that CSRF causes an action without reading the response and needs no flaw in the target, only reliance on the cookie alone, is exactly the distinction this chapter teaches.

What beginners get wrong

• Confusing CSRF with XSS. XSS runs the attacker's script on the target site (and can do anything, including read data and steal the token); CSRF makes the browser send a request to the target site and cannot read the response.
• Thinking the attacker steals the token. They do not; they exploit that the browser attaches the cookie automatically, so the request is authenticated without the attacker knowing the token.
• Believing the attacker reads the response. They cannot, because same-origin protections prevent their site reading it; CSRF is for state-changing actions, not data theft.
• Assuming a target flaw is needed. CSRF needs no flaw in the target beyond authenticating a request on the cookie alone; it exploits normal browser behaviour.
• Relying on SameSite alone or tokens alone. Use both for defence in depth, plus re-authentication for the most sensitive actions.
• Performing sensitive actions on easily-forged simple requests. Require an unpredictable token the attacker's site cannot read.

Quick revision

• CSRF: a malicious site causes a logged-in victim's browser to send a state-changing request to the target site; the browser automatically attaches the session cookie, so the request is authenticated and processed as intended.
• The attacker does not know the token and cannot read the response (same-origin protections), so CSRF is for state-changing actions, not data theft.
• Against XSS: XSS runs the attacker's script on your site (powerful: reads data, steals the token); CSRF makes your browser send a request to your site (narrower: causes an action). XSS needs a target flaw; CSRF needs only reliance on the cookie alone.
• Defences: anti-forgery tokens (an unpredictable per-session secret the attacker's site cannot read, required on state-changing requests) and SameSite cookies (the cookie is not sent cross-site), plus re-authentication for sensitive actions and origin checks. Use tokens and SameSite together.

Test yourself

1. Explain the mechanism of cross-site request forgery.

A logged-in victim's browser holds a valid session cookie for a target site. The victim visits a malicious page that causes their browser to send a state-changing request to the target site; because the request goes to that site, the browser automatically attaches the session cookie, so the request arrives authenticated and the target processes it as though the victim intended it. The attacker thereby causes an action on the victim's account without knowing the session token.

1. Why can CSRF change state but not read data?

Because although the browser sends the forged request with the cookie and receives the response, the attacker's page is on a different origin and the browser's same-origin protections prevent it from reading that response. So the attacker can cause an action, such as a transfer or a settings change, where causing it is the goal, but cannot see returned data, which is why CSRF targets state-changing actions rather than data theft.

1. Distinguish cross-site request forgery from cross-site scripting.

Cross-site scripting runs the attacker's script on the target site in the victim's browser, giving full control on the page including reading the response, stealing the token and reading data, and it requires an XSS flaw in the target. Cross-site request forgery makes the victim's browser send a request to the target site and cannot read the response, so it only causes state-changing actions, and it needs no flaw in the target beyond the target authenticating requests on the session cookie alone.

1. How does an anti-forgery token defeat CSRF?

The target site includes in each state-changing request a secret token unique to the user's session and unpredictable, and requires it to be present and correct before acting. The attacker's site, being on a different origin, cannot read this token because of same-origin protections, so it cannot include it in a forged request, which is therefore rejected even though the session cookie was attached automatically.

1. How does the SameSite cookie attribute mitigate CSRF, and why combine it with tokens?

A restrictive SameSite attribute causes the browser not to attach the session cookie to cross-site requests, so a request forged by another site arrives without the cookie and is not authenticated, defeating the attack at the browser level. It is combined with anti-forgery tokens for defence in depth, so that the attack is blocked both at the browser, by withholding the cookie, and at the application, by requiring a token the attacker cannot supply, in case either measure is absent or bypassed in some context.