How to mitigate CSRF Vulnerabilities

Introduction:

In the previous articles, we discussed what Cross Site Request Forgery vulnerabilities are and how one can detect and exploit them. From a developer’s view point, it is important to understand how to mitigate CSRF vulnerabilities. This article discusses mitigation techniques that are commonly used to prevent CSRF vulnerabilities. 

Learn Secure Coding Fundamentals

Build your secure coding skills as you progress through 14 courses focused on discovering, exploiting and mitigating common coding vulnerabilities.

Start Learning

How to mitigate CSRF Vulnerabilities?

Use of CSRF Tokens is one of the most popular and recommended methods to mitigate CSRF vulnerabilities in web applications. This can be implemented by generating a token at the server side and the server sends it to the client. When a form is submitted by the user, along with the session cookies, the details entered in the form, the token sent by the server earlier should also be sent. The server side code will then validate if the token matches with the token provided earlier to the client. If the token was not found within the request, or the value provided does not match the value within the user session, then the request should be aborted, session of the user terminated and the event logged as a potential CSRF attack in progress. 

It should be noted that the CSRF tokens can be generated once per user session or for each request. While per request tokens are more secure than the per session tokens, they may add more complexity and usability issues. So, per session CSRF tokens are commonly seen in web applications. 

When implementing CSRF tokens, developers must note the following:

• CSRF tokens should not be sent as part of cookies
• These tokens must be unpredictable as it defeats the purpose of CSRF tokens if they can be predicted by the attacker. 
• Tokens must be unique per session

CSRF Token example:

Let us consider the following request from Damn Vulnerable Web Application(DVWA): impossible challenge under CSRF.

Host: 192.168.1.91:8080

Upgrade-Insecure-Requests: 1

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.111 Safari/537.36

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9

Referer: http://192.168.1.91:8080/vulnerabilities/csrf/

Accept-Encoding: gzip, deflate

Accept-Language: en-GB,en-US;q=0.9,en;q=0.8

Cookie: PHPSESSID=od7idde1i52gjlc0t6chklug43; security=impossible

If you observe the preceding HTTP request, there is a CSRF token being sent when the form is submitted. Once the server receives this request, the token must be validated on the server side. The following code snippet shows how DVWA does it.

Secure source code example:

if( isset( $_GET[ 'Change' ] ) ) {

// Check Anti-CSRF token

checkToken( $_REQUEST[ 'user_token' ], $_SESSION[ 'session_token' ], 'index.php' );

  [Redacted]

If you notice the code in the above excerpt, the value of user_token  sent by the client is validated against the token from a session variable on the server side. If these two values do not match, the user will be redirected to the index.php page. Any further processing by the application happens only if the CSRF token is valid. We can verify this by tampering the CSRF token using a tool like Burp Proxy. To verify, submit the change password request in  DVWA and tamper the CSRF token and we should see the following response.

Date: Sun, 25 Oct 2020 14:39:28 GMT

Server: Apache/2.4.25 (Debian)

Expires: Thu, 19 Nov 1981 08:52:00 GMT

Cache-Control: no-store, no-cache, must-revalidate

Pragma: no-cache

Location: index.php

Content-Length: 0

Connection: close

As we can notice, the user is simply redirected to the index.php page.

Other mitigation techniques:

Though use of CSRF tokens is the recommended way of mitigating CSRF tokens, following are some of the other mitigation techniques that can be used as a defense in depth approach.

Use of Captcha:

Captcha is another technique that can reliably prevent CSRF vulnerabilities as users must enter a unique value while submitting a form.

SameSite Cookie attribute:

SameSite cookie attribute with the value Strict value will prevent the cookie from being sent by the browser to the target site in all cross-site browsing context, even when following a regular link. This will prevent CSRF attacks as the submitted request will not have a valid session.

Use of Referer header:

Some developers also use Referer header to verify the origin of the request inorder to defend against CSRF attacks. This is to ensure that the request has originated from the application’s own domain. This approach is often subject to bypasses and not recommended.

Learn Secure Coding Fundamentals

Build your secure coding skills as you progress through 14 courses focused on discovering, exploiting and mitigating common coding vulnerabilities.

Start Learning

Conclusion:

CSRF vulnerabilities can be tricky to mitigate as many developers find it complex to understand CSRF vulnerabilities. Clearly, they are not that hard to mitigate and one can use CSRF token as an additional parameter to mitigate CSRF. This article has provided practical examples of how CSRF vulnerabilities can be mitigated by taking examples from Damn Vulnerable Web Application(DVWA). 

Sources:

1. https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html
2. https://owasp.org/www-community/attacks/csrf
3. https://owasp.org/www-project-top-ten/