On Jul 11, 7:16 pm, bsterne <[EMAIL PROTECTED]> wrote: > Perhaps I am misunderstanding this point. Are you suggesting that an > ideal model wouldn't require that web developers do anything > differently than they currently are? Site Security Policy is intended > to be a belt-and-suspenders tool to protect sites and users, but we > are still advocating that developers keep their web applications free > of vulnerabilities.
In an ideal world, we wouldn't have attackers, and all code would be functional, elegant and secure. ;) But we know how that goes... Right now, a web developer who is willing to re-architect a site could take advantage of existing mashup work to produce more secure code. For example, they might look at the ways of isolating code used in Subspace [1] or SMash [2] that work in an unmodified browser. Or they could look towards enhanced-browser solutions like the <sandbox> abstractions of MashupOS [3][4]. Plus there are input-checking tools and data-tainting tools that can provide further protection. The target market, as it were, for a "belt-and-suspenders" sort of approach is probably not the people who have the time and skill to rework an entire web application. Those people already have tools. They might like to have better ones, but for the amount of effort involved they probably want much more than a belt-and-suspenders level of additional security. The people who could benefit most from SSP are those who are interested in additional security, but don't have the time (or possibly the skills) for full audits of existing code. System administrators who want to minimize risk to their servers. People who have installed blogging/webmail/etc. software on their websites and want additional security guarantees. Companies who feel they're at high risk of people trying to do cross-site request forgery on their sites and don't want a typo in input-checking to result in upset customers. Right now, these people could use a tool to help them enforce security policies with relatively minimal effort, which is pretty much what SSP is. But they'd benefit a lot more if it weren't necessary to also re- architect their sites to ensure that they get the most out of SSP! [1] http://www.collinjackson.com/research/papers/fp801-jackson.pdf [2] http://domino.research.ibm.com/library/cyberdig.nsf/1e4115aea78b6e7c85256b360066f0d4/0ee2d79f8be461ce8525731b0009404d?OpenDocument [3] http://www.usenix.org/event/hotos07/tech/full_papers/howell/howell_html/ [4] http://research.microsoft.com/~helenw/papers/sosp07MashupOS.pdf _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
