CSP: Duplicate Directives should "add" instead of be ignored

[devd]

the policy

object-src 'none'; object-src 'self';

right now enforces "'none'". Instead, I think it should append to the list of allowed object sources.

CSP is already eminently unprogrammable based on control flow. Right now, the only way to set a CSP policy is to look at URL and set it. This reduces flexibility because later on, the code might realize "I need to include an object".

But now, it is impossible to take the existing CSP policy and append to it without writing a CSP policy parser. AppServers only provide the API of setting a header and reading a header. The only alternative is to keep csp in a variable that is an array of hosts in a dictionary of directives and then modify that as you process and then at the end, serialize that and add that as a header. This is still very painful.

In general, the CSP will be written by the security / paranoid person in the team and not by all developers. After trying to use CSP at scale, I am convinced that it is more important to keep the CSP policy programmable instead of designing it to be a super paranoid "fail-closed" model, which is doing more harm than good.

If you are worried about "how can a team ensure an absolute minimum policy?", we can do that by setting an additional header (since if there are 2 policies, both are enforced). Or, the CSP pinning proposal.

FWIW, this is part of the reason why policy is "https://* data:" for most things other than scripts,objects because it is so painful to adapt the policy based on what the response is going to be. This also makes "hash-src" adoption difficult and we don't remove unsafe-inline/nonce even if the page doesn't need that.

[mikewest]

Ok. This is reasonable feedback. I think we could come up with a reasonable combining ruleset for parsing a single policy. I wonder if there's a way we could make it opt-in; perhaps the first occurrence could be something like object-src 'none' 'extensible'?

[devd]

that sounds good to me.

[devd]

although, I would prefer a directive instead of a host-src so that I don't have to keep writing it again and again and again for each directive.

[hillbrad]

Maybe just + ?

On Sat, Mar 21, 2015, 8:57 PM Devdatta Akhawe notifications@github.com wrote:

although, I would prefer a directive instead of a host-src so that I don't have to keep writing it again and again and again for each directive.

— Reply to this email directly or view it on GitHub https://github.com/w3c/webappsec/issues/221#issuecomment-84514174.

[devd]

So I would use object-src+ everytime?

[mikewest]

I was imagining that 'extensible' would only be required for the first occurence of a directive. We're currently preventing the (probably marginal) risk of partial header injection. We can keep that property by opting into the new behavior the first time, but I don't think we'd gain anything by requiring it for every occurence.

Or, did you mean that specifying the source expression for each directive was too much? I imagine specifying it on default-src could have the behavior you're looking for for a whole policy.

[devd]

specifying the "extensible" source expression for each directive is too much. Section 7 of the spec has 18 subsections!

[mikewest]

Ok. I guess that's an argument for making it a standalone flag.

[mikewest]

(Which, I suppose, would be required to come before any directives which you intended to extend)

[dveditz]

"Do we allow 'none' to be extended?" seems like a slightly different question than "do we allow adding hosts to a directive?". Or put another way, is 'none' simply a placeholder for an empty list or is 'none' a stronger assertion about the absence of a particular kind of content?

[devd]

not sure I understand: what's the difference? The key question to me is whether injection in the CSP policy is a threat to worry about and I think we can make the policy more flexible by not caring about that threat.