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:07 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 30 October 2006 12:49:02 GMT