There have been several proposals and a fair bit of discussion in recent months about allowing web authors to restrict the capabilities of "their" content - for XSS mitigation or other reasons. Here are some:
Content Restrictions (CR) http://www.gerv.net/security/content-restrictions/ Script Keys http://www.gerv.net/security/script-keys/ <jail> http://kathrin.dagstuhl.de/files/Materials/07/07091/07091.EichBrendan.Slides.pdf (and other similar proposals using names like <sandbox>) Browser Enforced Embedded Policies (BEEP): http://www.research.att.com/~trevor/beep.html Ian Hickson's summary of proposals posted to WHAT-WG: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-May/011198.html As Ian said, this is a complicated area, and there are a lot of proposals which may not be fully thought-through. (I include my own suggestions in that.) For example, the flexibility of JavaScript means that many suggestions for types of restriction actually do not restrict anything. Please do not chime into this thread without a good understanding of the issues and the documents above. Here is my attempt to summarise the current status. Possible Use Cases ------------------ - George is writing some blog software and wants to display user comments safely, either without any HTML or with a limited subset. He's worried his sanitiser might not be perfect. - The developers of TOR want to show retrieved HTML content in the browser without the content leaking any information about the user. - The developers of eBay want to allow sellers to upload complex pages with embedded script without sellers stealing buyers' eBay login credentials or cookies. Possible Goals -------------- - Simplicity - reuse as much security infrastructure as possible - Keep the restriction rules simple and easy to understand - Make it possible to implement without needing access to webserver configuration Open Questions -------------- * Restriction area - the whole of a page or just part? Restricting the whole of a page allows us to leverage the <iframe>/page security model. CR: Restricts whole page Script Keys: Restricts to only pre-approved script <jail>: Restricts part of the content BEEP: Can restrict different scripts in different ways Hixie: Restricts everything inside an <iframe> * Restriction scope - all script or only some actions? Just script or other stuff too? Different use cases require different types of restriction. So this question is probably best answered by deciding which use cases we are attempting to deal with. CR: Restricts script location in page, script host, cookie access and frame hierarchy traversal. Script Keys: Restricts what script can run, but not what it can do <jail>: Not clearly defined; restricts running of script and/or script capabilities BEEP: Restrictions arbitrarily flexible Hixie: Restricts whether script can run, frame hierarchy traversal, a set of "annoying" APIs, style cascade through <iframe> boundary. * Restriction mechanism - how to trigger restrictions? CR: HTML header/meta tag Script Keys: HTTP header matching a string inside script comments <jail>: HTML tag BEEP: installation of JS function Hixie: <iframe> attributes * Degredation - do we degrade to <noscript> or to full capabilities? I believe all proposals degrade to give script full capabilities (as that's what we have now). Existing Work ------------- There is a tracking bug for sanitizing content sinks: https://bugzilla.mozilla.org/show_bug.cgi?id=370946 There is a patch to allow <iframe> to size to content (required for <iframe>-based solutions): https://bugzilla.mozilla.org/show_bug.cgi?id=80713 IE has the proprietary "security" attribute on <iframe> which restricts script in various ways: http://msdn2.microsoft.com/en-us/library/ms534622.aspx Is this a complete summary? It may not be the most helpful way of looking at things; suggestions welcome. My analysis will follow in a separate message. Gerv _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
