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".
"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?
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.
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"?
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.
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.
When content is fed to you by/through domain1.com, do you see it as coming from domain1.com?
If the answer to that is YES, then you're FUCKED if domain1.com is serving up shit.
Presumably the millions of adsense and publishers will have to enable their sites to maintain adverts..? Might hit google revs a bit...
Hey! It doesn't need to be plain ol' text.
As a theoretical, it could be hamstrung html that pisses off some users by not recognizing UTF-8 in order to prevent malicious posting.
Or something. I'm sure we could figure out a decent implementation.
"Trolls they were, but filled with the evil will of their master: a fell race..." -- J.R.R. Tolkien on Olog-hai
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.
It is just a client protection, like Microsofts HttpOnly-Cookies. You can still send any packages to the server.
NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
Don't let other people serve content via your site.
Problem is that security flaws such as cross-site scripting (XSS) allow exactly this (insert arbitrary HTML/JavaScript into the page which is then rendered by the client browser.
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
Don't depend on user-generated content, since it's shit.
Says the person providing user-generated content to a site that depends on it.
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.
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.
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 ...
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.
Why is this modded troll?
99.99999% of attacks are the result of:
Malicious ads and clickthrough "offers" after a sale is processed
Vulnerabilities in PDF, Flash, etc.
Malicious content uploaded by users (javascript, sql injection, malformed jpegs, what have you)
Domain hijacking
General "LOL I GOT UR PASSWORD" shenanigans
From the summary:
As long as this "standard" is the one called HyperText Markup Language, then this makes sense. HTML is intended to say what scripts run on a page. If that's broken, then the HTML should be fixed. Somehow I suspect it's not broken, but that developers' implementations of sites are.
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?
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.
And moronic users. Don't forget the moronic users!
Sexconker is modded a troll - quite unfairly. Cross site scripting sucks. Simple as that. I go to a site, first thing I see is noscript's popup message that anywhere between 2 and 20 sites want to run scripts in my browser. I click the popup, to see WHO wants to run scripts. Sometimes, it's easy to see who wants to do what, and deciding to allow site a, but not site b is quite simple.
Often enough, it's just not that simple. I want to see some stupid flash presentation, and the only way to see it is to enable flash. Unfortunately, three different sites are offering a flash. Which one do I want? I choose one to be allowed, and I get rickrolled.
That is hamshite. Nothing more, and nothing less. The original site should be hosting it's own material, or they should supply the link to see the flash presentation. Cross site scripting is a ripoff that just helps to confuse the security conscious. And, God knows there are far to few users who are conscious. (I'd like to see a scientific poll that demonstrates just how many users really are brain dead - it has to be over 20%, and might be over 50%)
"Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it." - Charlie Br
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
That is a different problem. The problem with this specification is that when enabled it doesn't allow you to use inline scripts anymore. i.e. you can no longer directly trust *your own domain* unless you use out of line scripts, which is enormously constraining for a large class of applications.
In particular, many applications dynamically generate javascript on the fly. The only way to handle that under this specification would be to generate lots of little temporary files that the browser requests on the second pass. The performance problem with such secondary requests is a serious problem, due to turnaround latency.
Speaking of which, HTTP should be extended to allow web servers to push expected inline requests for script files, images, and frames (up to a reasonable limit and under reasonable constraints) into the web browser in-memory cache to eliminate the turnaround latency associated with such follow on requests. i.e. the browser in such cases would be able to fulfil such requests immediately from the cache because they would already be there by the time the web browser had finished parsing the page.
The other major problem with this solution is that it requires changes at the web site level.
In other words, you're only safe if the web site author opts into the security solution.
What are the chances that the hundreds of millions of web sites out there will all opt into this feature?
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.
We still can. The mentioned MAFIAA flaws are based on a vulnerability in server-side code. <iframe [...]> is posted as the search criteria and incorporated into the site output to the user. It's all HTTP (submitting the "evil" param") and HTML (returning a usable <iframe>.
The Firefox implementation "protects" only from scripts included via <script src=..> from another domain. Pure HTML (like above) or in-page scripts aren't blocked. In most* cases, that's a few minutes of extra work, tops; using the same vulnerability.
* Limitations include content filters (though allowing <script> yet blocking important JS keywords seems not that realistic to me), being vulnerable only to GET requests (limits script size to some 900 bytes; depending on implementation). A possible benefit (to the attacker) of including the script is being able to host it on a server he controls; thus the script can be changed while the attack is live and some tracking (how many people downloaded the script) can be done. OTOH, the attacker gets (more) trackable, too.
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.
Perhaps it would be more effective to modify Firefox so that it will only execute scripts from other domains which are directly referenced by the original domain. That seems much safer to me.
Yeah, I love the (relatively) new one where you have to allow javascript from some skank ass ad server to see the flash file.
They cram an ad in before the flash file actually starts to load, and you have to watch it. Some sites let you just wait and then serve up the flash anyway (they assume the ad shithouse is down at the moment, or something went wrong after the ad played), but you've got to sit and wait and watch a black square for 30-60 seconds.
So to see the flash, I've got "Temporarily allow all this page". In fact, I find myself doing that to get most sites to just fucking work, and it disgusts me.
Moronic users are victims.
Unless you're talking about the special type of moron who will somehow mash their keyboard and enter LOL'); DROP TABLE USERS;
I hate those users! I protect myself in all of my applications by checking for the name "Little Bobby Tables". That kid is TROUBLE!
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.
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?
They would be executed. Even if you use this to its fullest, attackers can still do XSS if they can alter your actual script files. But if fully deployed, it kills the most common cause of XSS: HTML injection. The point is that injected HTML will not be able to include scripts except from approved domains.
Currently an HTML injection anywhere in the application means you can stick in a <script> tag or onload attribute and run any script you like. This is bad, because HTML pages are usually generated dynamically and embed many user-provided strings that have to all be escaped individually by the application. One unescaped string and you get XSS.
With this new tech, a properly-configured site is immune to that. HTML injections can inject HTML, but not anything else: no scripts, images, objects, etc. except from approved domains. Since script files are usually static files with no user-provided strings embedded in them, XSS becomes vastly more difficult. You can't even inject an image from your domain to track IP addresses.
So even if you include dodgy third-party scripts, that won't enable HTML injection to escalate to XSS like it currently can. The third party can, of course, still freely screw you over if their server gets hacked or they deliberately provide malicious content. If you're worried about that, don't trust them!
MediaWiki developer, Total War Center sysadmin
That is a different problem. The problem with this specification is that when enabled it doesn't allow you to use inline scripts anymore. i.e. you can no longer directly trust *your own domain* unless you use out of line scripts, which is enormously constraining for a large class of applications.
But also necessary to prevent HTML injection from escalating into XSS. Even if you can't do this, however, the spec is very modular. You can still use other features it allows while allowing inline script, like restricting domains of image/script/etc. loading.
MediaWiki developer, Total War Center sysadmin
Why would they all need to do that. If any at all use the options, web surfing experience will be safer. It seems like a reasonable solution to me.
Sure, but the instant that you hit a web site that hasn't opted in, the protections are worthless.
MSFT's version of this feature works by inspecting the HTML on the page and blocking all scripts that appear to be hostile - it's not a perfect solution but it doesn't require the site to opt-in.
I think a hybrid solution of both MSFTs and FF's solution is likely to be the best option for customers - the FF solution allows for a declarative solution for sites that want to opt-in, the MSFT solution helps protect other sites.
Neither solution is perfect.
Nobody claimed it was perfect. If you are on a site that supports this feature you are safer. If you are on a site that does not support it you are as safe as you are now. That doesn't mean it's worthless. It makes browsing more secure for everyone. Instead of having a few computer-literate browsers (people not software) use noscript on the page, the page owner just has to write the list once and all visitors get protection, including those not tech-savvy.
A declarative solution still requires that the entire web be updated to adopt it before you're safe. That's why a combination of non declarative (MSFT's XSS filter) and declarative (FireFox's CSP) is the best option.
This is especially true if there's no visual indication that a site has opted into CSP - otherwise you have no way of knowing which sites are "safe" or not.