W3C home > Mailing lists > Public > public-webappsec@w3.org > June 2013

Re: Fetching contexts

From: Adam Barth <w3c@adambarth.com>
Date: Sat, 22 Jun 2013 22:03:13 -0700
Message-ID: <CAJE5ia9ou9MH5AKFHP_Agpo-B_mfsSf-vz7_s_u=x4fmSybGLw@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: Boris Zbarsky <bzbarsky@mit.edu>, Gordon Hemsley <me@gphemsley.org>, WebAppSec WG <public-webappsec@w3.org>
On Thu, Jun 20, 2013 at 12:27 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
> Context: http://wiki.whatwg.org/wiki/Contexts (hah)
>
> On Fri, Jun 7, 2013 at 1:35 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>> We should probably add at least workers, XMLHttpRequest, SVG resource
>> documents, document.load, XSLT.  Probably eventually the components import
>> stuff.
>
> It seems XMLHttpRequest is connect-src. Workers are covered by
> script-src.  HTML component imports are covered by script-src (for
> now).
>
> Not clear about SVG,

It depends on how you load SVG.  If you use <img src="foo.svg">, then
it's covered by the img-src directive.  If you use <iframe
src="foo.svg">, then it's frame-src.  If you use <object
data="foo.svg">, then it's object-src.

More generally, CSP cares about the API that generated the fetch, not
about the type of resource returned by the server.

> document.load,

That's a script-based API, so it's in the connect-src bucket.

> and XSLT. Adam?

You might think that XSLT is controlled by style-src because it's
styling information, but we've actually put it into the script-src
bucket because it's just as powerful as script.  You can see some
discussion of this topic if you search for XSLT in
https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html.

>> Does EventSource do a fetch internally?
>
> Yes.
>
>> I'm not sure whether any UAs fetch DTDs in practice, but if so they should
>> be added too.
>
> I think we should treat that as a bug :-)

I don't think there's anything in CSP that controls DTD fetches.  Do
any user agents actually fetch DTDs?

>> <object> might need to be a separate context from "nested browsing" and
>> "plugin", possibly.  It really depends on how the spec for it reads.
>
> It seems object-src is defined as being applicable to any kind of
> fetching <object> / <embed> / <applet> might do. Calling it a plugin
> context might be somewhat misleading, but I don't have a better idea.

Yeah, that was a topic of discussion on public-webappsec for a while,
but we settled on the "syntax-based" approach in the spec.  That means
<object> is controlled by object-src regardless of whether it ends up
creating a nested browsing context or a plugin.

Adam
Received on Sunday, 23 June 2013 05:04:12 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:02 UTC