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."
NoScript is designed so the user can protect themselves. SSP is designed so that the website owner can protect users from other users, malicious widget developers, or perhaps unscrupulous CDNs.
This makes me wonder if it would be good for helping in situations like ISP's using Phorm or their ilk.
unscrupulous Canadians?
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.
No such thing. We're all totally scrupulous.
None of them can see the clouds; The polished wings don't care.
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.
NoScript is designed so the user can protect themselves. SSP is designed so that the website owner can protect users from other users, malicious widget developers, or perhaps unscrupulous CDNs.
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 the work to protect less than half of your users but the rest that use IE will need some other form of protection.
It could skew already complicated cross-browser development.
Let's just hope microsoft doesn't make their browser even less standards compliant...although I did hear that IE8 scored high on the acid2 test. Guess they are making some headway.
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.
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 talking about?
1. I go to login to my bank account.
2. The bank server sends a text message to my phone with a one time key/password.
3. I enter the password/key, so the bank has a better idea that I am who I say I am.
Or...
1. ID theif uses my login info to try to get into my online account.
2. The bank server sends a text message to my phone with a one time key/password.
3. I'm not logging in at the moment, so I call the bank to check in, etc. Interesting.
My blog
turn up the jukebox and tell me a lie
because the server specifies the site policy. the browser uses the site policy to know what to block. if I am running my site and have my policy set up correctly, if an XSS is found in my site and an attacker tries to exploit it, hopefully my policy is defined well enough that a browser knows not to run the attacker's javascript. so the browser doesn't help the server, the server helps the browser know what it should run and what it shouldn't.
Say you are a webmaster. You serve pages that you generate and trust them. However, some third parties would like to include content on your pages that is served from servers that you don't control. For example advertisements - these are almost always served from a different computer than the main webpage. Another example is embedded content from another site like a YouTube movie, or all these little panels that the social networking sites are starting to introduce. This gets worse when users themselves are allowed to put this sort of content on your site (say you run a forum or social networking site).
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.
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.
If you care about your machine and what happens to it, it's your job. If you just want to flail around in anger when your box becomes a big paperweight, leave it up to someone else.
/snicker
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, and a slight change in behavior (stop trying to steal music, porn, movies and software). If you can't take these steps, I'm genuinely amazed that you are capable of showering, starting your car and driving to work and functioning. Most people can, but won't. It sort of flows into that whole "not accepting responsibility for stuff I do" attitude that pervades modern society.
Typical transaction:
Dumbass (to self): Sweet I just got the entire collection of every rolling stones song ever made for free! 8)
>click
Computer: all of your files are belong to us. Send payment to uvebeenpwned@yahoo.com or you won't get your files back, MU HU HA HA.
Dumbass (to IT buddy): My computer is running slow and all my files got encrypted. I think I have spyware.
IT Buddy: You use p2p?
Dumbass: no, I have no idea what happened, I swear I dun't download...
-r
Don't kid yourself. It's the size of the regexp AND how you use it that counts.
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.
What you've described is an RSA SecurID one-time-password. It may appear that your father's fob communicated with the remote server, but the truth is each fob has a unique seed and a clock that creates one-time-passwords based on the value of its clock and an optional salt (PIN). The remote server that validates the OTP knows the seed of your father's fob and is able to authenticate each password it receives. After each valid authentication the passcode is discarded and cannot be used again (within limits of the passcode length). The system allows for clock skew between the fob and the validating server. Current system functionality may have changed as this description is quite old.
I agree it would be useful to have better client-side protection, but I don't understand how this system could possible make things worse.
/etc/hosts or the like)
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 came up with some other system to let users decide what JS to run or not (like NoScript), that would still work too. This isn't a system to override your personal settings and force scripts to run, it's just another layer of protection applied before your personal settings, and to help people that can't or don't take the kind of additional protection steps you do.
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