Mozilla Experiments With Site Security Policy 68
An anonymous reader writes "Mozilla has opened comments for an new experimental browser security policy, dubbed Site Security Policy (SSP), designed to protect against XSS, CSRF, and malware-laced IFRAME attacks which infected over 1.5 million pages Web earlier this year. Security experts and developers are excited because SSP extends control over Web 2.0 applications that allow users to upload/include potentially harmful HTML/JavaScript such as on iGoogle, eBay Auction Listings, Roxer Pages, Windows Live, MySpace / Facebook Widgets, and so on. Banner ads from CDNs have had similar problems with JavaScript malware on social networks. The prototype Firefox SSP add-on aims to provide website owners with granular control over what the third-party content they include is allowed to do and where its supposed to originate. No word if Internet Explorer or Opera will support the initiative."
Why not just include NoScript by default? (Score:1, Insightful)
Re:Why not just include NoScript by default? (Score:5, Informative)
Re: (Score:3, Funny)
Re: (Score:3, Funny)
Re: (Score:2, Interesting)
Re: (Score:3, Funny)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2, Interesting)
SSP would be great considering the huge amount of attacks....from google, to microsoft, etc. Which have been successful.
The only problem with SSP is if microsoft doesn't implement it it will be shot down because IE has 60+% market share. Without IE it would be useless because you can't put t
Not a problem at all (Score:2)
News headlines like "IE does not implement important security protocol that Firefox does" will get chairs moving fast in Redmond.
Re: (Score:2)
Hmm lets look at the candidates... (Score:1)
MSP [Microsoft Security Policy], OSS [Open Site Security] (OSS is totally on Microsoft's side), MSS [Microsoft Site Security]
all sound like completely reasonable candidates. Or even
SSP [SilverLight Security Policy] if they really want to make it their own
Than they can apply for ISO standardization and release half ass documentation.
Re: (Score:2)
This isn't a standard.
As much as I dislike Microsoft, sometimes I really wonder about the unthinking Microsoft bashing on Slashdot. Here you've more or less assumed Firefox's non-standard feature will become a standard. But what justification is there for that? IE doesn't have a similar feature in this case, but there are several areas where IE does things differently than Firefox or has features that aren't in Firefox, so why are those never added as standards?. Why does the Firefox implementation
Re: (Score:2)
Name a Microsoft 'standard' which meets those criteria.
Re: (Score:2)
Re: (Score:1)
Re: (Score:1, Insightful)
Who is responsible for creating the seamless browsing experience? Users shouldn't have to block scripts at cnn.com and then waste time scratching their head while looking at their noscript menu to try and figure out whether or not the content
Re: (Score:1)
Anonymous Answers Itself (Score:1, Funny)
A: NoScript's security can get kind of annoying sometimes
Re: (Score:2)
Even if you could explain to an average user what NoScript does, they'd probably just enable scripts for every page they visit without caring what the script does.
Good news for Phorm victims? (Score:3, Interesting)
Re: (Score:3, Informative)
Their demo page surprised me. I didn't think that stuff would work. If the add-on stops that from being exploitable, it is a good thing, even if it doesn't prevent MITM attacks.
Re: (Score:2)
Or even worse it wouldn't surprise me if their DPI ad injecting boxes just stripped all SSP headers, which of course would open their users up to more threats but it isn't like they care much.
Maybe OT... probably not (Score:2)
No, it won't stop all identity theft attacks, but it is improvement.
Perhaps one day I'll get to use my pager/phone as se
Re: (Score:3, Interesting)
My father in law had a keyfob lcd thing to which his employer would send him passwords when he wanted to use his takehome work laptop. When he turned it on, it sent a signal to the home base, and the keyfob would show a number. He used this number to log in. This way, if the laptop got stolen, it was effectively worthless.
Is this what you're
Re: (Score:2)
Re:Maybe OT... probably not (Score:5, Informative)
Re: (Score:2)
Re: (Score:2)
Re: (Score:1)
Having seen it in action, it's a brilliant system. Unfortunately, I'm not a Barclays customer, so I haven't used it personally, but I'm waiting quite excitedly for my bank to implement a
Re: (Score:2)
Re: (Score:1)
My bank has been sending me OTPs for some 12 years now, at first by regular mail, currently as a text message to my phone, to be used every time I want to make a transaction.
(New) usernames and passwords have to be collected in person at the bank by presenting them with the confirmation letter and proper ID.
Friends of mine who do internet banking with other banks have been using a personal card reader/PIN pad and a challenge/response system for at least
Re: (Score:2)
Re: RSA SecurID (Score:2)
Re: (Score:1)
I had read about the European key fob type things and wondered when something like that would show up here. I guess BofA decided to take the cheaper for them route since many now have cell phones, but personally, I've simply never been able to justify the additional cost for a cell phone over (formerly) a landline, and the hurdle got higher recently wh
But why trust site administrators? (Score:1, Insightful)
But the real problem is still on the client end.
For example, I block google-analytics.com, because I don't want to be a part of whatever Google stores by means of "ga.js".
Perhaps I'm misunderstanding SSP, but the last thing I want my web browser to do is automatically "decide" that, for example, my trust in slashdot.or
Re: (Score:3, Interesting)
Currently the options for limiting the scope of JavaScript are:
1. Turn JS off
2. Prevent certain files from loads (i.e.
This does not interfere with either of those, and adds:
3. Allow site administrators explicitly list allowed scripts/domains and block all others.
You can still turn off JS, and you can still prevent certain files from loads. If you c
Re: (Score:1)
First off you are correct, you don't understand SSP. It does not force-enable JavaScript on the client's end. It allows site developers to force-disable JavaScript that they have not verified. It is sort of like NoScript for site developers that don't have 100% control over the source of their site. Consider the case where a site is built using a multi-author CMS. The group could agree to only use scripts that they wrote and ones server from [favorite_script_site]. SSP would prevent clueless Sally from addi
Don't malware attacks have signatures? (Score:2)
If SSP is as transparent as SSL (and how could it not be, since it's only 4 letters away in the alphabet!) then it will work. If it takes user intervention, it will probably fail.
There's no reason to believe Opera or IE would not adopt it, if it works.
pages Web (Score:3, Funny)
FF3 'Killer App' ? (Score:3, Interesting)
FINALLY (Score:5, Informative)
The best case would be a restructuring Javascript and the DOM as well, but I would be excited to see any increased security. After I used a reflected XSS attack to essentially gain control over a client's browser and all their cookies last year, I don't trust any web application.
Re:FINALLY (Score:5, Insightful)
I block everything by default, and rarely allow things permanent permissions, but trying to figure out which one is causing the site to not work is a real pain in the ass. Really it's something which shouldn't be expected of a user. the JSON ans XSS vulnerabilities really ought to be enough to convince at least financial institutions not to include that kind of crap on their sites.
But of course, this assumes that the system works, is well designed and protects against the things that developers really shouldn't be doing automatically. But I'll be giving it a whirl just to see if it helps at all.
Very confusing. (Score:2)
Re: (Score:2)
If a website's code is changed by a malicious, outside party, it usually has to reference an outside server at some point. SSP will block access to the outside server because it will recognize the current website has no need to have you interacting with it.
At least that's how I'm understanding it.
Re:Very confusing. (Score:5, Informative)
Re: (Score:2)
If a site owner implements these headers injected JavaScript won't be able to do much since it will be in the sandbox specified by the site-owner.
Re:Very confusing. (Score:5, Informative)
Because you don't control these web servers, the content they are serving could be replaced with malicious content, or just content that goes beyond what you gave them permission to do. Or a user could intentionally post malicious content.
This allows a webmaster to indicate what third party content is allowed on any page (if any), and what that third party content is allowed to do (text, images, animated images, javascript, plugins, etc). The web-browser then enforces the rules that the webmaster set.
Re: (Score:1)
Whos Job Is It? - Security (Score:1)
Re: (Score:3, Insightful)
It's the job of the authorities to lock up the crackers and other people that commit electronic crimes. It's your job to lock your front door.
At the end of the day, the authorities and your ISP can't do anything until the threat is known. By then the damage is done.
99.9% of stuff can be mitigated with NoScript, a $50 firewall, an
Re: (Score:1)
Additional Information (Score:5, Informative)
http://www.cgisecurity.com/2007/11/08 [cgisecurity.com]
Jeremiah Grossman's thoughts
http://jeremiahgrossman.blogspot.com/2008/06/site-security-policy-open-for-comments.html [blogspot.com]
it's just not sufficient protection (Score:3, Funny)
SSL + SSP = Safer Web Apps (Score:5, Insightful)
As I commented here [hackademix.net], SSL and SSP are orthogonal technologies whose correct and joint adoption should be required for any website performing sensitive transactions: the former ensuring integrity and, to a certain extent, identity; the latter defining and guarding application boundaries.
Those websites should encourage their users to adopt a SSP complaint browser, and complaint browsers should educate users to prefer SSP complaint sites with visual clues, just like we're already doing with EV-SSL (and for better reasons in this case, maybe).
On my side, I'm considering to highlight valid SSL + restrictive SSP websites as more reliable candidates for NoScript whitelisting.
Re: (Score:1)
Re: (Score:2)
Google DoubleClick et al (Score:2)
SSP will require them to cut down number of domains needed to whitelist (otherwise SSP whitelist would look like AdBlock's database