Slashdot Mirror
Mozilla Experiments With Site Security Policy
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."
It's what I use for XSS protection. NoScript's security can get kind of annoying sometimes, but it has been useful for some pages I've come across which have tried to load my user/pass data across a affiliate site.
This makes me wonder if it would be good for helping in situations like ISP's using Phorm or their ilk.
Q: Why not just include NoScript by default?
A: NoScript's security can get kind of annoying sometimes
The first thing I thought.. OH, IE catches up, Mozilla moves ahead. FF3 is awsomeness, and now better security development? Impressive. Yes, it's not client side, but offers a way for site owners to add that extra bit of security... hmmm Mr Banker? hello? Are you listening? I hope that something solid comes of this to offer better security for people in general and the Internet as a whole.
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 second path authentication for the bank? I am hoping for it, but any improvement in the meantime is a good thing.
Support NYCountryLawyer RIAA vs People
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.org is to be automatically extended to Javascript hosted by google-analytics.com, solely because Slashdot's site administrators have chosen to trust google-analytics.com. (Or ad.doubleclick.net, which is now owned by Google...)
In my eyes, that sort of behavior constitutes adding a security hole, not plugging it.
To use an example that doesn't quite hit so close to home, I just about flipped when my bank added a lovely little "feature" on its login box that would cut down its support costs by enabling me to "chat with a live person". I'll turn on Javashit when I log in to my bank because I trust my bank, but I was damned if I'm going to let a wholly-unrelated outfit like liveperson.com (who are a legitimate company, but they run the Internet equivalent of outsourced phone banks and chatbots) run their Javashit every time I log onto my bank, especially since I've never once felt the need to "chat with a live person" while trying to bank online.
Liveperson.com, much like Doubleclick and Google Analytics, got blocked in the HOSTS file and in the router. Those aren't options for non-technical users, but I fear that SSP may wind up enabling more holes/leaks than it closes. How much do you trust your site administrators? My bank's probably trustworthy. Slashdot's probably more interested in my data than Google is. But some random web forum whose administrator may not know his ass from a hole in the ground? The answer's still "no".
If the ISP isn't virus-scanning uploads, the ISP is inviting attacks.
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.
Oh, say does that Star-Spangled Banner entwine / The myrtle of Venus with Bacchus's vine?
This sounds like a great idea! Maybe this will be the killer app that pushes FF past IE.
As someone who has worked in web security, let me say that many of us have been begging for stricter control over security protocols for years. With all the AJAX going around, more and more sites are proving vulnerable to browsers that are just too friendly with the same-origin policy. If you check out the OWASP Top 10, you'll see that a whole bunch of these attacks could be prevented by better browser security.
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.
A modded up comment says it helps the web site owners to protect one user from another (malicious) user. But it is part of the browser. How does a browser help the server?
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
Its very one's job... But shouldnt the webmasters be responsible for their content. If an ISP can deep packet filter, and can be forced to by law, why cant a website be forced to filter content it displays, whether it comes from a CDN or other businesses. Pushing this off to the user, is doomed to failure for the majority.
This is something a lot of us in the industry have been writing about. Here's my rant from last October Browser Security: I Want A Website Active Content Policy File Standard!
http://www.cgisecurity.com/2007/11/08
Jeremiah Grossman's thoughts
http://jeremiahgrossman.blogspot.com/2008/06/site-security-policy-open-for-comments.html
Believe me, if I started murdering people, there would be none of you left.
In all likelihood it will be years before the enabling technology is in place to prevent the most vicious malware of all, the dreaded rickroll.
As I commented here, 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.
There's a browser safer than Firefox, it is Firefox, with NoScript
It would be silly to rely on SSP as the only form of protecton. As an additional measure you can use it even if not 100% of browsers implement it - you're just lowering risk/attack surface.
News headlines like "IE does not implement important security protocol that Firefox does" will get chairs moving fast in Redmond.
Advertisers may not like it. Currently they use scripts from multiple domains and dozens of CDNs.
;) and won't let them add new domains without getting publishers to change SSP.
SSP will require them to cut down number of domains needed to whitelist (otherwise SSP whitelist would look like AdBlock's database
But the question is if Microsoft will adopt the standard or make their own.
:P
..."Ring any bells"
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.
FWIW, NSA was using this technology in the '80s.
Invenio via vel creo