
Youtube comments susceptible to XSS - DanBlake
http://www.reddit.com/r/programming/comments/cluc5/html_injection_vulnerability_in_youtube_comments/
======
chime
XSS is such a huge deal and yet I don't understand why browser makers/w3c etc.
haven't agreed on any solutions yet.

a. Have a meta-tag (or something in the <head>) that says: do not allow in-
line script tags on this page. Only run scripts from external .js files. No
onclick/onmouse code allowed in HTML.

b. Have a <noscript_within> tag that tells browsers to completely ignore all
in-line script tags (including onclick code) within the tag. That way sites
can allow all HTML within the <noscript_within><div
id="comments">....</div></noscript_within>

NoScript sounds like a better and better option these days. I already use
FlashBlock to protect against 0-day Flash vulnerabilities.

~~~
sounddust
I doubt it's as easy to resolve as you think...

a. That would barely mitigate the problem; it might stop some of the goofy
alert() hacks from people messing around, but the others are just going to use
the exploit to include an external .js file. Even if your meta-tag would
require all JS code to be in the <HEAD>, someone could have used this exploit
to create an iFrame which then contained the JS. Or create a meta-refresh tag
that redirects to the page with the exploit. The possibilities are endless.

b. If someone figures out how to break the character escape jail, then they're
going to be able to write a </noscript_within> tag.

~~~
chime
If a user can do an alert(), they can pretty much do anything. JS has no
security-levels except domain restrictions.

> someone could have used this exploit to create an iFrame

But this exploit wouldn't even run. My browser would only run JS on
youtube.com from external JS files. YouTube devs could put <script> within
their php pages and it would do nothing, let alone random users putting
<script> tags in comments. Only way to run ANY JS on youtube.com would be to
load an external .js file. If this meta-tag was present, you cannot load an
external JS file unless it was defined in the <head>. I really fail to see a
way to break out of this shell. Adding a <script>, <meta>, <link>, <head> tag
below the initial <head></head> would not work if this mode was turned on.
Well-designed sites don't add meta/link tags outside of the <head> anyway. So
I don't think it is asking for too much.

> If someone figures out how to break the character escape jail

I agree but that is almost certainly preventable. Right now, JS can be
introduced via so many ways (<script>, on-events, javascript:) and web devs
have to protect against all of them. I remember in one of the MySpace XSS
attacks, IE allowed "<scri\npt>" to execute despite the new-line. Browsers
will look for string <noscript_within> as start and </noscript_within> as end.
So will web-devs. No partial-lines, no attributes, no nothing. RegEx doesn't
fail.

~~~
sounddust
The point I'm making is that it's not as easy of a problem to resolve as you
are claiming. The problem is that - as you said - there are so many different
XSS vectors in the browser; if you patch one specific use case then the
exploiter will just find another. Browser developers aren't avoiding this
problem; they just realize how complicated it is and have to approach it
slowly to do it right, and to not break compatibility.

Your <noscript_within> tag is something that I'm sure every browser developer
(and web app developer) has thought up at some point. It does not resolve this
problem. It would only protect a site in the case that a website allowed _all_
user input to be passed directly onto the page unedited. Your solution would
require app developers to allow commenters the full range of HTML (including
blink, marquee, and who knows what else) in their comments. Because once the
app developer starts to try to filter the commenter's input, he's opening
himself up to an exploit that allows the filtered output to contain a
</noscript_within> tag.

The simplest example would be an app developer who simply deleted all
<marquee> tags because he/she wanted to disallow marquees. The script kiddie
would just insert </noscript_<marquee>within> into his comment.

The more complicated examples would be things that neither you nor I have
thought of yet.

That doesn't even take into account the exploit of users in legacy web apps
who could potentially start passing in unclosed <noscript_within> tags (in
apps which allow HTML but filter only certain tags) to disable legitimate JS
later in the page, breaking the apps. Of course, it would be possible to only
enable <noscript_within> based on doctype or something else, but then it's
certain that some web developers will accidentally forget to do so and leave
their app open to abuse.

You are oversimplifying the problem. I am sure that a solution exists and XSS
will eventually become a problem of the past, but the solution will be more
complicated than you claim it would be.

~~~
chime
Forget (b). I get that it may not be perfect. Why do you think (a) wouldn't
work? It is as simple as disabling JS on the HTML pages. That works on all
browsers already. Let's keep that + enable JS from .js files. I understand it
is more complex than I'm making it out to be but isn't that better than XSS
error on the world's largest sites?

~~~
sounddust
The implementation of a) would be extremely complex from both a web developer
and browser development viewpoint.

From the web developer perspective: It's very hard to use JS without putting
at least _some_ javascript in the HTML. Loading js files is not very useful if
there's no means to actually activate any of the functionality of those files.

In order for your idea to work, you'd have to completely strip all HTML of
anything that can reference or activate javascript: not just mouseover, but
also href="javascript:xxxx()" as well. That means that the _only_ way you
could actually use javascript on a page would be to create a function that
would be loaded by body_onload to add event listeners and other attributes
through DOM manipulation. It would make web development so convoluted that I
doubt that you'd succeed in convincing w3c or anyone else to adopt it.

I think the right approach has to maintain the workflow and functionality of
web development. tptacek posted an idea in the other thread that sounds like
it would reduce the number of attack vectors without causing too much
difficulty to the developer: include a nonce in the header and require script
tags to include that nonce.

------
ComputerGuru
Solution: Do away with YouTube comments altogether. They're such a brain-drain
as it is.

Come to think of it - no longer needed. Just use YouTube Feather (beta) to
disable comments on the site: <http://www.youtube.com/feather_beta>

~~~
oscardelben
It's not enough apparently, the name of the video is also vulnerable.

------
Indyan
Google's official statement: "We took swift action to fix a cross-site
scripting (XSS) vulnerability on youtube.com that was discovered several hours
ago. Comments were temporarily hidden by default within an hour, and we
released a complete fix for the issue in about two hours. We’re continuing to
study the vulnerability to help prevent similar issues in the future."
[http://techie-buzz.com/online-security/youtube-hack-
update.h...](http://techie-buzz.com/online-security/youtube-hack-update.html)

~~~
cracki
that "official statement" is not sourced by techie-buzz.com. where did they
get that from?

~~~
studer
From "Jay Nancarrow, a spokesman for Google", perhaps? That's a real person.

------
oscardelben
they disabled comments, but I just read this on /b/:

Create video response Name of video = script of choice ??? WORKING, VERIFIED
AND UNABLE TO BE FIXED EASILY BY YOUTUBE.

So stay away from youtube for now

------
Indyan
To make things even worse, those bloody 4chaners are already aware of it.
<http://boards.4chan.org/b/res/247794166> (Warning: That page triggered
several alerts for drive-by malware downloads (Kaspersky))

~~~
TeHCrAzY
Don't waste your time linking directly to 4chan posts, especially on high
traffic boards like /b/. It only keeps a certain number of threads up at one
time, ones that stop being replied to will scroll off the end of the queue and
be nuked.

------
joeyh
One thing I find interesting about youtube's response is they are reportedly
going in and removing <script> tags from already posted comments. So.. do this
mean they sanitize comments at post time, rather than at display time?

------
nphase
And just when you thought youtube comments couldn't get any trashier.

------
steveitis
When I did this same shit to Reddit a year ago (during the time they were
doing it to Sears whilst crying 'I'm being oppressed!) they all called me an
asshole.

[http://www.reddit.com/r/reddit.com/comments/9cvvp/why_it_was...](http://www.reddit.com/r/reddit.com/comments/9cvvp/why_it_was_a_good_idea_to_remove_the_sears_post/)

Now it's because everyone at Google sucks, and this is some unforgivable sin
on the content providers behalf, not the jerk users who are exploiting it.

Fine internet. Have it both ways.... Sigh.

------
tszming
Now, the hole was blocked by displaying "Error. Try again"

