W3C home > Mailing lists > Public > www-voice@w3.org > January to March 2006

<?access-control?> allows privelege escalation attacks with many embedding mechanisms

From: Maciej Stachowiak <mjs@apple.com>
Date: Thu, 16 Feb 2006 17:51:40 -0800
Message-Id: <0AB289E1-FA7D-4767-98B7-4755556B87E3@apple.com>
Cc: Anne van Kesteren <annevk@opera.com>, www-voice@w3.org, public-webapi@w3.org, public-appformats@w3.org
To: Brad Porter <bwporter@tellme.com>


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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 30 October 2006 12:49:02 GMT