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;

fetch('//', {method: 'POST', credentials: 'include', headers: {'Content-Type': 'text/plain'}, body: '{"foo": "bar"}'});

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;
– 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 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.


Show Comments