Q and A on cross site request forgeries and breaking into sessions. It's one of the attacks that XSS enables and the attack of the future. For Session, fixations, hijacking, lockout, replay, session riding etc....

This seems to be an interesting area. I have a feeling some of the javascripts being used by the xul's in firefox and some plugins might be vulnerable to some dom based xss or other stuff... but in order to leverage an attack using these, we'll have to be able to force firefox to load chrome urls through csrf or javascript or something. Of course there is a restriction here. Has anyone done any playing with this?

If you look real closely you'll see that the xul's loaded through chrome:// can call chrome:// urls using iframes and (maybe, but i havn't seen any yet) other methods. Well, if they can do it why can't we? It must be aware of its chrome:// context somehow... I tried a few things... like loading chrome://browser/content/browser.xul up in firefox and then in that second browser trying to do a javascript:document.write('<iframe src="chrome://...">'); ... haha, I thought I might be able to fool it into thinking it was being called from chrome:// but that didn't work.

If anybody gets anywhere with this, here's an idea for a poc:

the following chrome urls crash firefox when loaded (this will crash firefox, careful)

I think these are deprecated menu's that no longer function, not sure tho. Regardless, they crash firefox. You could quite easily DoS any firefox user with javascript/csrf link if you could load those urls. ;/

Its a design feature of Firefox that you cannot initiate contact with chrome:// space, but chrome;// space can initiate contact with pages. If there was ever a way around this it would be patched fairly quickly.

So by all means look, but the moment someone finds a method (though considering this was specifically designed in, I'm not expecting anything), the mozilla devs will jump on it and fix it, because there are a bunch of issues being protected by this.

Yeh exactly kuza55. I've been auditing the Firefox code for about 3 months in 2006 and it's hard to find new entry points. There where some serious flaws which resulted in local file execution but that was quickly fixed.

I haven't really played with the chrome URIs, but I did find that Internet Explorer 7 includes three protocols that can be called via script, and simply cause the browser to crash almost immediately.
IE.FTP://
IE.HTTP://
IE.HTTPS://

Never seen those before. Odd. It would really nice to come up with a definitive list of all the protocol handlers for each browser and how they map across, if at all. If someone wants to write it, I'll host it with credit. It's just tiresome that we don't have a good thorough list. I've seen good (long) lists for single browsers - like Ronald's program that I am now forgetting the name of, but it's not clear which browser it belongs to, if at all (like scp://).

Right, that's exactly what I was talking about - while good, it doesn't separate them out into the various browsers and doesn't talk about what each of them are for. I'm picturing a table that we can look at at a glance. Something like this: http://ha.ckers.org/charsets.html

@Ronald browserfry.0x000000.com
IIRC konqueror has much more schema support, i.e. svn: svn+ssh: ipp:
somewhere I've seen jar:
also javascript: seems to be supported by most common browsers, while IE has VBscript: too
You may find more here:
http://www.w3.org/Addressing/schemes
http://esw.w3.org/topic/UriSchemes