Cross-site request forgery (CSRF)

Cross-site request forgery (CSRF) is an attack wherein an attacker causes an authenticated user to submit unauthorized requests to a web application. CSRF exploits the trust that a website has in the user.

Attack Vector

For a CSRF attack to happen, the victim must be logged in into the target site and have a session cookie assigned by the site. Through the use of social engineering, an attacker can trick the victim to visit a malicious website that causes them to send an unwanted HTTP request to the target application. If the application relies on session cookies alone to validate user requests, the forged HTTP request would be executed by the web application since the victim's browser would include the session cookie in the request.

Impact

A CSRF attack can result in the victim performing state changing requests such as changing passwords and transferring funds. If the user has a privileged account, the attacker may also gain control of the web application.

Attack Examples

Alice logs in into the website bank.com, and is issued a session cookie, SESSIONID=1jvc34dx. She receives a phishing email from Eve with a link to mal.com and clicks on the link. This leads her to a malicious website with the following HTML code, which forges the form on the website that allows users to change their passwords:

<html>  
    <body>  
        <form action="https://bank.com/change_password.php" method="POST">  
            <input type="hidden" name="password" value="pwned" />  
        </form>  
        <script>  
            document.forms[0].submit();  
        </script>  
    </body>
<html>

The script on the malicious website causes Alice's browser to send a HTTP request with her session cookie included:

POST /change_password.php Host: bank.com Cookie: SESSIONID=1jvc34dx password=pwned

The website validates the request as it includes Alice's valid session token. Eve is now able to login into Alice's bank account with the new password.

Defenses

CSRF token - A CSRF token is a random and unique per-session or per-request value that is embedded into HTML forms as a hidden POST variable:

<input type="hidden" name="csrf-token" value="FKutPdw5jRcNYWkGPoaYTA9S4zccVCnN" />

This token is verified by the web application together with the session cookie when the form is submitted. As the attacker does not know the value of the hidden form field, their forged request will be rejected by the web application.

SameSite Cookies - The web server can set the session cookie's "SameSite" attribute to "strict", which will cause the browser to include the cookie with requests that originate from the same domain. Eve's website mal.com is unable to send a post request to bank.com/change_password.php since the request and session cookie does not have the same domain.
Referer header - The web application can check the HTTP "Referer" header to verify that the request originated from the same domain as the target resource. The "Referer" header may however be omitted in some request, for example by the browsers for privacy reasons.
Refer to the OWASP Cheat Sheet for other defenses.

Criteria for Demonstration

To demonstrate a CSRF attack, provide a HTML file that, when accessed by the victim, causes an unauthorized HTTP request to be sent to the web application by the user. Explain how we can verify the success of the attack.

Other resources

jloh4