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 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
First thoughts on that:
If I say that my site trusts domain1.com, but domain1.com isn't using this and ends up having all sorts of dodgy scripts they're passing along, would this block them, or would they count as coming from domain1.com?
I like you, Stuart. You're not like everyone else, here, at Slashdot.
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"?
It doesn't quite work that way, it's much more fine grained, i.e. as a site owner I can say something like:
allow /foo/bar.cgi?weird looking strings and block anything else
so if an attacker finds a cross-site scripting flaw in say "/login.php" the client won't accept it, protecting my client, and protecting the site owner as well (bad guys aren't harvesting credentials from users, etc.).
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.
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.
If I say that my site trusts domain1.com, but domain1.com isn't using this and ends up having all sorts of dodgy scripts they're passing along, would this block them, or would they count as coming from domain1.com?
Domain1 woudn't need to use this - this is a client-side security measure. If your site uses it and declares trusted third-parties, it's enough.
Also, what is "passing along" supposed to mean? Scripts (or any other stuff) would either come from domain1 or not. If not, it wouldn't be trusted.
If domain1 proxies scripts from other sources, this means they come from domain1, as far as HTTP is concerend - and they would be trusted.
The problem I see however is domain1 declaring additional trusted domains when delivering its scripts, thereby allowing for "cascaded domain trust", which
would pretty much defeat the new system. This can easily be prevented by not accepting additional trusted domains from elements that are third-party though.
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.
Because, as a user I might not know which of the 47 different domains that CNN pulls scripts from are *supposed* to be serving scripts and which are some guy trying to get my facebook account details (not that I have one or read the CNN site regularly; largely because of the number of bloody domains they pull scripts from), whereas the owners of the CNN site *will* know which domains they're supposed to be pulling scripts from and can state so to the browser.
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".
Cross site scripting is exactly what it sounds like; running a script from one site in another site's security sandbox (i.e. scripting across sites). The script tag allows scripts to be loaded by a page from any site. These scripts then run in the same namespace and sandbox as any other scripts on that page. It's basically the web equivalent of an arbitrary code execution vulnerability. It isn't quite as bad as the client-side version, because there is (in theory) no way of escaping from the sandbox that the browser constructs from each site.
If you don't properly sanitise user-provided data then it's quite easy[1]. Imagine, for example, that Slashdot allowed arbitrary HTML. If it did then I could put a script tag in this post referring to a script in my domain. Your browser would then load this script and run it as if it were provided by Slashdot. If you enter your password, I could harvest it. Even if you don't, my script could send HTTP requests to Slashdot with your login credentials and post spam. If you've entered personal information in your user profile, I could harvest this.
You probably don't have any private information on Slashdot, so it's not a particularly attractive target for identity theft, but the large number of page views means that it might be useful for spam. Imagine, for example, a cross-site scripting vulnerability being used so that everyone with excellent karma who went to the Sony story posted something written by Sony PR.
For sites like eBay, it's much more important. These sites have full names, postal addresses, and often credit card numbers. If I can run a script in their pages' sandbox then I can access all of this information as the user enters it.
This idea is for each domain to provide a whitelist of domains that are allowed to provide scripts (or other resources). If I persuade eBay's code to load a script from my domain then FireFox can check my domain name against the list published by eBay, see that it is not there, and refuse to run the script.
[1] This isn't the only way of persuading a site to load your scripts, but it is the simplest to explain.
I am TheRaven on Soylent News
NoScript solves a different problem, which is that you don't trust the site. What this aims to solve is the problem of knowing what the site itself considers trustworthy, so that you're not required to issue a blanket statement of distrust: If you trust the site, you can (supposedly) trust its own trust list.