Preventing CSRF when vulnerable to XSS

*The following code and concepts should be considered highly experimental and should be considered a work in progress. Not to be used for production websites.*

Web Worms (like Samy) targeting social networking websites (like MySpace) typically involve combining two attacks, Cross-Site Scripting (XSS) and Cross-Site Request Forgery (CSRF). An attacker posts JavaScript Malware (Web Worm) to their user profile web page because the website allows user-supplied HTML and the input filters didn’t catch the offending code. When a logged-in user visits the infected profile web page their browser is hi-jacked (user XSS’ed) to “friend the attacker” and post of copy the Web Worm code to their profile (user CSRF’ed) causing self-replication. There is no “Cross-Site” as part of the forged requests as CSRF implied, but that conversation is for another time.

As was case for MySpace and many other website, important features such posts to a user profile and friend’ing users, are protected from CSRF using session tokens embedded in URL’s or HTML Forms. Requests aren’t valid without a token. To defeat the CSRF solution, Web Worms first request a third-party page (on the same domain) to get a valid token and use it as part of a forged request. Since the attack is on the same domain, access to session tokens is can be easily achieved. This is why many people, including myself, have believe that CSRF solutions can be defeated when XSS vulnerability exist on that domain. However, there may be something we can do.


Without using browser exploits, JavaScript only has a few ways to access HTML data from another page on the same domain. Generally speaking, if we can prevent JavaScript on an XSS’ed web page from being able to read in session tokens from other pages, we might have something worth pursuing.

XMLHttpRequest
window.open
IFrame

If we can remove access these API’s, we may be able to prevent or make it harder for JavaScript Malware to bypas CSRF security. Enter prototype hijacking. The following proof-of-concept code effectively does this when called first at the top of the web page.

PoC Code is (Firefox ONLY!) Should this method be found workable, we can port examples to other browsers, namely Internet Explorer.

1) XMLHttpRequest

The Samy Worm used this method. This following function overwrites the XMLHttpRequest constructor so it has no functionality of any kind.

function XMLHttpRequest() { }

By calling XHR after this point:

var req = new XMLHttpRequest();
req.open('GET', 'http://website/', true);

Results in the following error message:

Error: req.open is not a function

I’ve not been able to find a way to restore XHR’s functionality


2) window.open

A Web Worm could feasibly open a small, but hidden new window and read the session token out of that. Impose the following line:

window.__defineGetter__("open", function() { });

By calling window.open after this point:

window.open("http://website/",null,"");

Results in the following error message:

Error: window.open is not a function

Again, have found no way to restore window.open

3) IFrame

There are a couple of ways to create IFrames from JavaScript, createElement and document.write. Overwriting these constructors is the same as the previous examples.

document.__defineGetter__("write", function() { });
document.createElement = function () {}


There are a couple of things to note here:

• Any mechanism I have missed, the constructor should be able to be overwritten.
• The model break down if the XSS'ed web page requires any of these constructors.
• I have not yet explored if Flash, JScript, VBScript can be used as a substitute for JavaScript to retrieve session tokens.

Like I said, a work in progress, but fun none the less :)