EricLaw wrote: > --------------- > Versioning > --------------- > User-Agent header > What’s the use-case for adding a new token to the user-agent header? > It’s already getting pretty bloated (at least in IE) and it’s hard to > imagine what a server would do differently when getting this token.
The UA approach may be a botch, but it was an attempt at something like a less-verbose Accept-type header (six bytes in the UA, many more as a separate header which would have to be sent with every request, with no servers today actually understanding anything about CSP). Should the policy syntax ever change a server could theoretically send different syntax to a CSP/1 browser and a CSP/2 browser. The other approach is to version the response, a few extra bytes only when a server supports CSP. Yay, bandwidth win! But then what do we do? How does the server know which version to send? Should it send every version it knows about, and the client process the highest version it knows how to process? That means if we ever have a CSP-2 either clients are sending two complete headers (or three, or more) or they're sending their preferred version and users of clients which only support CSP-1 get zero protection rather than the 99% they actually support. In the case of brand-new directives older clients can simply ignore unknowns and that will work OK in many cases. Either loads of that type aren't supported at all (e.g. downloadable fonts, maybe?) or they can reasonably fall-back to the default allow directive. That might leave users of older clients vulnerable for that type (or only partially protected), but no worse than users of browser that don't support CSP at all. What if we change the rules? Suppose we add a "head" keyword to the script-src directive. Older clients will think that's a host named "head" and strip all the in-line <head> scripts the site relies on. In that case a versioned response actually works better for the site. The older clients get zero protection, much less than they are capable of providing (but the site still has to work to protect legacy browsers with no CSP at all), and at least the content isn't broken. > frame-ancestors > What exactly an “ancestor” is should probably be defined here. Would "frame-parents" make any more sense? Ties in to the window.parent property rather than introducing a new name for the concept > The “how many labels can * represent” problem has come up in a number > of contexts, including Access-Control and HTTPS certificate > validation. In the latter case, * is defined in RFC2818 as one DNS > label, but Firefox does not currently follow that RFC. Firefox 3.5 does, actually. The regexp syntax followed in older versions of Firefox was inherited from Netscape and predated the RFC by years. A small but vocal minority took advantage of the feature for internal servers, but given the lack of support in other browsers it was well past time to let it go. > • The spec might want to note that using wildcards does not permit > access to banned ports > http://www.mozilla.org/projects/netlib/PortBanning.html. Maybe an implementation note saying nothing in CSP prevents a user agent from blocking loads for other reasons. AdBlock will block additional loads, NoScript will block scripts, LocalRodeo will block access to RFC1918 addresses, etc. The Content Security Policy allows a site to define _additional_ restrictions it would like the client to impose for that content, but in no way is intended to loosen restrictions already imposed by the client for its own reasons. > • Scheme wildcarding is somewhat dangerous. Should the spec define > what happens for use of schemes that do not define origin > information? (javascript: and data: are listed, but there are > others). I am personally 100% against scheme wildcarding. There are so few schemes a site could reasonably want to allow that it shouldn't be hard to list them. > X-Content-Security-Policy: allow https://self > > Doesn’t make sense to me, because “self” is defined to include the > scheme. This suggests that we need a "selfhost" directive, which > includes the hostname only. Doesn't make sense to me either. "self" should be a keyword. If you want to stick schemes and ports on there then you should have to explicitly state your FQDN. > Violation Report: Headers > This seems like a potentially significant source of security risk and > complexity. For instance, the client must ensure that it won’t leak > Proxy-Authorization headers, etc. Maybe we should explicitly define which headers we will send. Do the Accept headers really help, for instance? We definitely want the method and the path, Host, Referer, Origin (when we have that), Cookie (and Cookie2 for UA's that support that). Anything else? The user-agent might be marginally useful for diagnostic purposes should different clients start reporting different errors, but could probably be gotten from the POST itself and not need to be repeated in the report body. I don't care either way, whichever might be more convenient for site authors. I suppose there are probably cases where a site serves content that's different enough in response to Accept headers that it's worth including them, although the Accept headers aren't under the control of the XSS-attempting attacker. > Parse Errors: User notification > If the “Fail closed” model is used, is there any way for the user to > know why the site is broken? Isn’t this going to create a problem, > where, say, a FF4 user will “downgrade” to a browser that doesn’t > support CSP (say, Opera 9) because the site “works properly there”? > Everyone loses. Since "user choice" is a fundamental principal of the Mozilla foundation we will almost certainly have some back-door way for an advanced user to tell the browser to ignore the site's Content Security Policy, but I wouldn't want to write that option into the spec. The spec should define what a conforming implementation should do. If a user wants to customize their browser into a non-conforming implementation that is outside the spec. While I think browsers should try to tell users why the content looks bad (just as we try to tell them why we're not accepting certain SSL certificates), I don't think the CSP spec should be dictating user presentation. Mozilla will be spitting violations into our Error Console at the very least, but whether we do something more visible to the user will probably come out of experimentation. > Agreeing with Sacolcor, I think the spec should explicitly note that > CSP isn’t intended to apply to User-Scripts, although I think the > Greasemonkey guys might find it hard to implement their current > feature-set considering where CSP is likely to be implemented in the > browser stacks. We're going to have trouble keeping 100% of current user scripts working. May have to add some API so Greasemonkey can actively participate in the content security policy model, such as by having user scripts declare which resources they're going to try to load so we can add them to the whitelist. > Scope Creep: exempt HEAD > We’ve had some folks suggest that CSP-like schemes would be more > easily deployed if they could allow arbitrary script/css to be > embedded inline/referenced in the HEAD tag. Gerv's original Content Restrictions allowed this, too. I'm not convinced the people who suggest that have looked at real-life pages. Even with <head> scripts allowed CSP will require massive rewrites of most pages, and XSS injection does happen in the <head>. Worth keeping in mind after we get some experimentation, but I'd rather start out with a stricter policy and loosen than the reverse. > (CSP currently seems to only apply to HTML documents, not > "resources" in general). CSP is currently a document-focused policy. > It seems natural that a subdownload should be able to say e.g. Content- > Security-Policy: callers <originlist> That's not too far off from what frame-ancestors does (which was also a scope-creep). Could they be combined in some way? I'd like something like that, but won't concerned sites want to enforce it server-side? A reliable Referer, or the Origin/Sec-From header would seem more useful there. -Dan Veditz _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
