Bug 103228 - CSP 1.1: Teach ContentSecurityPolicy about policy sources.
Summary: CSP 1.1: Teach ContentSecurityPolicy about policy sources.
Status: RESOLVED LATER
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebCore Misc. (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Mike West
URL:
Keywords:
Depends on:
Blocks: 85558
  Show dependency treegraph
 
Reported: 2012-11-26 01:40 PST by Mike West
Modified: 2013-01-04 00:53 PST (History)
4 users (show)

See Also:


Attachments
Patch (14.72 KB, patch)
2012-11-26 02:48 PST, Mike West
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Mike West 2012-11-26 01:40:30 PST
We're accepting Content Security Policies via either an HTTP header or meta element, and there's discussion in the WG regarding the way we parse/handle the header's content. `report-uri`, for instance, might or might not be something we want to support in the meta element. Likewise, we almost certainly don't want to suport `reflected-xss` in the meta element.

To support those sorts of distinction, we should teach the CSP object about the source of the policy. This is probably as simple as adding an enum. I'll take a look today.
Comment 1 Mike West 2012-11-26 02:11:40 PST
Ugh. The actual change here is very straightforward, but things end up being piped through eighty-three levels of worker context shifts*, and back and forth between Chromium and WebKit. Not pretty.

I'd also end up requiring a new `deprecatedSource` method to match `deprecatedType`. I don't really want to add an instantly deprecated method. :)

I'm not sure the distinction is even relevant for workers (at least, the directives being discussed right now don't seem relevant). I'll throw up a patch that papers over the problem with a Worker source, just to get a conversation going.

*this number might be slightly exaggerated.
Comment 2 Mike West 2012-11-26 02:48:17 PST
Created attachment 175951 [details]
Patch
Comment 3 Mike West 2012-11-29 00:10:15 PST
Friendly ping. I'm hopeful that we can either avoid piping this through workers, or find a mechanism that lets us do it without tons of busywork. :)
Comment 4 Adam Barth 2012-11-29 15:32:23 PST
This seems too speculative at the moment.  We don't know how this conversation is going to pan out in the working group.  If we end up needing this flag, this isn't an unreasonably way to wire it in, but it's not clear to me whether we're going to need it.
Comment 5 Mike West 2012-11-30 12:18:59 PST
(In reply to comment #4)
> This seems too speculative at the moment.  We don't know how this conversation is going to pan out in the working group.  If we end up needing this flag, this isn't an unreasonably way to wire it in, but it's not clear to me whether we're going to need it.

If meta or html@policy or whatever remains in 1.1, we'll quite likely need something along these lines for 'reflected-xss' (assuming that remains in 1.1 as well). *shrug* I'll mark this LATER for the moment, and come back to it when it's more pressing.
Comment 6 Eric Seidel (no email) 2013-01-04 00:53:14 PST
Comment on attachment 175951 [details]
Patch

Cleared review? from attachment 175951 [details] so that this bug does not appear in http://webkit.org/pending-review.  If you would like this patch reviewed, please attach it to a new bug (or re-open this bug before marking it for review again).