 |
Newsgroups: mozilla.dev.security
From: Daniel Veditz <dved...@mozilla.com>
Date: Wed, 08 Jul 2009 01:02:13 -0700
Local: Wed, Jul 8 2009 4:02 am
Subject: Re: Content Security Policy Spec questions and feedback
EricLaw wrote: The UA approach may be a botch, but it was an attempt at something like > --------------- > 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. 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 In the case of brand-new directives older clients can simply ignore What if we change the rules? Suppose we add a "head" keyword to the > frame-ancestors Would "frame-parents" make any more sense? Ties in to the window.parent > What exactly an “ancestor” is should probably be defined here. property rather than introducing a new name for the concept > The “how many labels can * represent” problem has come up in a number Firefox 3.5 does, actually. The regexp syntax followed in older versions > 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. 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 Maybe an implementation note saying nothing in CSP prevents a user agent > access to banned ports http://www.mozilla.org/projects/netlib/PortBanning.html. 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 I am personally 100% against scheme wildcarding. There are so few > what happens for use of schemes that do not define origin > information? (javascript: and data: are listed, but there are > others). 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 either. "self" should be a keyword. If you want > Doesn’t make sense to me, because “self” is defined to include the to stick schemes and ports on there then you should have to explicitly state your FQDN. > Violation Report: Headers Maybe we should explicitly define which headers we will send. Do the > 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. Accept headers really help, for instance? We definitely want the method and the path, Host, Referer, Origin (when The user-agent might be marginally useful for diagnostic purposes should I suppose there are probably cases where a site serves content that's > Parse Errors: User notification Since "user choice" is a fundamental principal of the Mozilla foundation > 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. 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 > Agreeing with Sacolcor, I think the spec should explicitly note that We're going to have trouble keeping 100% of current user scripts > 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. 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 Gerv's original Content Restrictions allowed this, too. I'm not > 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. 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 > (CSP currently seems to only apply to HTML documents, not CSP is currently a document-focused policy. > "resources" in general). > It seems natural that a subdownload should be able to say e.g. Content- That's not too far off from what frame-ancestors does (which was also a > Security-Policy: callers <originlist> scope-creep). Could they be combined in some way? I'd like something like that, but won't concerned sites want to enforce -Dan Veditz You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
| |||||||||||||