Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Security Mozilla The Internet

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."
This discussion has been archived. No new comments can be posted.

Mozilla Experiments With Site Security Policy

Comments Filter:
  • by RelaxedTension ( 914174 ) on Friday June 06, 2008 @03:27PM (#23686093)
    This makes me wonder if it would be good for helping in situations like ISP's using Phorm or their ilk.
  • FF3 'Killer App' ? (Score:3, Interesting)

    by apachetoolbox ( 456499 ) on Friday June 06, 2008 @03:41PM (#23686299) Homepage
    This sounds like a great idea! Maybe this will be the killer app that pushes FF past IE.
  • <quote>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.</quote>

    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.
  • by veganboyjosh ( 896761 ) on Friday June 06, 2008 @03:46PM (#23686363)
    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.
  • by morgan_greywolf ( 835522 ) * on Friday June 06, 2008 @03:46PM (#23686371) Homepage Journal

    No such thing. We're all totally scrupulous.
    So George Washington was really a Canadian?
  • by profplump ( 309017 ) <zach-slashjunk@kotlarek.com> on Friday June 06, 2008 @05:09PM (#23687555)
    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.

    Currently the options for limiting the scope of JavaScript are:
    1. Turn JS off
    2. Prevent certain files from loads (i.e. /etc/hosts or the like)

    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.

Happiness is twin floppies.

Working...