Forging Content-Type Header With Flash

You might already know how you can forge HTTP request headers using flash. So, to keep it short, I’m talking about Content-Type only.

Lately, I’ve been seeing tweets & reports about CSRF attack involving JSON data. In fact, I saw a tweet asking if it was safe to rely on Content-Type: application/json for CSRF protection. And, going through the replies, I found it was concluded safe- because browsers don’t yet support application/json in HTML form submission.

However, one can also submit JSON data as text/plain with name value pairs matched accordingly. Here’s a recent HackerOne report serving the purpose of POC. And, if it’s for CSRF, the same can also be achieved via simple XHR or fetch request as;

But, if the application checks received Content-Type header, attack fails. So, for developers, it might be tempting to just check received Content-Type and proceed only if it matches application/json.

Let’s proceed with an example. The following video demonstrates a CSRF attack against HackerOne API which only accepts application/json requests.

If you noticed, I’m using the same old trick- Flash + 307 redirect. This still works in all major browsers.

Let’s dive into technical details;
Pre-requisites
    – a flash file capable of sending cross-domain requests,
    – a 307 redirector page

To keep things simple, I uploaded both files to my own server at rootme.in. And, I used crossdomain.xml POC Tool by @IAmMandatory. In real attack scenario, however, everything would be automated and done in the background without any user-interaction.

Here’s what happens once a victim visits your site where you’ve embedded the flash file;

1. The flash file sends an HTTP request to a redirector with expected request headers & body parameters.
2. The redirector page issues a 307 redirect to vulnerable endpoint.
3. Following the redirect, another HTTP request is made with HTTP request message as it appeared in original request.
4. Since it’s a cross-domain request, flash also issues a request to crossdomain.xml

By the time flash receives response of crossdomain.xml, the attack is already completed.

Though, it’s not something new, I haven’t seen any report or anything exploiting this fact. Also, the flash issue that allowed setting custom-header in cross-domain requests seems fixed.

REFERENCES
http://help.adobe.com/en_US/as3/dev/WS5b3ccc516d4fbf351e63e3d118a9b90204-7cfd.html
http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/2011-February/007533.html

Add Comment

Required fields are marked *. Your email address will not be published.