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

On Feb 17, 2006, at 2:15 PM, Maciej Stachowiak wrote:

>>
>> 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.
>
> This might be an appropriate mechanism for off-site XBL2; I haven't  
> examined it in enough detail to know. But from your explanation  
> that sounds likely. XBL2 documents would also have to make sure not  
> to reveal any authentication information via the DOM, so no  
> document.cookie for instance.

I thought about this some more, and it no longer makes sense to me.  
If off-site XBL runs in the security context of the referencing  
document, not the XBL document, then why would <?access-control?> be  
useful? It is not possible to execute an attack against the site  
hosting the XBL document, so there is no reason for it to restrict  
access.

If XBL2 script executes in the security context of the referring  
document, what would be desirable is a way to include a CSS  
stylesheet without allowing inclusion of cross-domain XBL (or at  
least restricting what domains it may come from).

In fact, this should probably be default for existing stylesheet  
inclusion mechanisms, since traditionally CSS has been seen to have  
the same security implications as static content, such as off-site  
images; XBL2 would make off-site stylesheets have the same security  
implications as off-site script, which are basically "you'd better  
really trust whoever you are getting this from".

<?access-control?> might be useful if XBL2 went the other way and  
made XBL2 script execute in the security context of the site hosting  
the XBL2 document. But that would raise the authentication theft and  
privelege escalation attacks I mentioned, unless access to the XBL2  
shadow DOM is restricted. And since XBL2 allows embedding of content  
from the source document back into the XBL2 shadow tree, access would  
have to be restricted the other way too. I am not sure if this is a  
feasible design, as I don't know to what extent XBL2 content may have  
to interact with bits of the original document DOM that it embeds.

Regards,
Maciej

Received on Sunday, 19 February 2006 03:11:55 UTC