Cross Site Request Forgery is an vulnerability which can be easily understood and exploited in the web application.
And it can be found on most of the sites due to the misconfiguration.
So most of the peoples in infosec start their learning from this vulnerbility.(which require minimal coding knowledge to exploit it.
I thought to write a blog aroung it in the perspective of attacker and developer.
There are various labs available to get a handson exposure on CSRF. Few of them are
- https://portswigger.net/web-security/csrf (free)
- https://pentesterlab.com/exercises/csrf/course (Paid)
- bWAPP(free-offline installation)
It is recommended to start with the free labs and depend on your interest it can be extended to paid labs or even you can try building a vulnerable web applicaiton on yourself.
Using CSRF attacker can able to perform actions on behalf of user without their knowledge.
Consider if you opened a facebook profile in one of the tab and you mistakely clicks or accepts the attacker link.
Then it is possible for the attacker to change the email address or other sensitive information if the facebook wasnt protected against CSRF.
Earlier CSRF was found in facebook,google and other big tech guys. Eventhough developers more aware of this exploit in recent days, still misocnfiguration is found by bug hunters.
Types
- URL based - Sensitive token on GET request
- Form based - POST based
I will start with some of the reports which i found to be interesting related to the CSRF.
CSRF in google
Yeah you heared it right. Even i got wondered how this kind of known bugs is possible in a google platform.
Like all beginners i had a myth that it will be never possible to exploit Google. Its true their product has unique security team and the developers itself more equipped to build a secure code. But they are still devs right.
It was report publised by Oday Alhalabi who is is the top rank in the HOF on google.
This is the blog link where he published his report
He started to bypass the CSRF token in a novel ways but it didnt work out.
But he found that CSRF token can be viewed by public and that can be sent to victim to exploit it.
Its a another report by alhalabi itself, where he tried to replace a same length CSRF token in the request and it was accepted due to misconfiguration
For full report
Another one is by Jasinder where he found that bughunters portal having a CSRF token but its not validated against the server.
Hence it is possible for attacker to read all the reports of the users.
You can find the more detailed report and video here
Then a clever identification by Hassan Khan Yusufzai on the json data manipulation and results in the CSRF.
He had a same feeling of mine that google products never be exploited.
Lab
Exercise 1
In the first exercise we will exploit the page which didnt have any protection against the CSRF attack.
To complete the exercise, go the page which containing vulnerable parameter https://ac021fcf1ec09914c0c6599500a5000e.web-security-academy.net/my-account/change-email and provide any test email for update and capture the request in your favourite interceptor.
Then try to manipulate the emailid to attacker and generate a html page which has the following similar code.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
<html>
<!-- CSRF PoC - generated by Burp Suite Professional -->
<body>
<script>history.pushState('', '', '/')</script>
<form action="https://ac021fcf1ec09914c0c6599500a5000e.web-security-academy.net/my-account/change-email" method="POST">
<input type="hidden" name="email" value="test@hack.com" />
<input type="submit" value="Submit request" />
</form>
<script>
document.forms[0].submit();
</script>
</body>
</html>
To test the vulnerability you can use the exploit server on the same lab, to check the exploit on victim side.
Paste the code on body and click store -> deliver to victim to complete the exercise.
Since we have the document.forms[0].submit(); code which will auto submit the request when viewed by victim.
Finally the victim dashboard will be successfully updated with the attackers email id. Hence he can further reset the password of the account and perform the malicious actions
Exercise 2
As mentioned in the CSRF reports from google, still many websites vulnerable to handle the CSRF tokens. In this lab exercise we tried to switch the HTTP request and bypass the CSRF protection on the server.
In a historical way we tried to tamper the CSRF token but the server validation captured it successfuly and throws a 400 Bad Request.
Hence we tried to change the method and it was results in the successfull bypass on the server validation of the CSRF tokens.
First we checked the request in the repeater without any tampering
Then we tried to tamper the CSRF token which results in the 400 Bad Request
So we tried with the method switch from POST to GET, which results in successfull bypass of the CSRF token validation on the server
So finally we delivered the exploit the payload to victim
Exercise 3
In this exercise we do see the server isnt validating the CSRF token at all, hence we can fully neglact the CSRF token parameter and build our exploit payload