Stored XSS vulnerability on YouTube actively abused?

Published: 2010-07-04
Last Updated: 2010-07-05 17:50:22 UTC
by Bojan Zdrnja (Version: 2)
7 comment(s)

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.


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.

Stored XSS on YouTube


Keywords: xss youtube
7 comment(s)


How will this impact users who use their Google accounts to login to YouTube? Sure, your YouTube cookies don't mean an awful lot but I'd assume the Google Accounts (being linked to gmail addresses) are a more valuable target? Or would these cookies not be sufficient enough to compromise an account?
There is no impact to Google accounts. If you steal YouTube cookies you won't be able to access any other Google hosted stuff since it's in a different domain and the SSO system in place relies on the main domain.
Many people have their credentials in their browser. XSS can extract those easily.
Now that the vurnability has been patched, could you go into more detail about it?
I also wanna know in detail about XSS attack code.
Guess this proves what Microsoft has showed us the last years; errors are human and will always exist.. Holistic web-security should include web-filters that verifies the content before they are handled by the app.servers...
The update and explanation given here is quite good. There is another article technical describing details of this attack:

Diary Archives