Vulnerabilities

The Case of an Unconventional CSRF Attack in Firefox

It appears that an unconventional method of Cross Site Request Forgery may be made exploitable by using Firefox versions 21 and below. The exploit requires that the target application be first vulnerable to HEAD request verb tampering, which is where a HEAD verb(also commonly known as ‘method’) is supplied in place of a GET or POST, and is successfully processed by the application. Once this is found, an XMLHttpRequest(commonly abbreviated to ‘XHR’) request can be sent from an off-domain location with the .open() method invoked and HEAD supplied as the verb.

The XMLHttpRequest Living Standard specifications can be found here and defines how XHR objects should be used. Although there are many rules, steps 3 and 4 of the .send() method serve particular interest to this implementation error:

.send(data);

3) If the request method is GET or HEAD, set data to null.

4) If data is null, do not include a request entity body and go to the next step.

Consider the following very basic and elementary Proof of Concept:

<script>

var xhr = new XMLHttpRequest();

var url = “https://www.whitehatsec.com”;

var data = “foo=bar”;

xhr.withcredentials = true; //Allows for sending cookies with the request

xhr.open(“HEAD”, url, true);

xhr.setRequestHeader(“Content-type”, “application/x-www-form-urlencoded”);

xhr.send(data);

</script>

If you monitor your traffic or catch this in an intercepting proxy, you will see a request being made to https://www.whitehatsec.com with post data “foo=bar”, even though the request verb is HEAD. According to step 3 above, ‘data’ should have been set to ‘NULL’. This behavior seems to only occur in Firefox; The latest versions(as of this writing) of Internet Explorer, Chrome, Safari, and Opera are all successfully practicing proper .send() implementation.

I notified Mozilla of this behavior and a patch has been implemented into version 22 that was released on June 25th, 2013, and only users using a previous version of Firefox would be vulnerable to this now. It requires a bit of a “perfect storm” scenario, but could be extremely damaging depending on the context of the vulnerable application. I’d like to extend a huge thanks to the Mozilla security team for the swift attention this received, as well as for allowing me to participate in the remediation process.

Mozilla Foundation Security Advisory 2013-54

Mitre CVE-2013-1692