CSRF: Cross-Site Request Forgery

The attacker starts by spotting a request that changes something on a service, then builds an address or a script that reproduces it with their own values. OWASP gives the example of a fictional bank: the legitimate request transfers 100 dollars to a beneficiary, and the attacker replaces the beneficiary with themselves and raises the amount¹.

What remains is to get the victim to load that request while logged in. Two methods are cited: an unsolicited e-mail with HTML content, or a trap placed on pages the victim is likely to visit while using their online service¹.

The attack can also be stored on the vulnerable site itself, for example in a field that accepts HTML. It then becomes more likely: the victim is more willing to view a page of the site than an arbitrary page on the Internet, and is necessarily already logged in there¹.

Often, nothing. The booby-trapped link can be disguised as an ordinary link, with text such as "see my photos". It can also take the form of a fake image of zero size: if it appears in an e-mail, the victim sees nothing, but the browser still sends the request, with no visual sign that the operation took place¹.

Neutralized illustration, not a real address.
Disguised link: displayed text "See my photos", hidden address
hxxp://banque[.]exemple[.]invalid/virement?dest=[attacker's account]&montant=[high]
Variant: invisible image in an e-mail, loaded without a click.

If the service expects a POST request, the attacker can host on their site a form with hidden fields. The victim believes it does something else and clicks, or else a script sends it automatically when the page loads¹. In both cases, the page displayed is ordinary and the action takes place elsewhere.

The mechanism rests on normal browser behavior. Browsers store the cookies issued by an application, including the session cookies of authenticated users, and they send all of a domain's cookies with every request, whatever way that request originated in the browser². Cookies are not the only thing at issue: Basic and Digest authentication are also vulnerable, because the browser automatically resends the credentials until the end of the session².

Several defense ideas do not work, according to OWASP¹:

• a secret cookie, since all cookies are sent with every request;
• accepting only POST requests, since a hidden form is enough to forge one;
• multi-step transactions, as long as the attacker can predict each step;
• checking the Referer header alone, because it can be forged, and it is sometimes absent for privacy reasons.

The recommended protections, on the application side, are as follows.

• First check whether the framework already offers CSRF protection, and use it. Failing that, add anti-CSRF tokens to all requests that change state and validate them on the server side³. Without a token, the attacker cannot build a valid request³.
• For stateless software, use a double-submit cookie, preferably signed³.
• Set the SameSite attribute on session cookies³. With the strict value, the browser does not send the cookie on cross-site requests, even when following an ordinary link. With lax, it sends it for a link followed from another site but withholds it on methods exposed to CSRF such as POST⁴. With none, no protection is offered⁴.
• Check the origin with standard headers, notably Sec-Fetch-Site, supported by all major browsers since March 2023³.
• Do not use GET requests for operations that change state³.

These measures have limits. SameSite=Lax lets top-level navigation GET requests through: an endpoint that changes state via GET remains vulnerable². Older browsers may not enforce SameSite². And an XSS flaw can bypass all anti-CSRF protections; the Samy worm, for example, used an XMLHttpRequest to obtain the CSRF token and forge requests¹³. The default behavior of SameSite varies: in December 2024, lax was the default in Chrome, Edge and Opera, but in no version of Firefox or Safari, hence the advice to set it explicitly⁴.

2008: the uTorrent exploit

OWASP cites, as a real example of a CSRF attack against an application working through GET requests, an exploit targeting uTorrent dating from 2008. It was used on a large scale to download malware¹. The source says no more: neither the number of victims nor the means of distribution.

Flaws cataloged by the CWE (identifiers from 2004 to 2009)

CWE-352 gives a selected list of observed examples, which is not exhaustive⁵. Several rely on a simple URL in an img tag: CVE-2004-1703 and CVE-2004-1995 allow user accounts to be added, CVE-2004-1842 allows gaining administrator privileges⁵. Others affect administration itself: CVE-2009-3520 allows the administrator's password to be changed, and CVE-2009-3759 allows changing passwords or shutting down a virtual machine from a web interface⁵.