Summary

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).

Impact

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

Details

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

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 ‘www.nccgroup.trust’ website as an example:

This page has been saved here: http://15.rs/sdl/custom-header-test.html

After loading the above HTML page in a vulnerable IE (or Edge), first it sent a POST request to ‘http://15.rs/sdl/redirect.php?rdir=https://www.nccgroup.trust/&rdircode=307’ with custom headers then redirected the whole message with its custom headers and body to ‘www.nccgroup.trust’.

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"’.