- From: Ian Hickson <ian@hixie.ch>
- Date: Fri, 17 Feb 2006 21:44:56 +0000 (UTC)
- To: Maciej Stachowiak <mjs@apple.com>
- 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 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.) > - 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. I agree that <?access-control?> would not be a solution for cross-site XMLHttpRequest, <object>, <iframe>, <frame>, or other systems; anyone who thinks that it would be is, as you point out, failing to understand the scope of the problems. The use case that originally raised interest in <?access-control?> beyond the voice browser working group is, however, safe (assuming the PI is not used on sites where cookie theft is an issue). I do not believe anyone has seriously suggested that <?access-control?> be used as a generic mechanism beyond allowing the use of third-party XBL2. I agree that the specification should be absolutely clear about these risks. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 17 February 2006 21:45:14 UTC