- From: Gervase Markham <gerv@mozilla.org>
- Date: Mon, 30 Jan 2006 15:21:13 +0000
Alexey Feldgendler wrote: > See point 7 in my message: > http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2005-December/005301.html > > It's specifically targeted at keeping decent security in older browsers. > User agents that don't support sandboxing won't execute the scripts at all. What problem are you trying to solve with this proposal? I'm not sure it's the same one that I am. You are trying to solve the problem of letting LiveJournal authors include certain types of "safe" script on their page, when currently they aren't allowed to include any. I'm trying to solve the problem of protecting users from XSS attacks when there are unexpected bugs in an author's web application. > I'm very suspicious of any security policy model that doesn't degrade > safely. If it's anything else, it's OK to define that "older browsers > will just ignore this". But when it's about security, the possibility of > exceeding the defined privileges is not acceptable. But it's not a case of "exceeding the defined privileges". Script today can do "anything" - but only within the browser security model. So it can't, for example, write to your local disk. These sorts of things are the "defined privileges" which it's not acceptable to exceed - and neither my proposal nor yours allows exceeding them. However, in certain cases, an author may want to *further* restrict the capabilities of script on his page. For example, he may want to use it as a backstop in case his web application has an XSS problem. In this sort of scenario, it seems entirely reasonable to enumerate what further restrictions you want to put on the script. If we could rewrite the web again, we might start with a positive, capabilities-based system, where every time you inserted a <script> tag you had to define what it was _allowed_ to do. But we are where we are, and <script> tags by default have "full" privileges. So, for backwards compatibility, we need a restrictions model. > There is a well-known use case: blogs, wikis, forums and other web-based > systems that allow users enter text with markup. Many of them would like > to allow some scripting, but because they can't tell good scripts from > bad ones (which steal cookies, post comments on behalf of the user and > do other nasty things), they filter out <script>...</script> completely. > They won't benefit of the content restrictions you propose because they > can't risk feeding unsafe content to an older browser which doesn't > understand the restrictions. This is not a problem I'm trying to solve. And anyway, I don't think it's a serious security problem, because it already has a solution - filter out <script> altogether. I've not come across a compelling use case which says that blogs and wikis need to allow people to insert certain sorts of script into the blogpost or wiki page. Gerv
Received on Monday, 30 January 2006 07:21:13 UTC