- From: Maciej Stachowiak <mjs@apple.com>
- Date: Thu, 16 Feb 2006 17:51:40 -0800
- To: Brad Porter <bwporter@tellme.com>
- Cc: Anne van Kesteren <annevk@opera.com>, www-voice@w3.org, public-webapi@w3.org, public-appformats@w3.org
Hi everyone, I read over the <?access-control?> PI specification at the request of Anne van Kesteren and I noticed that it would allow privelege escalation attacks if combined with certain embedding and loading mechanisms, such as ebedding elements found in HTML and SVG, or XMLHttpRequest. This may have been obvious to the authors of the Note, since it is recommended for use with VoiceXML's <data> which provides highly restricted access to the DOM. However, it may not be obvious to readers of the Note, for example Anne initially thought it could be suitable for standardization as a general mechanism for securely restricted cross-site scritping. Therefore, I recommend the following: * If anyone is implementing <?access-control?> based loosening of the security sandbox for anything besides <data>, you should stop because your use is likely not secure. * The Note should be updated to make very clear that it is not secure when used with contructs that allow modification of the loaded DOM, access to http headers, access to the nonstandard but widely implemented document.cookie property, or possibly other things. This includes but is not limited to HTML's and XHTML's <frame>, <iframe> and <object> elements; SVG's <foreignObject>, <animation> and <use> elements; and networking APIs such as XMLHttpRequest. In case the attack modes are not obvious, here are some I thought of. - 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, - Similarly any loading or embedding mechanism that allows scripting access to the document.cookie property cannot safely be changed to support <?access-control?>. This too would allow 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. Example: Embed an HTML or SVG document via an HTML or SVG embedding element that grants scripting access onlye due to <?access-control?>. Now insert a <script> element into it via the DOM which loads a futher embedded document of your choice from the access-controlled document's origin server, and copies its data back to the original embedded document. Now read the data back into the embedding document. This means that if things like <object> or <foreignObject> granted access to documents due to <?access-control?>, then any server that grants access to one resource through <?access-control?> is effectively granting access to all resources. For these reasons, I think the Note should make very clear that <? access-control?> must not be respected by the kind of loading and embedding mechanisms I have mentioned, and implementors and content authors should be aware of the risks. I also think this is a reason not to take the Note to REC, unless it is specifically scoped to <data> or other embedding mechanisms that offer only severely restricted scripting access. Even so it would need a detailed Security Considerations section. Please pardon if this message is stating the obvious; it was not obvious to me until I carefully read the Note and thought about it. Regards, Maciej
Received on Friday, 17 February 2006 01:52:34 UTC