Cenzic 232 Patent
Paid Advertising
web application security lab

XSS Cheat Sheet Errata

I just made three quick changes to the XSS cheat sheet as pointed out by Andrey Bayora. It looks like I made three typos in the event handlers (it’s weird no one else noticed for the last year and a half - including me!) Here are the typos that I’ve corrected:

onRowDelete() should have been onRowsDelete()

onRowInserted() should have been onRowsInserted()

onSynchRestored() should have been onSyncRestored()

So if anyone wrote filters based on those exact strings they should probably update them to match what they really should be. I haven’t seen these used in any actual attacks, but I wouldn’t risk it. Thanks to Andrey!

6 Responses to “XSS Cheat Sheet Errata”

  1. ChrisP Says:

    Speaking of the cheat sheet, I was playing around last week with numeric character references in HTML. My hope was to build a regex that would catch all variations of “

  2. ChrisP Says:

    Argh - I entered an open angle bracket &lt in my previous post and your input filter caught it ;)

    I was saying that to my surprise, a browser (Firefox and IE latest) happily considers &#60 equal to &#000000000000000060 - as a matter of fact, insert as many leading zeros as you’d like.

    I can see why it’s mathematically correct, but why math rules apply to numeric character references I’m not too sure.

    So it sounds like the XSS cheat sheet section should say &#0*60 is a valid representation of the open angled bracket. Would you have any insight into why it’s accepted? Why would a browser want to accept more than say 4 bytes of reference, even if those bytes include leading zeros?

  3. .mario Says:

    Interesting point ChrisP - didn’t know that. Will update my filter rules immediately ;)

  4. RSnake Says:

    I haven’t seen it accept that many leading zeros in my testing. Which browser did you test that with? The maximum length I’ve seen is 7 chars as mentioned here: http://ha.ckers.org/xss.html#XSS_Long_UTF-8_Unicode

    But I also was only testing how it could create an XSS attack, not how it could be represented on the page.

  5. Ronald van den Heetkamp Says:

    Makes me wonder RSnake: There are quite some more Javascript properties and function. Not that they directly utilize XSS, but one can build upon them to bypass filters. I haven’t seen a place which explains such thing yet, you know thing like:

    doctype = document.doctype;
    charset = document.defaultCharset;
    activeElem = document.activeElement;

    Which could be useful in some situations, like propagating worms on their own. I’m researching this stuff since a few days, and there are a lot of other nice functions to use.

    Anyway, it was a thought I had just now ;)

  6. Ronald van den Heetkamp Says:

    @ChrisP

    That is correct, in fact they are not read e.g. it skips to the 60 on the first null that is found. Thereby you can add as much as you like, doesn’t make a difference. :) But, it could come in use to bypass filters.