On 10/27/2009 02:33 AM, Adam Barth wrote:
My technical argument is as follows. I think that CSP would be better off with a policy language where each directive was purely subtractive because that design would have a number of simplifying effects:
I couldn't find a comment that summarizes the model you are proposing so I'll try to recreate your position from memory of our last phone conversation. Please correct me where I'm wrong.
I believe you advocate a model where a site specifies the directives it knows/cares about, and everything else is allowed. This model would make the default "allow" directive unnecessary. The main idea is to allow sites to restrict the things it knows about and not have to worry about inadvertently blocking things it doesn't consider a risk.
My main objection to this approach is that it turns the whitelist approach we started with into a hybrid whitelist/blacklist. The proposal doesn't support the simple use case of a site saying: "I only want the following things (e.g. script and images from myself). Disallow everything else."
Under your proposal, this site needs to explicitly opt-out of every directive, including any new directives that get added in the future. We're essentially forcing sites to maintain an exhaustive blacklist for all time in order to avoid us (browsers) accidentally blocking things in the future that the site forgot to whitelist.
1) Forward and backward compatibility. As long as sites did not use the features blocked by their CSP directives, their sites would function correctly in partial / future implementations of CSP.
Under your proposed model, a site will continue to "function correctly" only in the sense that nothing will be blocked in newer implementations of CSP that wouldn't also have been blocked in a legacy implementation. From my perspective, the blocking occurs when something unexpected by the site was included in the page. In our model, the newer implementation, while potentially creating an inconsistency with the older version, has also potentially blocked an attack.
Are you suggesting that a blocked resource is more likely to have come from a web developer who forgot to update the CSP when s/he added new content than it is to have been injected by an attacker? This seems like a dangerous assumption. All we are getting, in this case, is better consistency in behavior from CSP implementation-to-implementation, but not better security.
2) Modularity. We would be free to group the directives into whatever modules we liked because there would be no technical interdependence.
I actually don't see how opt-in vs. opt-out has any bearing at all on module interdependence. Maybe you can provide an example?
Let's also not forget that CSP modularity really only helps browser vendors. From the perspective of websites, CSP modules are just one more thing that they have to keep track of in terms of which browsers support which modules. I support the idea of making it easier for other browser vendors to implement CSP piecemeal, but our primary motivation should remain making the lives of websites and their users better.
3) Trivial Combination. Instead of the current elaborate algorithm for combining policies, we could simply concatenate the directives. An attacker who could inject a Content-Security-Policy header could then only further reduce his/her privileges.
In the case of an injected header, this is already the case now. We intersect both policy sets, resulting in a combined policy more restrictive than either of the two separate policies.
If we are talking about an attacker who can inject an additional directive into an existing CSP header then, yes, the attacker could "relax" the policy intended to be set by the site. I'm not sure how much I care about this case.
4) Syntactic Simplicity. Instead of two combination operators, ";" for union and "," for intersection, we could simply use "," and match standard HTTP header syntax.
Okay, sure.
Balancing against these pros, the con seem to be that we hope the additive, opt-out syntax will prod web developers into realizing that adding "script-src inline" to the tutorial code they copy-and-paste is more dangerous than removing "block-xss".
Those seem equivalent to me, so I'm not sure which model your example favors.
In general, I'm slightly skeptical of the view that we need to base our design around the fact that admins will copy-paste from tutorials. Sure, this will happen in practice, but what is the probability that such a site is a high value target for an attacker, and by extension how important is it that such a site gets CSP right? Remember, a site cannot make their security profile any worse with CSP than without it.
I do want CSP to be easy to get right. I should do some homework and collect some stats on real world websites to support the following claim, but I still maintain that a HUGE number of sites will be able to benefit greatly from a minimal policy such as "allow 'self'". Even "allow *" would be a gigantic improvement in terms of blocking all the common XSS vectors.
My contention is that CSP tutorials should (and will if we evangelize properly) instruct sites to start with a minimal policy such as "allow 'self'" and incrementally add policy until the site behaves as expected. This approach will result in minimal policy set and will tend to be optimal in terms of bandwidth and risk profile.
Cheers, Brandon _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
