On Sat, 18 Feb 2006, Maciej Stachowiak wrote:
>
> 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?
You want to prevent people from being able to use off-site XBL files
without those files being intended for that purpose because otherwise you
would be allowed to fetch any arbitrary XML on any site (including, e.g.,
authenticated extranet or intranet sites).
> 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.
<?access-control?> in an XBL context is not used for preventing direct
attacks, but for preventing data theft.
> 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).
That is also a concern. I haven't attempted to see how to resolve that
concern yet. I wouldn't think <?access-control?> would help here.
> 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".
Indeed; there were attacks on a very well-known community site recently
that were directly related to this problem. It is a real problem.
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'