 |
Newsgroups: mozilla.dev.security
From: Sid Stamm <s...@mozilla.com>
Date: Tue, 07 Jul 2009 11:18:38 -0700
Local: Tues, Jul 7 2009 2:18 pm
Subject: Re: Content Security Policy Spec questions and feedback
Hi Eric,
I've addressed many of your (excellent) comments in the Spec. Thanks On 7/5/09 5:28 PM, EricLaw wrote: > --------------- Under Discussion. > 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 > --------------- Removed this confusing point from spec. (Refined spec to say: Images > 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? loaded from stylesheets should be subject to "img-src", external stylesheet loads are subject to style-src, and inline styles are allowed.) > frame-ancestors Yes, updated spec. > 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. Done. > I like this directive, but it s worth noting that this is the only I believe the original goal for this directive was to help prevent > directive which constrains how others can host the protected- > document. More on this later (see Scope Creep below). clickjacking. > --------------- I believe we have plans to register the header, and when we do, we'll > CSP Declarations > --------------- > HTTP: Header Name absolutely drop the X-. > HTTP Header: Final Under Discussion. > 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 personally want to eradicate the META tag > I like the restriction that META must appear within the HEAD, although > technically HTML5 has no such restriction. (http://blog.sidstamm.com/2009/06/csp-with-or-without-meta.html). This should be discussed more in depth to decide if we should remove META support, if we should support multiple HTTP headers, etc. > Are relative URIs valid for the report-URI/policy-URI? (Seems like Spec updated to support relative URIs. I don't think CSP should > 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? interact with the BASE tag at all. > The spec needs to specifically define what happens if a META tag is Done. > found in violation of the rules (e.g. It MUST be ignored, and a > CONSOLE ERR must be raised) > CSP-Tagging Under discussion. > 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 > --------------- Under Discussion. > Policies and Wildcarding > --------------- > Wildcarding: Multiple Labels > The how many labels can * represent problem has come up in a number > Wildcarding: Zero Labels Done. Wildcard matches zero or more labels. In a semantic sense, the > 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 . wildcard token can be considered "*.", and may be replaced by any number (>= 0) of DNS labels x[i], each followed by a dot, and concatenated as "x[0].x[1]. ...x[i]." > Wildcarding: Port& Scheme Done. Also added detailed descriptions of port/scheme wildcarding. > 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 Done. > access to banned ports http://www.mozilla.org/projects/netlib/PortBanning.html. > Scheme wildcarding is somewhat dangerous. Should the spec define Under Discussion. > what happens for use of schemes that do not define origin > information? (javascript: and data: are listed, but there are > others). > Sample Policy definitions Updated spec to allow "https://self:443" syntax. Self flexible and may > The example: > X-Content-Security-Policy: allow https://self > Doesn t make sense to me, because self is defined to include the or may not include scheme and port. When absent from the expression, scheme or port are inherited. > --------------- Yes and Yes. Will add such an example. > Reporting issues > --------------- > Violation Report: Headers > This seems like a potentially significant source of security risk and It is. We should discuss this. > 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 Removed the requirement to send "request-headers" from the XML schema > schemes (specifically, FTP and FILE) do not use headers. (implied optional). > Data Leak Vectors Done. > 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 Done. > 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 Done. > 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 Fixed spec: "HTTP POST is used if available in the employed scheme, > POST. otherwise an appropriate 'submit' method is used." > Violation Report: No redirects We should indeed anticipate this complaint, but I think it should be > 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. tabled for now. > Parse Errors: Server detection I don't think we need to address this (as per Gerv's comment on this). > 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 We should discuss the use of a UI indicator or something similar, though > 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. in the case of policy violations (that get repaired due to reporting), the failure should be short-lived enough so it won't warrant downgrading. > --------------- Agreed. Added comment to spec. > Misc > --------------- > User-Scripts > Broken link Fixed. > 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]] > --------------- Under Discussion. > Logical evolutions aka Scope Creep > --------------- > Scope Creep: exempt HEAD > Scope Creep: Prevent Sniffing& Unintended Reuse Under Discussion. > 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 > Scope Creep: Same Origin Only Under Discussion. > 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- > (A competing idea is to respect Access-Control-Allow-Origin response > This allows for a useful CSRF/bandwidth misuse protection at little > I m not fully convinced that the Origin proposal (or at least the Under Discussion. > 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? > --------------- -Sid > That s all I ve got for now. Thanks for your great work here! > Eric Lawrence 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.
| |||||||||||||