CSP directive controlling manifest loads?

[mikewest]

Two question here:

1. Do we need to add something to CSP to control the sources from which manifests can be loaded? e.g. manifest-src 'self' or the like? Or do you see this fitting into an existing category?
2. Do you envision the requests generated by a manifest (icons, currently, probably other stuff in the future?) being governed by the policy of the page which requested the manifest? Or the policy delivered with the manifest (via HTTP headers)? Or the policy specified in the manifest? It's not clear to me what you're proposing; we should be clear about it either here in this spec, or in CSP itself.

[marcoscaceres]

@mikewest, I'm reading the CSP spec again - hence my filing bugs over on your repo. However, I'm a CSP n00b so your guidance would be appreciated. I don't have an opinion, so I'm pretty open to whatever recommendations you might have.

Hopefully later today I will be able to have a bit more of an informed opinion about this.

[marcoscaceres]

Just to be clear, #iamdoincsp 💃

[mikewest]

1. Awesome!
2. You're looking for <meta http-equiv="Content-Security-Policy" content="[policy goes here]">. I've added an example to the spec. :)
3. I'll try to find you on IRC to chat briefly today or Friday about the options.

[mozfreddyb]

I see you're working at Mozilla, @marcoscaceres ;) If you're testing in Firefox, you have to use the HTTP Header for now.

[anssiko]

1. I'd be counting on the WebAppSec participants to give us an informed recommendation.
2. This is largely undefined unless @marcoscaceres has done an overhaul on the spec recently ;)

For the "CSP in the manifest", we a draft extension at: http://w3c.github.io/manifest-csp/

In the "core" manifest spec we state that "The appropriate time to obtain the manifest is left up to implementations". That is, some implementations might obtain the manifest only when the user explicitly asks the UA to do so (think how the Atom/RSS feed is obtained only when the user clicks the feed button), while some may obtain it upfront when the page associated with the manifest is loading (we don't delay the load event, however). I assume this would mean that both the HTTP header as well as the security policy of the resource associated with the manifest (the page that includes ) could be technically enforced for the manifest.

The question is, do we want to have a dependency on CSP delivered with the resource that is associated with the manifest? That is, the Content-Security-Policy HTTP header and the associated ? We can only deliver CSP for the manifest via the HTTP headers. That may be problematic using hosting services (such as GH pages, I think).

Not answering your questions perhaps, as I'm not yet settled on this issue. Please let us know what makes sense to you?

[marcoscaceres]

@mozfreddyb thanks for the tip!

[marcoscaceres]

Summary of chat with @mikewest and @anssiko about how this is gonna work.

• Like HTML documents, a manifest can have an associated CSP policy. That policy can only be delivered over HTTP.

• The CSP spec will add a new manifest-src directive which will determine where manifests can be loaded from. This is for HTML documents. The policy applied to the HTML document does not apply to the manifest. The server must send a policy explicitly for the manifest.

Question: What is the default policy for manifests? Can they get images from anywhere?

• When a manifest is requested by the user agent, a policy can be delivered by the server along with the manifest using a HTTP header. That policy dictates what the manifest can/can't load. The policy applied to the manifest does not affect HTML documents - they are independent and don't interact.

For instance, in the following example, the second icon would not load:

HTTP/1.1 200 OK
Content-Type: application/json
Content-Security-Policy: img-src icons.example.com;

{
    "name": "custom manifest",
    "start_url": "http://boo",
    "icons": [{
        "src": "//icons.example.com/lowres"
      },
      {
        "src": "//other.com/hi-res"
      }]
}

• The csp member, will determine the policy for a URL scope. When the URL scope is missing in the manifest, the policy applies to the document associated with the manifest (the implicit or explicit "start_url").

Note that the csp member DOES NOT apply to the manifest itself - authors MUST use a HTTP header to control, for instance, where icons can be obtained from.

• The policy is applied to all resources in the URL scope as if it was a HTTP header. Requested documents can contain their own policy (as either HTTP headers or meta tags). So it's the union between the csp member and any other HTTP headers that makes up the policy. This policy can then interact with any meta elements on a per document basis.

Please confirm that I have gotten this correctly.

Question. What happens if the user agent load manifest from "bar.com" and it includes the following?:

{
   "csp": "manifest-src foo.com"
}

I guess it's too late by then, as the manifest has loaded.

[anssiko]

@marcoscaceres Thanks for documenting our discussion, this is exactly how I recall it as we adjourned :)

Re your last question: I'd say we ignore the manifest-src directive in the csp member, as we cannot introspect the manifest without first fetching it (similarly to how a <meta> cannot prevent the HTML document from being loaded). But I'll defer to @mikewest to give us a more informed answer, and check whether this issue is unique to this directive. I'll update the csp extension spec accordingly once we have consensus on this issue.

Btw. I'd like to borrow some of the illustrations to a non-normative section of the http://w3c.github.io/manifest-csp/ spec.

[marcoscaceres]

@anssiko happy to give you the graphics. I have them as SVG as they were created in Sketch.

[marcoscaceres]

Seems I accidentally reopened this... was closed via 5d2eccc.