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

Yes, your comments are certainly well understood by myself.  They are 
also well written and a good basis for further discussion.  The 
access-control mechanism does not in any way separate execution contexts 
or in any other way handle cross-site scripting issues, but instead is 
designed to enable "network file read" access to a wider range of XML 
data sources while still preserving the general sandboxing restrictions 
of a  "network file read."

Simply, the purpose of the access-control header is to allow XML 
document authors to make their content available to other web 
applications. 

Let me try summarizing the security issues you raise... please 
edit/amend/extend as necessary:

1) An XML document provider may want to expose their XML data to a 
referring application, but likely does not also intend to expose their 
cookie and header data. 
2) Executing any content retrieved by this mechanism implicitly grants 
that content security permissions of the referring document.

You are correct that we do not have either of these two issues in the 
VoiceXML <data/> element use of this capability. 

I was not involved in the recent discussion about taking this Note to 
REC.  With the proliferation of AJAX, I do believe the use-case for 
being able to allow referring applications to make use of published XML 
data (weather data, mapping coordinates, flight tracking information) 
exists and that this Note could be implemented effectively for that 
use-case.  That use-case is admittedly more narrow than solving the 
general cross-site scripting problems, but still may be important enough 
to consider taking to REC.

Brad


Maciej Stachowiak wrote:

>
> 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 05:04:13 UTC