XSS vulnerabilities are often underestimated, but they can sometimes be extremely dangerous. It looks as if couple of hours ago attackers started exploiting what looks like a stored XSS vulnerability on YouTube.

I don't want to go into details on how to exploit it until YouTube fixes it, but it indeed looks pretty widespread already. So far, all exploits I've seen just enter some benign HTML and are more of comment spam, but as this appears to be a full-fledged vulnerability things could get out of control easily unless this is fixed.

What could an attacker do? Well, they could steal your YouTube cookies, which probably doesn't mean much to them, but they could also post various JavaScript code that will execute in your browser, in the context of YouTube. I've seen nasty XSS attacks that are used to fake whole login screens and we know how many people use same passwords for multiple accounts.

We'll keep you informed on the development of this.

UPDATE

We received a lot of questions from our readers asking details about the vulnerability. Now that Google patched it, we can explain how it worked.

Stored XSS vulnerabilities allow an attacker to store valid HTML/JavaScript/VBScript code in the system. This is most often done through comment systems, such as was the case with YouTube, but can be in any field that the attacker can edit. For example, if you let a user enter his first and last name, and you don't properly filter/encode this data, once it is displayed back arbitrary script code can be executed. This is, obviously, particularly dangerous if an administrator is viewing attacker's profile as the script code will be executed under privileges of the administrator.

The backend comment application used by YouTube incorrectly encoded output data – only the first entered tag was correctly encoded, so by supplying the comment with two <script><script> tags, the browser would get back the following: &ltscript&gt<script>. We can see here that the first tag is properly encoded and will be displayed by the browser as it is supposed to, but the second tag actually starts script code.

This incident shows how important it is to properly check every single point of your application that receives data from users, or displays it back to them. Besides correctly encoding data that is sent back to the browser, the script could have been fixed by also properly encoding data immediately after receiving it from the user.

Luckily for Google, the vulnerability has only been abused by various users to "hide" other comments – they weren't really hidden, they just weren't displayed because the rendered HTML  code was broken due to supplied malicious code.

As I said in the initial diary, vulnerabilities such as this one must not be underestimated. While typical examples of XSS vulnerabilities just show you how to popup an alert window, stealing cookies is just the first step – remember that by carefully crafting JavaScript code that will be executed in the browser, the attacker can show whatever he/she wants and this include much more than stealing cookies; it is actually pretty easy to display fake login forms that will look completely legitimate to users.

Before ending this diary, below you can see a screenshot of one exploit of YouTube that didn't just "hide" comments but also displayed a popup to the visitor.

--
Bojan
INFIGO IS