Sounds like you're proposing that the principal that XBL gets should be
based off of the principal of the stylesheet that attaches the binding.
Do I have that right? I'll have to re-examine the XBL exploits that
were found before I did all the tightening up on the model.
By the way, there is a long-standing bug about this problem. 59701. We
ran into this just as you have, since we've been wanting to build drag
and drop behavior into the embedding world using XBL (since we have all
the behavior over in XUL JS right now).
One exploit that immediately comes to mind is that someone could load a
chrome URL stylesheet from a remote Web page and then use the CSS object
model to add in new rules that point to remote XBL bindings.
So now that I think about it, you can't blindly use the CSS file's
principal. Maybe a model where you use the *least* privileged of the
CSS principal and the XBL document's principal? That way trusted CSS
pointing to untrusted XBL would result in untrusted XBL, but trusted CSS
pointing to trusted XBL would result in trusted XBL, even when bound to
an untrusted document. (Whew!)
dave
([EMAIL PROTECTED])
Stuart Ballard wrote:
> Perhaps the difference in our opinions is because you are assuming the
> binding will be attached by remote CSS, and I'm assuming it will be
> added in (say) html.css. (Consider the XBL-form bindings too - there's
> no reason for them not to be privileged, if necessary).
>
> I should clarify, then, that I'm assuming that remote CSS would not be
> able to attach to a chrome:// binding, and only trusted (eg chrome://)
> CSS would be able to access these trusted bindings. Would that address
> your concerns while still allowing the XBL code to run privileged?
>
> Stuart.
>
