In this article we will learn about Bypassing CSRF Protections for Fun and Profit.We will have a look at some unique methods for exploiting CSRF attacks.

Overview[Bypassing CSRF Protections]:

Cross Site Request Forgery is an attack that forces an authenticated user to perform some unintended action. These actions may vary depending on the type of application.

Note: This article does not cover basic authentication bypassing, such as server-side token validation checking, bypassing referrer checks, and performing CSRF via XSS attacks. Also, the POCs shown are taken for real targets, so some parts of the images are blurry. However, our main goal is to share the techniques we have learned from our experience.

We will look in detail at the following two techniques:

• Exploiting CORS via Flash files
• Skipping XMLHttpRequest header validation (Matthias Carlson)
• Exploiting CORS via Flash files
• Crossdomain.xml

The Crossdomain.xml file is a cross-domain policy file that allows Flash players to access resources other than where it is hosted.

For example, the following screenshot shows the cross domain.xml file for twitter.com. Here we see that twitter.com only allows flash files from certain domains to access its feeds.

At this point, you can get some idea that if an attacker controls any of the above domains, they can simply read your Twitter messages or post on your behalf.

Exploiting insecure cross-domain policy files:

When it comes to security, what and who do you trust with your data?

In a real world scenario, the answer will be “NO ONE”. The same goes for the above cross domain.xml file. So Twitter.com has explicitly defined its domains so that only those domains can access specific resources when needed. If you’ve read this section carefully, you may already have an idea of ​​what an insecure crossdomain.xml file looks like.

The following screenshot shows an example of an 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 the domain name. We also have the freedom to choose different headers.

related article:Everything you need to know about Ethical Hacking as a Career by Blackhat Pakistan 2023

How to abuse?

Exploiting the above misconfiguration is as easy as finding this vulnerability. Because we can get the content of the HTML page for any vulnerable domain, which allows us to retrieve the CSRF tokens and further create the CSRF payload.

To exploit this vulnerability, we will use the following part of the action script code:

As you can see in the screenshot above, we have defined a public function in our exploit that will retrieve the content of the html page and send it back to the attacker’s domain.

The following piece of code is inserted into the index.html of the attacker.com page

Following are the requests send by browser when the victim visits attacker.com.

As seen in the screenshot above, when the browser loads the swf file, it simply checks the crossdomain.xml file for the vulnerable domain, if it finds the necessary directives, as above, it loads the resources. To send data back to the attacker’s domain, the browser checks the same directives and initiates a send request.

An attacker can then further retrieve the CSRF tokens by parsing the html using a regular expression, create a CSRF payload and load the same request to a new tab or to the same window.

The main topic of the above topic is how we can steal CSRF tokens using insecure multi-domain policy for flash files.

Skipping XMLHttpRequest header validation

Due to the increasing use of mobile applications, organizations are also migrating their web applications to centralized web service endpoints. Now the question arises why? The answer is simple, reduce complexity and increase scalability; they previously had 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 that there is one popular format for delivering data to these web services, which is JSON. However, a simple CSRF payload does not work due to HTTP header limitations. We can use XMLHttpRequest, I tried it but it failed miserably due to Same Origin Policy (SOP). Now the question arises how we can create a CSRF payload for this data format and bypass the SOP limitation.

We can use flash data again, but this time in conjunction with one of the unusual HTTP status codes.

Credits: Mathias Karlsson (@avlidienbrunn)

To get a clear idea of ​​the attack, take a look at the image below.

As seen in the image above, the attack proceeds in the following steps:

• An authenticated user loads an attacker’s web page containing a malicious SWF file.
• The SWF file made an XMLHttpRequest to the attackers domain before the browser does it, it checks if the attacker domain allows flash requests via cross domain.Xml file (which it apparently does in this case) as shown in step (2).
• The victim’s browser then made an actual send request to the attacker’s domain with the post data to be sent to the vulnerable domain.
• The attacker sends a 307 redirect response, which means to send POST data to the location header value.
• The victim’s browser then sends an actual POST request containing the attacker’s data portion to the vulnerable domain with the necessary headers. However, this time the browser requests the crossdomain.xml file, but only after the data part has been sent.

Exploitation Phase:

We will use the following part of the action script code to send a POST request to the attacker’s domain.

Before we proceed to execute the action script code above, let’s take a look at the victim’s pre-attack profile. So we have updated our profile with first name, middle name and last name as a test, which means after successful use these values ​​should 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 seen in the image above, the following are the sets of requests that are made in our browser.

• The browser first checks if the attack server allows flash requests by asking for a cross domain.xml file.
• It then sends the CSRF payload to the attacker’s server.
• The attacker’s server responds with a 307 redirect with the location vuln-web.com as shown in the following screenshot.

• The browser then sends the content to the vulnerable domain with the correct headers.
• If we look at the 4th request in the image above, we can see that the browser requested the crossdomain.xml file to the vulnerable domain, however, after executing our payload.
• As can be seen in the screenshot below, we are successfully able to perform a CSRF attack and bypass the SOP restriction.

References:

https://wiki.mozilla.org/Security/Guidelines/Web_Security#CSRF_Prevention

https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy

http://gursevkalra.blogspot.in/2013/08/bypassing-same-origin-policy-with-flash.html