5031871
story
Comments: 160 +- IT: New Firefox Standard Aims to Combat Cross-Site Scripting on Monday June 29, @05:06PM
background: url(//a.fsdn.com/sd/topics/topicsecurity.gif); width:59px; height:78px;
security
background: url(//a.fsdn.com/sd/topics/topicmozilla.gif); width:80px; height:64px;
mozilla
background: url(//a.fsdn.com/sd/topics/topicinternet.gif); width:70px; height:73px;
internet
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.'"
Related Stories
Submission: Firefox Standard Will Combat Cross-Site-Scripting by Anonymous Coward
"The porcupine with the sharpest quills gets stuck on a tree more often."
All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2009 Geeknet, Inc.
as an end user (Score:2, Insightful)
I really hope the default policy is "only allow scripts from the current domain" and "do not allow the site to override my choice".
Re: (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.).
Re: (Score:2, Funny)
As an end user I really hope that the sites I visit have a default policy of "we only serve up our own shit". ...
Fuck.
Re: (Score:3, Interesting)
Noscript does this.
Which brings me to the observation that, at least as far as I can tell from the blurb, this entire thing sounds a bit redundant in light of the ready availability of Noscript. Why not just make it part of the default firefox install instead?
Re:as an end user (Score:5, Insightful)
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.
Parent
Re: (Score:3, Insightful)
Sounds like a bug rather than a feature to me. Th
Re:as an end user (Score:5, Insightful)
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.
Parent
How does this change userland? (Score:5, Insightful)
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.
Re: (Score:2)
Dude. How are *you* going to know that it is ok to run scripts on Slashdot.org that originate from slashdotscripts.com and not scriptsforslashdot.com? Even if you are a lunatic and micromanage the trusted sources of these scripts, how would selectively running any of them do you any good? I would imagine almos
Re:How does this change userland? (Score:4, Insightful)
Dare I say it?
Site XXXX is attempting to run a script on site YYYY.
(C)ANCEL or (A) LLOW?
All snark aside, why would I allow either of those domains to run a script on slashdot.org? Since I trust slashdot to a certain extent, I would allow from scripts.slashdot.org. But allowing scripts from a completely different domain? No way.
The point is that my security policy is annoying to implement. For site mybank.com I need to enable scripting. But if things were perfect, I could enable only for scripts from $SUBDOMAIN.mybank.com, so I don't get hosed by scripts from $HACKERSITE.bankmy.com. And if legitimate sites are hosting their scripts from an entirely different domains... well, that would have to change. Instead I have to take an all-or-none approach, since the sites I need security the most on are the ones where I need to enable scripting. That just sucks.
Parent
Re: (Score:3, Insightful)
And I know that fsdn.com is also a trusted site.
Funnily enough, I know I don't want fsdn.com's content because the side bar is annoying bloatware that cripples the utility of the site. I'm very glad to have NoScript on the case, blocking it for me. (Which makes me wonder how many other horror websites there are out there whose horrible bloat I've been saved from by virtue of my browsers blocking XSS.)
Re: (Score:2)
I absolutely hate having to figure out which domain that I've blocked that will allow access to the content and which ones are dodgy. And further whether the site that's serving up the content is safe enough to allow.
Re: (Score:2)
Indeed, I wish noscript would allow me to whitelist domains and even specific scripts on a per-site basis. So, for example, I could whitelist maps.google.com's use of javascript from gstatic.com but not allow any other sites, like images.google.com, to pull in javascript from gstatic.com.
eBay and MySpace? (Score:3, Insightful)
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 w
Re: (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.
Cost vs. Benefit? (Score:4, Interesting)
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"?
Re: (Score:2)
The TD Ameritrade settlement for instance was an absolute joke, they ended up losing a lot of personal information and then they ended up with a slap on the wrist. It's not going to be cost effective for organizations to secure their sites as long as they're free to pass on the cost to th
Article on this and related technologies (Score:3, Interesting)
Re: (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.
Headline: Google other ad publishers revenues drop (Score:2, Interesting)
Re: (Score:2)
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.
The XSS FAQ (Score:3, Informative)
The Cross-site Scripting (XSS) FAQ http://www.cgisecurity.com/xss-faq.html [cgisecurity.com]
This is great for Firefox users... (Score:2, Interesting)
Re: (Score:3, Insightful)
Well, if Firefox users find it effective, then other companies will follow suit. It's just a standard Mozilla is adopting, though it seems to have been defined in house, that won't stop anyone else from using it.
A step in the right direction (Score:2)
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.
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.
Yea. they are free. right. (Score:2)
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. rememb
RFC? (Score:4, Insightful)
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).
Re: (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.
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:Good idea (Score:5, Insightful)
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?
Parent
Re: (Score:2)
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.
Re:Good idea (Score:5, Interesting)
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.
Parent
Re: (Score:3, Insightful)
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?
Re: (Score:2)
Because if it doesn't form a TLA (Three-Letter Acronym) it won't catch on.
You're doing it wrong (Score:2, Flamebait)
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.
Re: (Score:2)
Re: (Score:2)
...why?
Re: (Score:2)
Re: (Score:2)
And can you be sure you have all the legitimate user agents?
Certainly ie, mozilla, safari, chrome and opera will cover most of the desktop / laptop user agents, but what about all the obscure browsers used on phones and other mobile devices?
Re: (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.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (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: (Score:3, Interesting)
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
Re: (Score:3, Interesting)
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
Re: (Score:2)
It is just a client protection, like Microsofts HttpOnly-Cookies [microsoft.com]. You can still send any packages to the server.
Re: (Score:2, Funny)
I guess the other browsers will just ignore this unless of course they jump on board and implement it too.
Exactly. Also, it will rain tomorrow. Unless it doesn't.
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.
Parent