Cenzic 232 Patent
Paid Advertising
web application security lab

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.

12 Responses to “JavaScript StarWars”

  1. Myspace Codes » Blog Archive » JavaScript StarWars Says:

    […] Original post by RSnake and software by Elliott Back […]

  2. unsticky Says:

    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.

  3. unsticky Says:

    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’;});

  4. nEUrOO Says:

    Well, why not using HttpOnly cookies?

  5. Jeremiah Says:

    unsticky, exactly!

    nEUrOO, because FF doesn’t support HttpOnly.

  6. unsticky Says:

    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…

  7. kuza55 Says:

    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

  8. Jeremiah Says:

    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.

  9. Wladimir Palant Says:

    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

  10. RSnake Says:

    @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?

  11. kuza55 Says:

    I know, I agree the attitude was quite unnecessary but I over-reacted, I apologize.

  12. RSnake Says:

    Thank you, Kuza55, I appreciate it, and your apology is accepted. :)

    Nuff said, back to work!