Slashdot Mirror
New Firefox Standard Aims to Combat Cross-Site Scripting
Al writes "The Mozilla foundation is to adopt a new standard to help web sites prevent cross site scripting attacks (XSS). The standard, called Content Security Policy, will let a website specify what Internet domains are allowed to host the scripts that run on its pages. This breaks with Web browsers' tradition of treating all scripts the same way by requiring that websites put their scripts in separate files and explicitly state which domains are allowed to run the scripts. The Mozilla Foundation selected the implementation because it allows sites to choose whether to adopt the restrictions. 'The severity of the XSS problem in the wild and the cost of implementing CSP as a mitigation are open to interpretation by individual sites,' Brandon Sterne, security program manager for Mozilla, wrote on the Mozilla Security Blog. 'If the cost versus benefit doesn't make sense for some site, they're free to keep doing business as usual.'"
I really hope the default policy is "only allow scripts from the current domain" and "do not allow the site to override my choice".
As long as this isn't something that can easily be compromised then I think this is an excellent way of handling the problem.
"The Mozilla foundation is to adopt a new standard to help web site's prevent cross site scripting attacks (XSS). The standard, called Content Security Policy
Do you notice that name does not sound like the description? Why do they never call it what it is?
So does this mean we can't hack anti piracy organizations any more? http://torrentfreak.com/mpaa-website-now-with-torrents-090502/ http://torrentfreak.com/riaa-site-features-torrentfreaks-latest-news-090504/
A Magic the Gathering Article and Forum Aggregator
I will still run with noscript installed because I've yet to see a good XSS-preventing implementation that will allow *me*, as a user, to easily define what sites can run scripts on the sites I visit. And when I visit a site where I need to disable noscript, I have no other tabs/browsers open.
I'm sorry, but NO site can be trusted 100% from a user's perspective... and giving site owners the tools to help prevent XSS from their side doesn't help with the fact that users still shouldn't trust absolutely.
The reason something like this scares me is that it lulls users into a higher level of trust... and doesn't protect them from hacked sites, or sites that choose not to implement this.
Of course, I'm slightly paranoid. And of course, this isn't transparent to Joe Sixpack, so he's going to trust|!trust based on whatever it is he's basing it on now. And for security-critical sites like banks, this is a good thing... but I try very hard to make sure my friends & family are a bit paranoid too, so they'll take precautions.
"Trolls they were, but filled with the evil will of their master: a fell race..." -- J.R.R. Tolkien on Olog-hai
On the surface this sounds like a great idea. Sort of like SPF for JavaScript. Of course I'm sure that more knowledgeable folks than I will do their best to poke holes in it. I guess the other browsers will just ignore this unless of course they jump on board and implement it too.
Seems like they are trying to compete with IE http://blogs.msdn.com/ie/archive/2008/07/02/ie8-security-part-iv-the-xss-filter.aspx But on http://sla.ckers.org/ circumvention has already been found. XSS will always be around, because of dumb coders trying to re-invent the wheel, yet again.
If the cost versus benefit doesn't make sense for some site, they're free to keep doing business as usual.'
The author gave the best reason for not implementing this.
The benefits of this, and other various security implementations, won't be seen until it's tested. The costs of testing? Way too high compared to the current cost of operation. This is a very hard proof-of-concept problem, and unless this is already built into development standards, I doubt any deployments would switch.
Which would you take, the option which delays production for a week, or the option to just hit "next"?
Shameless self plug: I wrote about this in my column: Web security - Protecting your site and your clients in September of 2008 and I'm VERY glad to see this is moving forwards as it means I (as a site owner) can actually do something to protect my site and my users against flaws in my site that is relatively easy and non-intrusive (that's the key!). The thing I really love about this is if your clients don't support site security policy, things still work, and if your browser supports it but the remote web site doesn't, things still work, but if both ends support it you get a nice added layer of protection. What would be really wild is if Microsoft added support for it, although "not invented here" they have been making efforts to protect users from XSS attacks in IE8 with mixed success, so who knows. You can do similar things with mod_security potentially and outgoing filters but it is nowhere near as simple as site security policy should be to deploy (hopefully).
Instead of making me modify each file to send that header/meta tag, why not make it like the flash security files and just have a file in the root directory.
Don't let other people serve content via your site.
Don't rely on shitty plugins from security failures such as Adobe.
Don't depend on user-generated content, since it's shit. If your site can't provide it's own content, at least properly filter incoming user content down to plain ol' text.
Don't sign up with a shitty registrar who will transfer your domain/dns/mx records to some slut like godaddy at the drop of a hat.
Don't give people the password to your account at your host/registrar, and don't give people access to your fucking ftp/ssh/direct/etc. accounts for your server.
I know there's been a lot of dialogue between the authors of SOMA, which predates this, and the Mozilla team; it might provide some interesting context.
If you're having to modify individual files to set HTTP headers, you're doing it wrong. Also, polluting sites' namespaces (even worse than they already are with robots.txt/favicon.ico) is a bad idea.
But then, you already betrayed your cluelessness when you revealed that you put Flash on the Web.
Presumably the millions of adsense and publishers will have to enable their sites to maintain adverts..? Might hit google revs a bit...
The Cross-site Scripting (XSS) FAQ http://www.cgisecurity.com/xss-faq.html
Believe me, if I started murdering people, there would be none of you left.
What about IE, Chrome, Opera, and Safari users? As of now this solution only benefits a small portion of users. I don't see this being widely implemented at all.
The first trap you will fall into thinking about this is that it should be the end-all security policy, and will solve our problems. It won't. That's not the intent, and also impossible given our diverse browser ecosystem.
The ability to tell the browser, via out-of-band, non XSS-able information, that certain scripts should not be executed, however, is a very powerful defense in depth measure, and makes it one step harder for attackers to make an attack work.
Security is a war of attrition. Bring it on.
The summary is wrong, this is NOT a standard in any way, or even a proposed standard. This is a proprietary security feature being introduced by Firefox. I'm not saying this is a bad thing (it's not), or that this won't eventually become a de facto standard (it might). But it is not a standard.
More than a "Firefox standard", it seems to me that this is an extension. I'm all for it, but let's call things by their name.
To do list for Windows
just like they have forced the 'humongous, scary ssl warning error' instead of the previous acceptable and understandable error message. it forced a lot of small businesses who used the certificates they themselves signed to buy 3rd party certificates from vendors. again with this change, all small businesses will have to spend more on web development charges, because most end users will set their firefox to the prevent setting for this new feature. the 'free to do business is usual' bit is bullshit. remember, say the word 'security', and you can even sell wars to people. so dont feed the 'free to do business as usual' bullshit to anyone.
one thing that is most damaging to us open source crowd is being too self righteous and jacobin. it starts to hurt us again as time passes and projects develops. this time its happening with firefox.
Read radical news here
Is this 'standard' endorsed by anyone else or written up as part of an RFC? Calling something a standard when you are the only guys doing sounds like a certain company that was started by Bill and Paul.
I am not trying to troll here, since I am all for the solution, I am just ensuring that this properly documented and shared by the right entities (think W3C).
Jumpstart the tartan drive.
Just wondering, wouldn't this break a lot of bookmarklets since they are essentially javascript being run from a different location on the site. Correct me if I'm wrong (I probably am). Just wondering
This proposal looks like massive overkill to me. Implementing the restriction on inline script tags is equivalent to saying - our web developers are incompetent and naive and cannot be trusted to take basic security measures, so we feel making our web development practices more cumbersome and inefficient (if not impossible) is a healthy trade off.
A more effective program would be to develop and promote standardized html sanitization routines for popular web development languages, so that user entered html could easily be accepted under certain restrictions. Most web logs do this already.
Alternatively a less draconian solution would be to allow inline scripts to execute if the script tag includes a response specific serialization value that is also present in the HTTP headers. 64 bit values would make forging a inline script essentially impossible, because there would only be a 1/2^64 probability of a subsequent accidental match.
Obviously if a site does not contain one of these headers it will default to allow from all. Also called not breaking the whole internet with your new browser feature.
Come as you are, do what you must, be who you will.
CSP is effectively server-side NoScript. And it isn't exactly new either. This has been in development as a Firefox extension for at least a year. The article mentions it being first crafted back in 2005.
The issue I take with this article is that they suggest this feature could even possibly be integrated into eBay or MySpace. These two giants seem like the exact opposite type of market that would use this -- any site that allows users to post their own data is not going to possibly survive the wrath they would catch if users had to explicitly allow the domains they want scripts to run on. For a corporate Web site yes, but for something for the masses or those of us that run a CMS? I don't see that as happening anytime soon.
How would you pass parameters to scripts? How would you do AJAX or DHTML stuff based on realtime data? I suppose you could wrap everything in semantic classes and data attributes containing JSON, hell even Javascript, and then include an external script that evals them all. Inline scripting through the backdoor. Is that what they want us to do? Or have an extra Javascript file with every HTML file?
Why would anyone run cross site scripts *now*, except in clearly white-hat uses?
Please don't let this become the same horrors, that it is with plugins.
If you ever tried to add a applet or anything embedded into a site, that came from some other domain (like a mp3 stream), you will know what I am talking about.
It just gets blocked, except if you have a signed certificate and other shit, that you can only get for money. And then it is still a huge mess to set up.
In my eyes this stifled web technology quite a bit.
Additionally, what do you do, when you yourself have several domains and subdomains? Like a global domain for common things, like the base stylesheet and script libs, and a local domains, that use them. Etc.
It's good to make this safe. But it absolutely must be done right. Or else, there will be a giant mess. :/
Any sufficiently advanced intelligence is indistinguishable from stupidity.
So is there an official definition of "Cross-Site Scripting" somewhere? Since that phrase started to be used in scary security stories a few years ago, I've been collecting the definitions that various stories provide, and I've been a bit disappointed. Mostly, they aren't even "definitions", in the usual dictionary sense of the term. I.e., I can't use most of the purported "definitions" to decide whether what I'm looking at is an instance of the phrase. And in general, no two stories or sites seem to use similar definitions (when they actually give definitions at all).
My impression is that "Cross-Site Scripting" is an empty scare phrase that really just means "anything involving two different machines and a script -- whatever that may be".
So has some official organization defined the phrase? If so, what makes them an authority? And is there some way that I can tell when someone is using the official definition (if such exists), or should I just continue to view the phrase as an attempt to scare readers without actually informing them about the problem?
I note that the definition associated with TFA isn't actually a definition. And several other postings here have linked to sites that also give ambiguous non-definition definitions.
It sure seems there's something being talked about here, but it seems to suffer from the usual problem with security authorities, that they view me as an idiot who doesn't need to be informed about the subject matter; I only need to be scared (presumably so that I'll pay them to fix something that they've carefully made sure I can't understand clearly).
I'd think that security is an area where you'd want to be careful with your definitions and terminology. But apparently I'm wrong.
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
I'm a bit out of my league knowledge-wise here, but in my company I have a company web application that would benefit very much from being able to do something in the window of another site. Why can't a browser (not the web app) be set to very specifically allow a particular web application to make use of another specified website. E.g. that would allow me to fill out a form with data from the web app or vice versa to get data into my MySQL database without having to fill out the data manually, which is error-prone. Because it is a browser setting where both domains are set to specifically interact with each other, I don't see how it could be used to do anything malicious, but it would help web apps enormously.
Bert
Next step: educate PHP users so that they have a clue about security?
{{.sig}}
Well, it's about time somebody does something. For years JavaScript has been an on/off affair, and it's been driving me nuts both as a web surfer and a developer.
They can do whatever they want for Joe Average to ensure advertisers won't complain, but please, can I have the ability to allow scripts to run only from the same domain as the originating page? Please? Just a simple checkbox will do, thank you.
Adobe did the same thing to prevent actionscript cross site scripting. This bothered everyone, and now you have security.allowDomain = "*"; all over the internet ....
The page from the primary domain refers to scripts on those other domains as a matter of trust. If CNN doesn't trust a domain's scripts, then they won't refer to them in the first place!
OTOH if the http connection is being attacked (say from an infected system on the LAN) and references to bad domains are being injected, then that could be a real problem but not one that is solved by this new feature. Only https would prevent this attack.
And I'm not running any of 'em. And I never have.
If you are talking about noscript, yes, that's exactly how it works. The UI is simple enough that my 9-year-old uses it without problems. It cannot really be used by anyone who does not understand the difference between code and data, though.
The difference between noscript and this idea is simple:
Noscript - you decide who you will trust.
TFA - whoever hacked the site you are visiting decides who you will trust.
No-brainer from where I'm sitting. But for people who are not knowledgeable enough to browse safely, and who need to (or insist on) browsing anyway, this would be a step in the right direction.