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

On Feb 16, 2006, at 9:04 PM, Brad Porter wrote:

> 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."

Yes, I think the problems are twofold:

1) Some people think this would be a suitable mechanism for a  
restricted cross-site scripting mechanism; that is not the case.

2) There is no obvious mechanism in HTML/SVG UAs which gives *only*  
the semantics of a network file read, without opening up one of the  
attacks I mentioned. In fact, I read over DOM Level 3 Load and Save,  
and I think event hat would not be a suitable mechanism because it  
gives you unrestricted access to the Document object that results  
from the load. I think VoiceXML's <data> may be the only mechanism  
that is sufficiently restricted.

> 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.

Correct.

> 2) Executing any content retrieved by this mechanism implicitly  
> grants that content security permissions of the referring document.

Actually, what I had in mind was the other way around. If you have  
write access to the content retrieved by this mechanism, and the  
content has access to scripting features (such as <script> elements  
or event listeners), you can inject scripting content which will then  
run in the security domain of the loaded document. This allows you to  
then freely access any other resource on the site that held the  
referred-to 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.

AJAX typically uses either XMLHttpRequest or a hidden html <iframe>  
element, the Note is not safe to use with either of these mechanisms.  
It would require a new loading mechanism to use it safely.

> 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.

I agree in principle, but I believe the Note as written does not  
address this use case.

Regards,
Maciej

Received on Friday, 17 February 2006 21:26:28 UTC