New Firefox Standard Aims to Combat Cross-Site Scripting 160
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.'"
Re:as an end user (Score:3, Informative)
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 XSS FAQ (Score:3, Informative)
The Cross-site Scripting (XSS) FAQ http://www.cgisecurity.com/xss-faq.html [cgisecurity.com]
NOT a standard (Score:3, Informative)
Standard? (Score:3, Informative)
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.
Massive Overkill (Score:3, Informative)
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.
Re:RFC? (Score:3, Informative)
I should have the read the article first, since no where in the article do they mention the word 'standard'. When they do decide to make it happen I do hope the submit the proposal to the right organisations, as to avoid making this a one browser standard.
Re:Old Standard to Prevent All Attacks (Score:3, Informative)
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.
I suggest you resign from Slashdot as soon as possible then ...
Re:Article on this and related technologies (Score:3, Informative)
If MS did this we'd all be crying about how this isn't sanctioned by W3C, and it's "embraceandextend" (tag?).
Extinguish.
It's Embrace, Extend, Extinguish. That last E makes all the difference in the world.
Re:Use a file? (Score:3, Informative)
Ugly, lots of over head...
And requires me to figure out the useragent of either every browser out there (to allow) or every bot out there (to deny). At least, as far as I can tell.
No, only "bots" (spiders, nowadays) actually check robots.txt, per the RFC. User-initiated requests don't/shouldn't (no browser I've ever seen) do not request/parse robots.txt.
How do you code without any inline scripting? (Score:1, Informative)
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?
Re:Managers (Score:2, Informative)
It extends well beyond scripts into other content areas. It can be used to limit the domains that are allowed to serve images, css, and so on (this is all for a given page).
PLEASE GOD NOOO! ;) (Score:2, Informative)
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. :/
Re:eBay and MySpace? (Score:3, Informative)
Apparently, you have no idea what XSS means. Neither eBay or Myspace allow the execution of user-provided scripts for obvious reasons. Given the market share of Firefox, the big sites will implement CSP pretty soon.
Re:Massive Overkill (Score:2, Informative)
Hackers can just fire up a different browser, so the number of hackers this will stop are exactly ZERO.
It's not about stopping hackers from running these scripts. It's to protect the users if a hacker have managed to insert a remote script via a form on the webpage. It protects users running firefox if the site have implemented the tag.
Re:XSS (Cross-Site Scripting) definition? (Score:4, Informative)
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.