Parsing Quirk Causes bit.ly XSS

Fun fact: When your browser parses a document, it locates <script> and </script> tags before evaluating the javascript within. While this appears to make sense, it creates an interesting quirk- injected </script> tags, even within quoted javascript strings, will force it to end a block of javascript code and throw a parse error. It will also allow you to start a new block of unquoted (and therefore, executed) code.

I put together a basic demonstration of this quirk a while ago and bounced it off a few people. As it turns out, this is known behavior, and was even used in one of the first examples on RSnake's XSS Cheat Sheet.

Arguably, this is not really even a bug. It stems from the order in which the document is parsed- structure (tags) is handled before parsing javascript content. I looked into the various standards that apply and didn't see anything dictating how this behavior should be handled, but I confess I didn't look that hard.

At any rate, the reason I'm writing about it today is because I found an XSS hole in the popular URL shortener, bit.ly. This can be used to compromise browsing history, tamper with a user's bit.ly settings, and even abuse Twitter accounts (they have a Twitter API).

Due to the nature of the exploit the link only works once, so I can't send you directly there. However, if you take the following URL and make "CHANGEME" a unique string, it should work.

http://bit.ly/?url=http%3A%2F%2Fskeptikal.org&keyword=%22%3C/script%3E%3Cscript%3Ealert(1337)%3C/script%3ECHANGEME

While it's generally known that putting user-supplied input into executable code is a bad idea, many developers still do it, especially with javascript. Don't assume that just because the input is wrapped in quotes, it will not be XSS-able.