- From: Maciej Stachowiak <mjs@apple.com>
- Date: Fri, 17 Feb 2006 14:15:29 -0800
- To: Ian Hickson <ian@hixie.ch>
- Cc: 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 1:44 PM, Ian Hickson wrote: > On Thu, 16 Feb 2006, Maciej Stachowiak wrote: >> >> - Any loading or embedding mechanism that gives access to the >> resulting >> http headers would prevent the use of <?access-control?> for any XML >> document on a server that uses cookies for login. A resource from >> another source would be able to steal the cookie, > > Indeed; any resource that returns an <?access-control?> PI would > have to > be one that the server knows will not be associated with any > DOM-accessible authentication information. > > (Note that this isn't privilege escalation, it's authentication > leakage > or cookie theft.) Fair enough. >> - Any loading or embedding mechanism that gives read/write access >> to the >> target's DOM cannot be used safely with <?access-control?>, >> because the >> loaded document can be used to execute script and reflect requests >> for >> resources that are supposed to be inaccessible. > > 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. Off-site XBL2 could probably use some security review, I'll try to find the time to read over the spec. Regards, Maciej
Received on Friday, 17 February 2006 22:16:00 UTC