10 Methods to Bypass Cross Site Request Forgery (CSRF)

During web application security assessments, Cross Site Request Forgery is often an underrated vulnerability and often ignored, either due to the fact that it requires some sort of user interaction or lack of severity. Lack of severity part is debatable, it depends on which functionality the CSRF vulnerability exists, for example it would be severe if it exists on a password change functionality, an attack could send a crafted link to victim, victim clicks the link (Actual click is not required, one could use embedded HTML links in a page), attacker rides the victims session and password gets changed of attacker’s choice.

There are several methods being used to protect web application attacks, the most common method is using Anti CSRF Tokens. In this post i will be presenting the techniques one should use to bypass when confronted with CSRF protection mechanism. 10 Methods to Bypass Cross Site Request Forgery (CSRF) are as follow.

Randomness of Anti-CSRF Token

CSRF Token Randomness must always be checked to make sure its random enough not to be guessed. If Anti CSRF Token is not random an attacker could guess the next Anti CSRF token, use it in a legitimate request and perform the attack, the main purpose of Anti CSRF token is to associate a random parameter at each request so that the same request cannot be replayed. Following are the ways to check for Randomness of Anti CSRF Token:-

• Check for the length of the token. “22ma9y83bz” is not good enough, “99856782347567msadiotrbnwquh” is, using automated tools like Burp or custom scripts one could calculate the randomness of shorter tokens. Additionally sometimes the backend validation only checks for the length of the CSRF token for its validation, a quick check for this is to change one character of the Token and replay.
• Check for common encryption/encoding types, there is a good chance the Anti-CSRF token is an encrypted/encoded value. If you think “a0a080f42e6f13b3a2df133f073095dd” is random and long enough Anti-CSRF token so it is probably secure. Nah You are wrong, “a0a080f42e6f13b3a2df133f073095dd” is MD5(122). You can similarly encrypt the next value MD5(123) to for CSRF token bypass. 
• Check for complexity and randomness of Anti CSRF Token, this can be done using automated tools and scripts like Burpsuite Pro, it will compare a large number of Anti-CSRF tokens from requests/responses and matches them byte by byte to find the similarity and difference, either they are being generated using a specific Algorithm, by comparing large amount of data we can analyze and establish the Pattern being used, once we know we can generate the tokens using the same pattern to be used for CSRF token bypass.
• In my experience with web security assessments, often the Anti-CSRF token is composed of two parts, one of them remains static while the other one dynamic. For example, one time you get the Anti CSRF Tokens “837456mzy29jkd911139” for one request the other time “837456mzy29jkd337221” if you notice, “837456mzy29jkd” part of the token remains same in both requests, what happens if you use remove the dynamic part of the token and send the request with only the static part?. It often works thanks to poor back-end validation.

Exploiting Poor Implementation

Poor implementation of Anti-CSRF token leads to a wide range of issues, during security assessment Penetration testers should make sure to test the application against such issues, some of the issues are mentioned below:-

• Replay Attacks, this simply means that attacker is able to use the same Anti CSRF token for a number of request, by exploiting this issue attacker can simply use the same CSRF token in Crafted HTML form for the attack. I have seen applications where CSRF token is session based, which means that the CSRF token remains the same for the entire session until the user session is nulled. It is in best practice to use per request CSRF Tokens, because regardless of the method used, if the CSRF token of per session token gets compromised it can be used again by the attacker. Per request Anti CSRF token has its disadvantages in terms of usability, for example back button wouldn’t work because it will submit the previous token while that gets in validated.
• Sometimes the application wouldn’t even check if the Anti CSRF token parameter is present in the request or not (stupid eh?) , easiest way to bypass CSRF Token even Facebook has made such a blunder.

CSRF bypass  by Leveraging other Vulnerabilities

This is where it gets interesting, leveraging other vulnerability in the Web Application to exploit CSRF weaknesses. Following are few of the ways chaining of vulnerabilities can lead to CSRF exploitation:-

• There are good number of whitepapers detailing how one could obtain CSRF tokens leveraging XSS vulnerabilities this one describes the process in detail, such attack works even if Anti CSRF token is per request based.
• In cases where Cookie attributes are used to submit CSRF token, for example In Double cookie submit CSRF protection Method , If a vulnerability in application allows an attacker to do Header Injection, this would also lead to user supplied cookies, attacker can set its own CSRF values in cookie resulting in Anti CSRF Token bypass.
• Verb tampering (Converting GET to POST and vice versa) is another way one could bypass CSRF, consider this interesting example explained in the write up by interwebtechie
• Crossdomain.xml file is responsible for assigning permissions to external sites for FLASH content, An insecure crossdomain.xml file can lead to a number of issues, including SOP bypass and extracting Anti CSRF token using FLASH. The requirement in this case is to have a crossdomain.xml file where “allow-access-from domain” is set to wildcard “*” . which means that any attacker can make request and read response which could be used for gaining Anti CSRF Token. I quickly used google dorks to find Adobe domain having wildcard access. https://fpdownload.adobe.com/pub/swz/crossdomain.xml

i am probably missing some other interesting ways to Bypass CSRF, feel free to let me know, I will include that with acknowledgement. Happy Hacking!