Cross-site request forgery (CSRF) is a common web application vulnerability that can put users’ online accounts and sensitive information at risk. In this blog, we provide an overview of CSRF attacks, including how they work, what makes them dangerous, and what mitigations can be put in place to protect your application.

What is Cross-Site Request Forgery?

CSRF involves an attacker tricking a user into performing an action on a website without their knowledge or consent. For example, an attacker could send a link to a user that, when clicked, submits a form on a website the user is logged into. The form submission could then perform critical actions such as transferring money or changing account details.

CSRF attacks can be especially dangerous because they do not require the attacker to steal the user’s credentials or gain access to their account. Instead, the attacker relies on the user’s existing login session to carry out the attack.

What Does a Successful CSRF Attack Require?

For a successful CSRF attack to occur, there are several requirements that must be met:

Target URL: The attacker must know the URL of the targeted web application and the specific action that they want to perform on behalf of the victim. This is because the attack involves the submission of a forged request to the targeted application.

Authentication: The victim must be logged into the application that the attacker is targeting. This means that the victim must have an active session on the site.

Cookies: The target application must be using cookies to transmit the session token. This means that if the session token is stored in local/session storage, the token will not be automatically submitted by the browser when a request is initiated. As a result, the attack won’t take place within the victim user’s session.

Vulnerable Application: The targeted application must be lacking effective anti-CSRF protections such as anti-CSRF tokens and the SameSite cookie attribute (for the session token). But please note that the anti-CSRF protections can be bypassed completely if the CSRF attack is used in conjunction with a cross-site scripting (XSS) vulnerability in the target site.

Victim Interaction: The victim must perform a specific action that triggers the forged request. This can include clicking on a malicious link, visiting a webpage that contains malicious code or in triggering a XSS vulnerability containing the payload on the target site.

Browser Support: The majority of browsers past a certain version will default a cookie’s SameSite attribute to ‘Lax’ where no explicit attribute value is provided. This means that cookies will only be sent with cross-site GET requests (and not with any cross-site AJAX calls). This acts as a supplementary layer of protection against a successful CSRF attacks but browsers such as Safari (and older versions of modern browsers) will default to SameSite = ‘None’ or equivalent.

CSRF in Action:

To demonstrate CSRF in action, we’ll be using a vulnerable input field from OWASP Juice Shop.

In this example, we log in as a standard user who has the username of ‘user1’. Let’s say that our aim is to change the username of an admin user to ‘user1’ as well.

We attempt to change the username of the standard user and capture the request with the Burp Suite HTTP proxy. We see in the request that there is no anti-CSRF token in place. An anti-CSRF token is a random value that is typically stored hidden in the POST request form but in this case has not been implemented.

We know that an admin user would likely be making the same request to change their own username, however, at the moment we can only initiate the request with our standard user’s session token.

We want the admin to trigger the same request and so we need to create a CSRF payload to be executed (Burp Suite can help automate this).

If we right click on the request -> Engagement Tools -> Generate CSRF PoC. This provides us with a HTML payload that will execute a basic CSRF attack.

We ensure that ‘include auto-submit script’ is ticked so that the payload will automatically trigger when the HTML renders.

We can then copy the HTML payload which can be embedded in a third-party site or within a cross-site scripting vulnerability (useful when bypassing cross-site request protections). For this example we’ll trigger the payload through a Burp Suite link instead by clicking ‘Test in browser’.

We copy the link provided and paste it into our browser. Proxying the traffic through Burp Suite, we can see that a successful request is being sent to the target application to change the username to ‘user1’. All we need to do now is to get the admin user to trigger the payload.

Whilst logged in as the admin user, we browse to the same Burp Suite link (mimicking a malicious site).

When the admin user reaches the site, the malicious HTML code renders sending a request to change the username to ‘user1’, however, this time, the admin’s session token is being sent with the request instead of the standard user’s and therefore the username of the admin user is changed to ‘user1’.

After the request, we see that the username of the admin user has been successfully changed. Depending on the protections in place, this can also work for other actions including changing email addresses and passwords, deleting users and other critical changes on the site. The results of these actions include user account compromise, disruption to the application and unauthorised access/manipulation of user data.

How to Protect Your Application Against CSRF Attacks:

Use anti-CSRF tokens: Anti-CSRF tokens are unique codes that are added to forms and requests to verify that the request is legitimate. These tokens can help prevent attackers from submitting unauthorised requests.

Introduce the SameSite attribute for cookies: Ensure that cookies that are used to maintain the user’s session have the SameSite cookie attribute explicitly stated. The value should either be ‘Lax’ which allows the cookie to be sent with cross-site navigational GET requests but not with cross-site AJAX calls, or ‘Strict’ which prevents the cookie from being sent with all cross-site requests. This should be used as an additional layer of protection rather than the primary defence against CSRF attacks.

Introduce a session timeout for the application: Ensure that a session timeout mechanism is introduced that will invalidate the user’s session after a period of inactivity. Having the user logged into an application indefinitely increases the risk that the victim user has an existing session when the CSRF payload is triggered.

Require the user to input a known secret for critical actions: Where there is a critical action to be performed such as a user deleting their account or changing their password/username, consider prompting the user for a known secret such as their current password. This is unlikely to be known to the attacker and will prevent them from successfully exploiting the protected mechanism.

Cross-site scripting (XSS) prevention: XSS within the target site can defeat all CSRF mitigation techniques, since it will execute within the same context/origin as the site we’re trying to exploit. This allows us to read the user’s anti-CSRF tokens before we make a request and bypass defense-in-depth mitigations such as the SameSite cookie attribute. Any mitigations put in place for XSS will automatically reduce the risk of successful CSRF exploitation.

Predatech is a cyber security consultancy that offers a range of services including CREST accredited penetration testing and Cyber Essentials/Cyber Essentials Plus assessments. What makes us different? We combine expert cyber security with great customer service and value for money. If you’d like to better understand your security posture, and how to strengthen it from attacks including CSRF, please contact us for a free consultation.