(I'm moving a thread to NNTP at the request of Gerv. Thanks for reading!) The following is a weakly-organized list of my questions and thoughts on the current CSP spec draft. (See http://blogs.msdn.com/ie/archive/2009/06/25/declaring-security.aspx if you're interested in higher-level feedback)
--------------- Versioning --------------- Server CSP Versioning Can the server define which version of CSP policies it wants to use, allowing the client to ignore? I know that backward compatibility is the goal, but other successful features (E.g. Cookies) have had tons of problems here as they try to evolve. The current “Handling parse errors” section imposes a number of requirements that might be onerous in the distant future when we’re on version 5 of the CSP feature. 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. --------------- Policy Questions --------------- Style-src I don’t know what “style attributes of HTML elements” means. Is this meant to cover cases where a CSS rule specifies url() for a font/ cursor/image? Or are those meant to be controlled by the other relevant CSP directives? frame-ancestors In addition to IFRAMEs/FRAME tags, this should also restrict OBJECT tags that point to HTML pages, correct? What exactly an “ancestor” is should probably be defined here. I like this directive, but it’s worth noting that this is the only directive which constrains how others can host the protected- document. More on this later (see Scope Creep below). --------------- CSP Declarations --------------- HTTP: Header Name W3C folks have been giving us (IE) a hard time about the number (and scattered documentation) of X- header names http://blogs.msdn.com/ieinternals/archive/2009/06/30/Internet-Explorer-Custom-HTTP-Headers.aspx, and they’ve strongly encouraged us to register our header names (even provisionally) with IANA http://www.iana.org/assignments/message-headers/message-header-index.html rather than using the X- prefix. You don’t need a formal RFC to do this (some just point to the relevant working groups), and you’ll find some of the header names proposed by Jackson and Barths listed there already. I think Content-Security-Policy is well-thought-out enough that it’s going to get implemented by more than one UA, and we might as well save a few terabytes of traffic over the next several years by dropping the X-. Mark Nottingham (HTTPBis chair, I think) is probably a great person to talk to about this if you want more info on best practices for header definition. HTTP Header: Final It seems like it might be useful for a CSP Header to declare that it’s the “Final” security policy, to prevent meddling by META Header injection and the like. Of course, HTTP Header injection is a threat as well, but that seems like a smaller threat, and the “FINAL” directive doesn’t really significantly increase attack surface here because sites using the Header are unlikely to also send the META tag. Meta Tag Placement I like the restriction that META must appear within the HEAD, although technically HTML5 has no such restriction. Are relative URIs valid for the report-URI/policy-URI? (Seems like this would be a good thing to support). However, if so, is there any interaction/relationship with the BASE tag, which is supposed to also appear early in the head? The spec needs to specifically define what happens if a META tag is found in violation of the rules (e.g. It MUST be ignored, and a CONSOLE ERR must be raised) CSP-Tagging What happens to CSP if I save a CSP-protected document to my local disk? I’d assume it would be ignored (because many restrictions could be broken) but this should be explicit. Also, when saving docs to disk, HTTP headers are lost, so to preserve it, you’d need to explicitly serialize to a META tag, which could get complicated if the document already had a CSP META… --------------- Policies and Wildcarding --------------- Wildcarding: Multiple Labels Allowing a wildcard to represent an unlimited number of DNS labels could be problematic, because it leaves the wildcard-configured site at the mercy of the DNS policies of any of its children. I think there’s a use case that suggests a single-label wildcard would be useful but a multiple-label wildcard incurs unneeded attack surface for some. 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. Wildcarding: Zero Labels In a related vein, wildcards are currently defined as “one or more labels” by the CSP spec. Real-world sites have the unfortunate habit of serving content from both “example.com” and “www.example.com” which is likely to cause site breakage when CSP is in use. Unfortunately, trivially redefining a wildcard to “zero or more labels” doesn’t quite work because then there’s a leading dot we’d have to get rid of, but I’d propose that this is probably the simplest/most intuitive fix. Therefore, a site could specify “*.example.com” to match “www.example.com” and “example.com”. Wildcarding: Port & Scheme As the intent is to allow wildcarding of the port, and constrained- wildcarding of the scheme, it might make sense to provide explicit examples of each in the document. • The spec might want to note that using wildcards does not permit access to banned ports http://www.mozilla.org/projects/netlib/PortBanning.html. • 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). Sample Policy definitions The example: 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. --------------- Reporting issues --------------- Violation Report: Headers I don’t think I understand the use case for sending the request headers. Is the hope that the server operator be able to use this to catch XSS attempts and go plug holes to protect legacy clients? If so, should the Violation Report Sample example be explicitly be updated to show such an injection attempt being caught? 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. Also, the “blocked-headers” is defined as required, but not all schemes (specifically, FTP and FILE) do not use headers. Data Leak Vectors Per other parts of the spec, “all reports must be sent to the same host” should read “all reports must be sent to the same Origin (scheme/ port/host).” The section “Restrictions on policy-uri and report-uri” has a similar problem. Violation Report Syntax: How to send It probably should be restated in this section that redirects are not to be followed. This section says that the report must be “transmitted” but does not explain how such transmission should occur. I assume the proposal is to use a HTTP POST. If so, this should be stated. Problem: Neither FTP, nor File, nor a number of other schemes support POST. Violation Report: No redirects I like the simplicity of forbidding redirects outright, but I think there’s going to be a complaint that same-origin redirection via 307 ought to be permitted. As a designer, I’d probably ignore that complaint, but I bet it’ll be made eventually. Parse Errors: Server detection Parse errors are defined as only being reported on the client. This is probably reasonable, but leads to the possibility that some UA will fail to parse some CSP directive and the server operator will not know about it. 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. --------------- Misc --------------- User-Scripts 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. Broken link The “CSP Syntax” link seems to be broken, and goes to the general introduction page? When any known directive contains a value that violates [[CSP syntax]] --------------- Logical evolutions aka Scope Creep --------------- 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. Presumably, you still get some solid security value here because the HEAD is a much smaller part of the document to protect from injections. Scope Creep: Prevent Sniffing & Unintended Reuse It seems natural that a subdownload should be able to say Content- Security-Policy: strictType which would cause a UA to refuse to sniff content or feed it to tags of mismatched typing (e.g. text/plain resource fed to a <SCRIPT> element, etc). This would go beyond IE's X- Content-Type-Options directive. In particular, this could be used by non-JS responses to explicitly prevent them from being used by SCRIPT tags, and to prevent HTML files from being scraped by liberal CSS parsers. This is an anti-CSRF ASR. Scope Creep: Same Origin Only The claim “Content Security Policy enables a site to specify which sites may embed a resource” is currently over-broad, but it shouldn’t be. (CSP currently seems to only apply to HTML documents, not "resources" in general). It seems natural that a subdownload should be able to say e.g. Content- Security-Policy: callers <originlist> which would cause the UA network stack to refuse to process (e.g. Set-Cookie) or return the content (to a script tag, object tag, image tag, XHR request etc) unless the Origin of the requestor matches the specified Origin list. (A competing idea is to respect Access-Control-Allow-Origin response headers on all types of requests (not just XHR) but I don’t think that’s what’s currently being proposed?) This allows for a useful CSRF/bandwidth misuse protection at little cost. I’m not fully convinced that the “Origin” proposal (or at least the versions I’ve read closely) will prove generally workable. Among other problems, every protected resource would need to be served with a Vary: Origin header, which is problematic for a number of reasons, including legacy IE bugs (http://blogs.msdn.com/ieinternals/archive/ 2009/06/17/9769915.aspx). --------------- Feedback from others --------------- ASP.NET Controls Apparently, ASP.NET controls are tightly bound to use of JavaScript: protocol URIs, and this isn’t likely to be easily changed. For that reason, it might be interesting to have a way to allow only those URIs and not inline script blocks, event handlers, etc? --------------- That’s all I’ve got for now. Thanks for your great work here! Eric Lawrence Program Manager - IE Security _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
