- From: Maciej Stachowiak <mjs@apple.com>
- Date: Sat, 18 Feb 2006 19:10:54 -0800
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: Ian Hickson <ian@hixie.ch>, Brad Porter <bwporter@tellme.com>, Anne van Kesteren <annevk@opera.com>, www-voice@w3.org, public-webapi@w3.org, public-appformats@w3.org
On Feb 17, 2006, at 2:15 PM, Maciej Stachowiak wrote: >> >> For the use case that first started us looking at <?access-control? >> >, this >> type of privilege escalation would not be possible. The use case was >> off-site XBL2. This case would not be susceptible to this attack >> because >> third-party XBL2, like third-party CSS, runs in the security >> context of >> the source document, not the security context of the XBL2 document. > > This might be an appropriate mechanism for off-site XBL2; I haven't > examined it in enough detail to know. But from your explanation > that sounds likely. XBL2 documents would also have to make sure not > to reveal any authentication information via the DOM, so no > document.cookie for instance. I thought about this some more, and it no longer makes sense to me. If off-site XBL runs in the security context of the referencing document, not the XBL document, then why would <?access-control?> be useful? It is not possible to execute an attack against the site hosting the XBL document, so there is no reason for it to restrict access. If XBL2 script executes in the security context of the referring document, what would be desirable is a way to include a CSS stylesheet without allowing inclusion of cross-domain XBL (or at least restricting what domains it may come from). In fact, this should probably be default for existing stylesheet inclusion mechanisms, since traditionally CSS has been seen to have the same security implications as static content, such as off-site images; XBL2 would make off-site stylesheets have the same security implications as off-site script, which are basically "you'd better really trust whoever you are getting this from". <?access-control?> might be useful if XBL2 went the other way and made XBL2 script execute in the security context of the site hosting the XBL2 document. But that would raise the authentication theft and privelege escalation attacks I mentioned, unless access to the XBL2 shadow DOM is restricted. And since XBL2 allows embedding of content from the source document back into the XBL2 shadow tree, access would have to be restricted the other way too. I am not sure if this is a feasible design, as I don't know to what extent XBL2 content may have to interact with bits of the original document DOM that it embeds. Regards, Maciej
Received on Sunday, 19 February 2006 03:11:55 UTC