JavaScript StarWars
Jeremiah and I have been talking the last few days about some code he was developing to attempt to stop large scale XSS worms. As a result of his research he came up with a few experimental code snippets for Firefox. Very interesting stuff. It shows how JavaScript can be used to protect itself as sort of a defense in depth strategy for when your inline XSS filters fail you, or when your website (like MySpace) is eternally riddled with XSS holes due to having to use HTML
Jeremiah lists a few words of caution when using this code, and I’d like to add one to the list. The mhtml vulnerability is still out there and using it can easily circumvent this, by including an iframe to a remote site with this malicious code. In Jeremiah’s words, “everything breaks down completely with [browser vulnerabilities]”. He’s exactly right. So experimental, yes, neato, yes. I’m sure there is lots more research to be done, and I’d be curious to hear of anyone able to undefine his __defineGetter__ functions.
January 22nd, 2007 at 4:08 pm
[…] Original post by RSnake and software by Elliott Back […]
January 22nd, 2007 at 4:58 pm
Expanding on Jeremiah’s idea, why not have document.cookie return either a null value or some fake string? I don’t know of much of a use for document.cookie from a web-programming stand point, with the server side languages, of cource, being able to access cookies as well. So by ‘disabling’ it, you’d cut down, if not wipe-out, account credential theft.
January 22nd, 2007 at 5:01 pm
Forgot to through the code in so it looked more like I knew what I was talking about…
document.__defineGetter__(”cookie”, function() {return ‘fake=value’;});
January 22nd, 2007 at 5:14 pm
Well, why not using HttpOnly cookies?
January 22nd, 2007 at 5:15 pm
unsticky, exactly!
nEUrOO, because FF doesn’t support HttpOnly.
January 22nd, 2007 at 6:49 pm
The only way I can come up with to stop the defineGetter idea is if the XSS injection point is before the calls to __defineGetter__ to shutdown the ‘worm-related’/unneeded functions. If it is, you can set document.__defineGetter__ as an empty function, or even turn it into the worm itsself…
January 22nd, 2007 at 9:49 pm
I can’t be bothered thinking up a nice comment. Redeclarations can be removed by using the delete operator. Rant is here: http://kuza55.blogspot.com/2007/01/dont-we-have-memories-for-reason.html
January 22nd, 2007 at 11:14 pm
unsticky, that would be one major requirement, the protection JS code must be called at the top of the page so it runs first. Easy enough.
January 23rd, 2007 at 4:41 am
Too bad it doesn’t work. I left a comment on this in Jeremiah’s blog: http://jeremiahgrossman.blogspot.com/2007/01/preventing-csrf-when-vulnerable-to-xss.html#c8467433620118299973
January 23rd, 2007 at 2:33 pm
@Kuza55, believe it or not I tried that exact code snippet you had on your blog, but for some reason it didn’t work for me (I do have a memory, believe it or not). But I just tried it again and it didn’t work (again) but I realized I had JS turned off. There is a chance I was testing without JS turned on yesterday, which would be why it didn’t work for me.
Also, you should be aware, that I had (looking back at my chat logs) from 9:01AM to 9:15AM (14 minutes) to test this yesterday morning while doing a bunch of other things. So I appreciate you bringing it to my attention, but the attitude is a tad unnecessary. I have plenty of opportunities to harp on almost everyone who visits my site for their ignorance or mistakes, but I prefer to avoid going down that path. There’s enough attitude in security as it is, I don’t want it on my site. Save it for the newbs, kay?
January 23rd, 2007 at 3:18 pm
I know, I agree the attitude was quite unnecessary but I over-reacted, I apologize.
January 23rd, 2007 at 3:23 pm
Thank you, Kuza55, I appreciate it, and your apology is accepted.
Nuff said, back to work!