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

This entry was posted in Vulnerabilities on by .

About Johnathan Kuskos

Johnathan Kuskos is an Application Security Engineer for WhiteHat Security's Threat Research Center in Houston, Texas. He received his B.S. in Computer Science and accompanying Mathematics minor from University of Houston - Downtown, and is looking forward to continuing education with a Masters in Cybersecurity. Outside of WhiteHat, he has contributed to responsible disclosure for Netflix, Etsy, Barracuda Networks, LastPass, Google, Meraki, Nokia, and Mozilla.