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.
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.
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.
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.
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.
Lots of sites use Google's CDN so it's very likely the file is already in your user's cache. That seems like a nice little speed bonus if the only trade off is the theoretical risk that Google's CDN might be more easily hacked than your own server.
As an aside, I notice on my site there are a few precent of visitors with security settings on their browser that prevent loading from Google's CDN (actually, there's usually an internet security product of some sort interfering). So you're going to have to provide a fallback to a file on your own server anyway.
Of course! Your whole app is hosted on your server, you're already hosting a bazillion images and other files, including scripts and CSS - if your server is compromised it won't matter much whether your jquery.js is safe or not. Also, aside from security concerns, you're adding an unnecessary single point of failure to your project.
Sure, CDNs are advertised as super reliable and stable and whatnot, but all services go down once in a while. As with every monoculture, there will be large scale outages. It's something developers would be better off acknowledging and planning for upfront instead of having a heart attack whenever a service goes down "unexpectedly".
There is a way to fall back to locally hosted version in case the primary one goes down. Still not convinved I should give up on the speed bonus a precached asset gives me.
Thomas wasn't really discussing about this in regards to the external CDN going down he was discussing it in regards to the CDN being a large point of attack with little benefit to your speed increase.
Look at it this way: if google's jquery is attacked and becomes compromised you and everyone else who uses it has become compromised because you were relying on third party security.
Next if you use jquery from google's cdn for the reason of they can do file security better than you you are already fucked because if someone is targeting your specific jquery hosted on your server chances are you are compromised in other ways.
If you want to use it for the precaching you can but I don't think precaching the 100kb jquery is really going to give you that much benefit in the long run, especially if your website is an application or something along those lines.
The worst offenders here are those who host their jQuery and offer it to others on a domain that is also being used to host other web applications.
For eg. company xyz.com is a hosting company, but it also offers jQuery and other javascript at cdn.xyz.com.
A client of the company at client.xyz.com is setting a cookie for its users but sets it as xyz.com. Now everybody else that is using cdn.xyz.com will also see those cookies.
One example of this is the cloudflare CDN[1]. All of their clients and all of their hosted javascript is on the same domain. Test it out by checking the cookies your browser sends along[2], I see random Techcrunch cookies (they used cloudflare on a site)
I think it's important to also notice that attackers (most recently Duqu) are increasingly often using valid certificates. The more parties you trust, the easier it is for an attacker to find a weak link.
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. :)
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.
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.
That is a massive hole. Very nice find. I hope you notified the ad network of this before you posted it though, responsible disclosure of these things is important because this hole can now be used by anyone to do pretty much anything. The most obvious thing that comes to mind is a spammer using this to redirect traffic through a third party domain which is whitelisted.
They were a bit lacking in an obvious right person to email[1], but I did send a quick "hey there's a problem" note. I almost didn't when I saw that their main "contact us" page was a "opt in for us to email you" form, but then I found some actual email addresses rather further down.
Past experience dealing with ad networks about this issue has led me to believe that they really don't care.
Multiple networks, multiple framebusting scripts they want you to host, all with blatant security holes that they don't want to fix after you (as a client) point them out.
Or maybe it's that the people in the organization who might care are completely insulated from the channels available to people who are dealing with the network as a client. Hard to say.
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...
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.
You're much more likely to get in trouble with the law yourself than gain any benefit out of the situation. IT departments will be quick to blame a "hacker" instead of themselves for the vulnerability.
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.
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.
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.
I hope not. He hasn't done anything at all. Unless its used maliciously. Like, if he went into CNN comments and posted a link that forced users to repost his comment, steal passwords, etc... Otherwise this is almost like me telling you to post javascript:alert('you are ugly'); in your browser.
That's a point that can be very expensive to make. The line is blurry. You're unlikely to cross it testing for XSS (particularly this reflected stuff). But it can be easy to cross it looking for (and, particularly, at) SQL injection or authorization bypass.
You should be extremely cautious testing other people's sites for security vulnerabilities.
Hmm, what crime would that be? He has not sabotaged anything on the vulnerable websites, he has not used it to gain access to any data, and he has not used it to impersonate or trick anyone.
I'm reading the laws now... It seems that "unauthorized access" itself, may be a crime which he has committed? Also, the laws vary by state and I'm having trouble figuring out what the federal laws are.
Obviously, he didn't commit any fraud or steal any information, and I can't imagine anyone would want to prosecute him.
edit: it looks like he's probably relatively in the clear on this? Most of the laws seem to require intent, fraud, or thievery. It's all very confusing.
edit 2: downvotes? I'm sorry for worrying that our laws and legal system sucks?
A lot would depend on how "access" is defined, I imagine.
What I did was provide input to a publicly accessible script on their server. I didn't have to "break in" to anything to do so, or to find out about it. So it'd hinge on whether or not using someone's website in a way they didn't intend you to counts as being "unauthorized access".
Possibly but I doubt it. He has only made people access their own web browsers, so while there might be a case for unauthorized access it seems very weak to me.
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.
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.
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.
It's been awhile since I played with it, but I believe there's a legitimate reason for breaking the <script. Possibly one of the older browsers had a broken parser that would interpret that as the beginning of a new script tag?
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.
The session id is stored in the cookie. if you can read that, then you can convince the website that you are that user, and hence do (just about everything (depending on how often the website asks for password)) that that user can do on that website.
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.