In my last post on CSRF I discussed the basics of the attack and offered, what I think is, a great analogy for anyone who has a tough time understanding it. This post will focus on the techniques you can use to bypass CSRF protections and achieve a successful attack.
Circumventing CSRF Tokens
- In some cases the server will only verify the csrf token during a
POSTrequest, but it may not verify it in a
GETrequest. When performing tests, change the HTTP request from
GETto look for any differences between the responses.
- In other cases the server will validate the authenticity of a csrf token if it is included in the request, but if it is omitted it may still process the request and skip any form of validation.
- If the server requires that a valid token must be present in the request then you still have a chance to bypass it! Some applications may not validate that the token in the request is linked to the session cookie; it will only validate that the server has issued that token. This means that you can log into your account on the application, grab your csrf token and feed that token to the victim in your CSRF attack.
- However, there may be cases where the application does tie the csrf token to a cookie, but it may not be the session cookie. In this case, you can log into the application with your account, grab the csrf token and accompanying cookie, leverage the website’s ability to set a cookie (if applicable) with your cookie, input the csrf token as a normal parameter in the request body and you might be able to launch a CSRF attack.
- If the previous two vulnerabilities don’t seem to work, there is another method that you can try. Some applications do not keep track of what csrf tokens they issue; they duplicate each token within a cookie and a request parameter. When the request is sent to the server it checks to make sure the values in the cookie and request parameter are equal. If the website allows any cookie-setting behavior, then an attacker can invent a token (of the same format as the application’s token), set it as a cookie in the victim’s browser, include it as a request parameter and launch a successful attack.
Circumventing Referer-based Defenses
Some applications may uses the HTTP Referer header to validate requests in order to prevent a CSRF attack. The data found in the Referer header is the link to the URL where the current request is coming from. For example if I am on
superspooky.net and there is a link to
super.superspooky.net then the Referer header in the HTTP request to
super.superspooky.net would be
superspooky.net. Now that we understand this , below are three methods to circumvent Referer-based defenses.
- Some applications will verify the Referer header when it is included in the request, but when omitted they will still handle the request properly. Within your website’s code, add the line
<meta name=”referrer” content=”never”>and the resulting request will omit the Referer header.
- In other cases the application will check for the presence of its domain name in the header. If the application is only looking for its domain name anywhere in the header, than an attacker can place the required value in their url:
http://superspooky.net/csrf-attack?vulnerable-website.com. The resulting request will now include this entire url, including
vulnerable-website.com, the domain of the target application.
- However, if the application checks that the domain in the Referer starts with the expected value, then an attacker can make the domain a subdomain of the attacker’s website, like so:
I hope these techniques help you in your bug hunting! Give me a follow on twitter if you desire.