In this article, we will have a look at some unique methods for exploiting CSRF attacks.
Cross Site Request Forgery is an attack that forces an authenticated user to execute some unintended action. These actions can vary depending on the types of application.
Note: This article does not cover the basic validation bypasses such as checking server side token validation, bypassing referrer checks and executing CSRF via XSS attacks. Also, the POC shown are taken for real world targets, that why some part of images are blurred. However, our main focus is to share the techniques we have learned from our experiences.
We will have an in-depth look at following two techniques:
Abusing CORS via Flash Files
Bypassing XMLHttpRequest Header Validation (By Matthias Carlson)
Abusing CORS via Flash Files
Crossdomain.xml file is a cross-domain policy file that grants flash players to access the resources other than it is hosted on.
For example, the following screenshot shows the cross domain.xml file for twitter.com. Here we can see that twitter.com server only allows flash files from certain domains to access its resources.
At this point, you may get some idea that if the attacker controls any of the above domains so he/she can simply read your Twitter messages or post on the behalf of yourself.
Exploiting Insecure Cross Domain Policy Files:
Well, In the context of security it all comes down to what and who you trust with your data?
In real world scenario, the answer will be “NO ONE”. Same is the case with cross domain.xml file shown above. Thus, twitter.com has explicitly defined its domains so that only these domains can access the specific resources when needed. Now, If you have read to this part carefully, you might already get the idea of how an insecure crossdomain.xml file looks like.
Following screenshot shows an example of insecure crossdomain.xml file.
As we can see in the allow-access-from directive, it allows any domain to access its resources by specifying a wildcard instead of domain name. Further, we also have the freedom to choose different headers.
How to exploit?
Exploiting the above misconfiguration is as easy as finding this vulnerability. As we can grab contents of HTML page for any vulnerable domain, thus allowing us to fetch CSRF tokens and further craft a CSRF payload.
We will be using the following piece of action script code to exploit this vulnerability:
As can be seen, in the above screenshot, we have defined a public function in our exploit that will fetch the html page content and send back to attacker domain.
Following piece of code is embedded in index.html page of attacker.com
Following are the requests send by browser when the victim visits attacker.com.
As can be seen in the above screenshot, when the browser loads the swf file, it simply checks crossdomain.xml file for the vulnerable domain, if it finds the necessary directives as mentioned above, It loads the resources. For sending data back to attacker domain, the browser checks the same directives and initiate the post request.
The attacker can then further fetch the CSRF tokens by parsing the html using regex, craft the CSRF payload and load the same request in a new tab or in the same window.
The main focus of above this topic is how we can steal CSRF tokens by exploiting insecure cross domain policy for flash files.
Bypassing XMLHttpRequest Header Validation
Due to the increasing use of mobile applications, the organizations are also switching their web applications to use the centralized web service end points. Now the question arises why? The answer is simple to reduce the complexity and increase the scalability; previously they have to maintain separate technologies to support their business, and now they can merge them into one and focus on productivity instead of compatibility issues.
We all know there are one popular format for feeding data to these web services which are JSON. But simple CSRF payloads doesn’t work due to HTTP headers limitation. Well, we can use XMLHttpRequest, I have tried that, but it failed miserably due to Same Origin Policy(SOP). Now the question arises how we can craft the CSRF payload for this data format and bypass SOP restriction.
We can again use flash based payloads but this time in conjunction with one of uncommon HTTP status codes.
Credits: Mathias Karlsson (@avlidienbrunn)
To get a clear picture of attack, have a look at below image.
As can be seen in the image above, the attack works in following steps:
Authenticated user loads the attacker web page containing malicious SWF file.
SWF file made an XMLHttpRequest to attackers domain, before doing that, the browser checks whether attacker domain allows flash requests via cross domain.Xml file (which in this case is obviously yes) as shown in (2) step.
Victim browser then made an actual post request to attacker’s domain, with post data that needs to send to the vulnerable domain.
The attacker sends response with 307 redirect, which means send POST data to the value of location header.
The victim browser then sends actual POST request containing attacker’s payload to the vulnerable domain with necessary headers. However, this time, the browser request for crossdomain.xml file but after sending the payload.
We will be using the following piece of action script code to make a POST request to attacker’s domain.
Before Proceeding with executing the above action script code lets have a look at the profile of victim before the attack. So we have updated our profile with the first, middle and last name as a test which means after successful exploitation these values must change to CSRF as shown in the image above.
Let us compile the above action script code, host it on attacker server and run it in our browser.
As can be seen in the image above, the following are the set of requests that gets executed in our browser.
The browser first checks whether the attacker server allows flash requests by requesting cross domain.xml file.
It then posts the CSRF payload to attacker’s server.
The attacker server responds with 307 redirects with the location of vuln-web.com as shown in the following screenshot.
The browser then sends the payload to the vulnerable domain with proper headers.
If we look at the 4th request in above image, we can see that browser did make a request to the vulnerable domain for crossdomain.xml file, however after executing our payload.
As can be seen, in the below screenshot we are successfully able to execute CSRF attack, bypassing SOP restrictions.