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.

Watch Out For Suspicius Links

As part of our recent research on CSRF attacks, Russ McRee found a vulnerability in the Linksys WRT160N router. Sadly, this wasn't a huge shock to us, but what was surprising was the response from Linksys:

We can’t reasonably prevent CSRF's without bogging down our code. The compromise we had made here is to have a timeout on the web interface, so users are logged out after 10 mins of inactivity. We have also advised users to not click on suspicious links while logged in to the web interface, or close the web interface as soon as they are finished configuring the router

As ridiculous as the entire response is, I'd like to focus on the "Don't click suspicious links" bit. Most users will click on any link you throw at them, particularly from link-heavy social sites such as Twitter. In fact, if you clicked through to this page from my Twitter post, the page you're currently on should be at "http://skeptikal.org/a_very_suspicious_link."

Why did you click it?

Because you trust me. And you trust Twitter. And you trust my hosting company. And your DNS servers. And my DNS servers. And TinyURL.

I could rant on this topic for a while, but I know I'd be preaching to the choir. Don't trust any links, anywhere. Especially don't trust the ones from TinyURL, bit.ly, or any other URL shortening service. You have no way of knowing whether a site is malicious or not until you load it into your browser. Even then, it's doubtful that you'd ever notice. You're probably not a normal user, but most people wouldn't ever recognize real malware for what it is, especially if it's properly obfuscated.

In theory, a goal of never clicking a malicious link is impossible to achieve. In practice though, many malicious links are fairly easy to recognize if you just look at the URL. This is why sites like TinyURL allow you to preview links before being redirected to them. Earlier today, @OWASP_podcast sent out the following tweet:

http://tinyurl.com/preview.php?enable=1 will force all TinyURLs to appear in preview mode on your machine.

It's a good idea, but this is clearly a URL that modifies user preferences based on GET variables, and I couldn't help noticing that the same preference could be disabled with a bit of CSRF:

<img src="http://tinyurl.com/preview.php?disable=1">

I'd call this a failure on TinyURL's part, but even if you did preview the URL, there's no guarantee the seemingly innocent link won't have malicious content, redirects, cross-site scripting, HTML injection holes, poorly configured DNS, poorly coded flash files, content ownership problems, compromised FTP accounts or other issues.

Just keep that in mind- previewing a link is a convenience, not a security feature.