Intro :
- I hope you're doing well guys . For being honest I'm not a fan of write ups but some kind of findings should be disclosed . Let's go this is a vulnerability that I found on one of hackerone private programs . The funny thing that It was pretty easy for identifying it but totally complex for being exploited and that's the cool part .
Technical details :
- So keep an eye on the illustrative picture while I'm explaining the process let's start from up to down
- You may notice that the http method is a delete method which means that a written exploit in this case isn't going to look like the traditional CSRF exploits . In cases where the affected request is using methods such as PUT/DELETE we can use " _method " parameter ( a post request with a put or delete request inside it more technically this kind of behaviors is called method overwriting ) but it's limited to some frameworks or we can initiate an ajax ( xmlhttpreq ) with the particular http method and for sure this is applicable only to cases where the cors configuration of the vulnerable application is not validating the origin properly. Google and javascript documentations are your lovely friends so don't hesitate to take a peek on them .
- The second thing is the Content-Type header . As you expected there was no validation for the content type ( There was some restrictions but I don't think that those restrictions were implemented based on a security concern that's why it wasn't a big deal for bypassing them )
- The third factor are the http header that are holding the CSRF tokens ( TB-CSRF-Token and X-XSRF-TOKEN ) There was no validation for those headers in the server side so if you remove them or remove their values nothing happens this is a vulnerable behavior but still not enough for making this scenario possible to exploit, basically that's due to the double cookie submission prevention ( I'll explain how it works in the next sections but for now take a look on the picture exactly on the highlighted csrf tokens in the cookies ) those tokens are csrf cookie double submission prevention . Briefly what happens is that they're protecting the website from CSRF exploits even if the CSRF tokens in http headers aren't getting validated.
- Now the fourth thing to check is the origin and referer headers . They weren't validated . Yep this is a good news so when we run our exploit on the victim browser the website isn't going to validate where the forged request is originating from.
- Now let's get back to the tokens in the cookies . The first thing that you should know is that the PLAY_SESSION is the session cookie. Now let's look at that cookie parameter that is called XSRF-TOKEN you can notice that it has the same value of CSRF tokens in the http headers so what is that ? this is the double submission csrf prevention as you know an attacker has no way to access the victim cookies during a CSRF attack but he has the ability to remove or manipulate the tokens that are implemented on http headers or a request body . This is the time where the double submission prevention starts to play, in the server side the backend code is going to make a small comparison between the csrf tokens submitted by http header or request body and those in the cookies so if the attacker was able to manipulate them he is not going to be able to manipulate those in the cookies and the server side comparison will fail ( and for sure the csrf attack would fail too ) . More info on csrf double submission prevention are here https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html
- Another thing that I didn't understand is that there's another csrf token tied to the session ( PLAY_SESSION ) as you can see ( I highlighted it ) why a developer is supposed to tie a csrf token to the cookie session that was pretty confusing to me. The only scenario I can imagine in this case is that the tied token is a second way to perform the double submission csrf prevention .
- Now how we are supposed to test if the double submission prevention is properly implemented or there's a way to break on it . This is pretty simple, remove the tokens in the http headers but don't touch the tokens in the cookie then forward the request if the process succeed without any errors it means that there's no comparison in the server side and the double submission prevention is useless in this case .
- This is what happened exactly there was no validation for the tokens in the http headers in the server side and there was no comparison between the tokens in the http headers and those in the cookies which made the vulnerability possible to exploit .
Takeways :
- Don't get confused when you see a lot of CSRF tokens.
- Most of time I get paid for vulnerabilities that are complicated and to be honest I look for them most of the time. Why ? simply because most hackers like to get paid easily but they don't like complex vulnerabilities so don't give up without trying when it looks un-exploitable .
- When I was testing this private program I found that the affected endpoints are the login and the account deletion. But the email changing endpoint was properly implemented and not affected. I mean if you're testing CSRF on a target website don't make random conclusions that if the email endpoint isn't affected the rest of endpoints too aren't affected but test each one separately .
