Account confirmers, Anti-spam team, Confirmed users, Bureaucrats and Sysops emeriti
4,925
edits
Talk:Security/CSP/Spec: Difference between revisions
no edit summary
No edit summary |
|||
| (39 intermediate revisions by 3 users not shown) | |||
| Line 3: | Line 3: | ||
We've been discussing CSP in lots of places, mainly in the [http://groups.google.com/group/mozilla.dev.security mozilla.dev.security] newsgroup. This is a great spot to discuss details of the CSP Spec, though. I've split this page into topics and am marking each issue as either open or closed depending on whether we have made decisions to resolve it or not. -[[User:Sidstamm|Sid]] | We've been discussing CSP in lots of places, mainly in the [http://groups.google.com/group/mozilla.dev.security mozilla.dev.security] newsgroup. This is a great spot to discuss details of the CSP Spec, though. I've split this page into topics and am marking each issue as either open or closed depending on whether we have made decisions to resolve it or not. -[[User:Sidstamm|Sid]] | ||
== Version Beacon (<span style="color: | == User Script interaction (<span style="color:green;">OPEN</span>)== | ||
It seems like the spec should indicate how CSP interacts with user scripts (e.g. greasemonkey). --[[User:Sacolcor|Sacolcor]] | |||
Well, it should not affect them at all. Question is, is that technically possible? -- [[User:Gerv|Gerv]] | |||
== restrict TYPES for "object-src" (<span style="color:green;">OPEN</span>)== | |||
Shouldn't "object-src" allow restrictions on what TYPES of objects are allowed, rather than just which hosts are allowed? -EricLaw | |||
This sounds to me like over-complication. What's the use case? -- [[User:Gerv|Gerv]] | |||
I don't think its an over complication. The object-type directive could be optional. If it is specified then allow that type only, if its not present then all object types are allowed. On the flipside, if you argue for TYPE in objects, why not TYPE in images ? What is it about objects that demand a special object-type directive ? | |||
A simple use case would be a enterprise app that has distributed a plugin to all its users to embed a proprietary format object. But for sake of security it doesn't want any flash or java in that page. --duryodhan | |||
== <tt>form-action</tt> Directive? (<span style="color:green;">OPEN</span>) == | |||
Should we add a <tt>form-action</tt> directive? Password theft can be accomplished if an attacker can inject an HTML form into a site. Password managers will even play along with this sometimes, even though the form action may target an attacker's site, and not ''self''. -[[User:Sidstamm|Sid]] | |||
When you submit a form, thats a new web request, so isn't this already covered by the allow directive? In such a case, is there a use case for adding a specific <tt>form-src</tt> directive ? --duryodhan | |||
Forms were not covered by the "allow" directive since there's user interaction required to submit the form; this is the same reason links to external sites aren't stopped by CSP. Any requests caused automatically by the page's load (dependent load requests) are subject to CSP, but if the user wishes to navigate away from the page, they're allowed. | |||
-[[User:Sidstamm|Sid]] | |||
Ok. Thats a very nice clear cut view -'anything without user interactions has CSP applied to it, without doesn't'. I am stupid and I didn't understand this from the spec - maybe you can add that somewhere appropriate ? | |||
Additionally, in this scenario, while I do understand where you are coming from - there is a difference between links and forms. In links more often than not, you(user) know where you are going to. In forms unfortunately there is no indication in current UI of where the form data is going. So although there is user interaction in a form submission, whether user intent is there or not, is not clear. As such, I think forms should be covered by allow directive. If not, then a form-src also makes sense. --duryodhan | |||
Assume form actions are subject to the <tt> allow</tt> directive as you recommend. If a site wants to allow form submissions to arbitrary third party sites (such as search boxes with arbitrary targets), then they have to open up the allow directive to be something like <tt>allow *</tt>. This is not safe, especially if the site authors don't want ActiveX controls or Scripts loaded from third party sites. As a result, the site authors have to then use the rest of the directives as ''blacklists'' instead of whitelists, making the policy a bit more confusing. If there's a <tt>form-action</tt> directive, then only one additional directive is needed aside from <tt>allow self</tt> to get a fairly closed-down policy that allows form submissions to arbitrary sites. | |||
So either we need a directive to control form actions, or we shouldn't subject the form actions to CSP at all like anchor-based links (not even the allow directive). | |||
Also, <tt>form-action</tt> is not part of the spec yet... but the more it is discussed, the more I'm starting to think it's useful. | |||
-[[User:Sidstamm|Sid]] | |||
I agree :). In addition, in the spec could you please clarify that the CSP is only applied to automatic HTTP requests and not those caused by User interaction (as I noted before)? I honestly thought that it applies to all HTTP requests. | |||
--duryodhan | |||
== Version Beacon (<span style="color:red;">CLOSED</span>)== | |||
Is more misuse of the user-agent header the best way to go, or does | Is more misuse of the user-agent header the best way to go, or does | ||
| Line 14: | Line 53: | ||
The alternative to the request announcing the support level is to version the reponse, and for the client to ignore policies with an unknown (newer) version. Combine that with server UA version sniffing if the server needs to decide which version of a policy to send. Or if we allow multiple CSP headers and intersect them (discussed elsewhere) then a server could simply send multiple versions which either get intersected into something sane in newer browsers or fall back to the older CSP header in older browsers. -dveditz | The alternative to the request announcing the support level is to version the reponse, and for the client to ignore policies with an unknown (newer) version. Combine that with server UA version sniffing if the server needs to decide which version of a policy to send. Or if we allow multiple CSP headers and intersect them (discussed elsewhere) then a server could simply send multiple versions which either get intersected into something sane in newer browsers or fall back to the older CSP header in older browsers. -dveditz | ||
I perceive general distaste for version strings in the UA header, so I am going to modify the spec to be forward-compatible: (1) unknown directives are not fatal -- they are just ignored (2) future versions can implement directives with arbitrary values, but directives in the first version of CSP are restricted to their existing syntax. | |||
Resolution: updated ABNF to allow future directives with arbitrary syntax. | |||
-[[User:Sidstamm|Sid]] | |||
== Script Languages (<span style="color:red;">CLOSED</span>)== | == Script Languages (<span style="color:red;">CLOSED</span>)== | ||
| Line 65: | Line 109: | ||
-[[User:Sidstamm|Sid]] | -[[User:Sidstamm|Sid]] | ||
== origin/host/source terminology (<span style="color: | == origin/host/source terminology (<span style="color:red;">CLOSED</span>)== | ||
Rather than using the term "host" and "source" would it be more accurate to replace all instances with "HTML5 Origin"? This term has a defined meaning and would remove ambiguity in cases (like report-uri) which are currently defined as both "same host" and "same source". -EricLaw | Rather than using the term "host" and "source" would it be more accurate to replace all instances with "HTML5 Origin"? This term has a defined meaning and would remove ambiguity in cases (like report-uri) which are currently defined as both "same host" and "same source". -EricLaw | ||
| Line 73: | Line 117: | ||
PublicSuffix+1 is a bad compromise. If we assume the author means exactly and only the host they specify then the policy is clear (no hidden meanings) and can be restrictive if necessary. If the author wants your behavior they can add a wildcard, which also has an explicitly clear meaning. -dveditz | PublicSuffix+1 is a bad compromise. If we assume the author means exactly and only the host they specify then the policy is clear (no hidden meanings) and can be restrictive if necessary. If the author wants your behavior they can add a wildcard, which also has an explicitly clear meaning. -dveditz | ||
== What does 'self' represent? (<span style="color: | Gerv and I were talking about different things. He was not talking about treating all origin/host/source directives as applying to an entire subdomain but rather specifically about allowing the reportURI (and policyURI?) be anywhere on the "same domain" rather than strictly "same origin". I'm ok with publicSuffix+1 for the reportURI but uncomfortable with going beyond same-origin for the policyURI. But having the two directives have different restrictions is confusing. I'm open to arguments that looser restrictions on the policyURI is OK (or that we don't need the policyURI at all -- it complicates a lot of things) -dveditz | ||
Resolution: Requiring "same origin" for policyURI (scheme/host/port), and Public Suffix +1 for reportURI. --[[User:Sidstamm|Sid]] | |||
== What does 'self' represent? (<span style="color:red;">CLOSED</span>)== | |||
"self" is defined as the scheme/host/port (origin) in the prose, but the flowchart defines it as document.domain. Which is it? -EricLaw | "self" is defined as the scheme/host/port (origin) in the prose, but the flowchart defines it as document.domain. Which is it? -EricLaw | ||
| Line 86: | Line 134: | ||
Would it be difficult to implement an intelligent "self" that was the same as the current URL for all unspecified bits? So it just Did The Right Thing? -- [[User:Gerv|Gerv]] | Would it be difficult to implement an intelligent "self" that was the same as the current URL for all unspecified bits? So it just Did The Right Thing? -- [[User:Gerv|Gerv]] | ||
Not difficult, but ambiguous, and it's not much more difficult to actually type the host name (it ''is'' available in the HTTP request).<br/> | |||
Resolved: self will always represent (scheme, host, port) of the protected document. | |||
--[[User:Sidstamm|Sid]] | |||
== Scheme wildcards (<span style="color:red;">CLOSED</span>)== | == Scheme wildcards (<span style="color:red;">CLOSED</span>)== | ||
| Line 103: | Line 155: | ||
-[[User:Sidstamm|Sid]] | -[[User:Sidstamm|Sid]] | ||
== Report XML mime type (<span style="color: | == Report XML mime type (<span style="color:red;">CLOSED</span>)== | ||
What MIME-type is used when sending the Report XML? -EricLaw | What MIME-type is used when sending the Report XML? -EricLaw | ||
Any objections to application/xml? -- [[User:Gerv|Gerv]] | Any objections to application/xml? -- [[User:Gerv|Gerv]] | ||
Sounds good. -[[User:Sidstamm|Sid]] | |||
== "Final" Directive to ignore META tags (<span style="color:red;">CLOSED</span>)== | == "Final" Directive to ignore META tags (<span style="color:red;">CLOSED</span>)== | ||
| Line 115: | Line 169: | ||
Closed as long as META is dead. -- [[User:Gerv|Gerv]] | Closed as long as META is dead. -- [[User:Gerv|Gerv]] | ||
== | == "font-src" and "xhr-src" directives (<span style="color:red;">CLOSED</span>)== | ||
Should there be a "font-src" restriction? -EricLaw | |||
Good question. Right now fonts are subject to the "allow" catch-all directive, and loading third-party fonts requires loosening that restriction. Perhaps we should discuss adding such a directive as well as an xhr-source directive (for when cross-site xhr explodes). -[[User:Sidstamm|Sid]] | |||
I think we should do this, since fonts are a whole new beast. Marking this as closed; reopen if there's an objection. I'm also adding an XHR-src. | |||
-[[User:Sidstamm|Sid]] | |||
== Distinguishing Keywords (<span style="color:red;">CLOSED</span>)== | |||
Should we distinguish keywords such as "inline", "self" etc. when they are in a hostname slot? I discussed possibilities with Sid, and we thought that single quotes might work well; <tt>script-src: 'self'</tt>. Other options are CAPS, or a $prefix %character. What do people think? -- [[User:Gerv|Gerv]] | |||
Using single quotes for 'none', 'inline', etc. -[[User:Sidstamm|Sid]] | |||
== Option (not source) Keywords (<span style="color:red;">CLOSED</span>) == | |||
Should we move the keywords 'inline' and 'eval' out of the script-src directive? ''YES'' | |||
Where should we put them? | |||
# In the allow directive (<tt>allow self eval-script inline-script</tt>) | |||
# In their own directive (<tt>allow self; options eval-script inline-script</tt>) | |||
# As their own directives (<tt>allow self; eval-script; inline-script</tt>) | |||
I'd prefer the "options" directive technique. Any thoughts? -[[User:Sidstamm|Sid]] | |||
I added an "options" directive to the spec. Feedback please! | |||
-[[User:Sidstamm|Sid]] | |||
Resolution: using the "options" directive. See the spec. | |||
--[[User:Sidstamm|Sid]] | |||
== <tt>frame-src</tt> Consistent Across Navigation (<span style="color:red;">CLOSED</span>) == | |||
The frame-src restriction does not appear to take navigation into account. Suppose example.com has a refresh.php that serves a page with a Meta Refresh (e.g., like http://www.wizards.com/leaving.asp?url=http://www.adambarth.com/ but | |||
that proceeds automatically after a moment) and uses the following CSP policy: | |||
X-Content-Security-Policy: allow self | |||
Now, the attacker can subvert the frame-src policy by injecting the | |||
following HTML: | |||
<iframe src="http://example.com/refresh.php?url=http://attacker.com/"></iframe> | |||
The frame-src check will pass because the URL comes from example.com, | |||
but the frame will be loaded from attacker.com, circumventing the | |||
policy. We recommend that every change to a frame's src be validated | |||
against the frame-src whitelist. | |||
-- (reposted by [[User:Sidstamm|Sid]] for abarth) | |||
Not subjecting inner-frame navigation to the outer frame's CSP seems to force an inconsistent state, but doesn't seem fatal. Personally, I think it might be good to force the frame to ''eternally'' follow the CSP <tt>frame-src</tt> policy, but it doesn't feel like an urgent need to me. | |||
-- [[User:Sidstamm|Sid]] | |||
What type of XSS attacks would 'eternally' follow protect against? --duryodhan | |||
First example (a somewhat contrived example though) that comes to mind is the redirect example above, followed by a redirect back to a resource on example.com that has an XSS hole and no CSP set, perhaps because it's usually a top level page (<tt>http://example.com/failmessage.php?text=xss_outer_frame()</tt>). The inner frame is then same origin as the outer frame, but has some script reflected into it from the attacker's site. It can then access the outer frame and fool with it. | |||
I dunno, like I said before, I'm not convinced ''eternal'' enforcement of frame-src is necessary, but this scenario might happen. | |||
-[[User:Sidstamm|Sid]] | |||
Yeah but if example.com has a flawed page and no CSP set, it can be hacked from another page also. The CSP enabled example.com's page would just end up saying that from this page you can't attack, which I don't think is worth is, because with an 'eternal' frame-src directive you are making life very hard for ads (think syndication). (afaik, imho) the attacks that happen with a malicious iframe are : the new redirect goes to a phishing page which looks like example.com and as the top URL bar also has example.com, the user is fooled into typing in his personal data. But this attack isn't XSS and shouldn't be handled by CSP I think. CSP should stick to protecting a web application from XSS --duryodhan | |||
I agree CSP shouldn't address phishing, and we don't intend to do that. The situation I was trying to describe is the "hacked page" that ends up in a subframe of a sensitive page. The error page in the situation above, when victimized by XSS, may not be a huge risk -- when it's enframed by a more sensitive part of the site (say a page with account data displayed) the XSS can be used to extract more sensitive data. | |||
-[[User:Sidstamm|Sid]] | |||
Once you XSS any page, can't you just XHR the a/c data page and get the data? Or you are saying that the A/C data page would have required the user to reenter his password ? I just think this case then becomes too contrived/obscure for CSP to take care off -- any such really sensitive page just shouldn't have a iframe from other page imho. --duryodhan | |||
I'm going to close this. I'll try to make it more clear in the spec that this is the case with frame-src (it is not eternally enforced), but I think a happy compromise enforces the frame-src policy on HTTP redirects (30x) while missing refreshes/js redirects. | |||
Resolution: Not changed. frame-src is enforced for HTTP redirects (30x). | |||
-[[User:Sidstamm|Sid]] | |||
== video and audio src (<span style="color:red;">CLOSED</span>) == | |||
shouldn't there be a video-src and audio-src for the <video> and <audio> tags? Reasons for inclusion being the same as that for img-src. I am a little worried that there might be way too many <elementname>-src in the spec. --duryodhan | |||
That's what <tt>media-src</tt> is intended for: video and audio. | |||
-[[User:Sidstamm|Sid]] | |||
I ''am'' an idiot. Sorry about that! But, Why is there a separate img-src ? Why isn't it covered in media-src ? (too many *-src tags still worries me :) --duryodhan | |||
Embedded audio and video are relatively new compared to images on web pages and when rendered on a page these media are displayed with controls. Images by contrast can be backgrounds, and touch a completely different part of the code. In fact, it's completely reasonable to think that a site that wants to use images will want to prohibit videos from showing up -- especially since video codecs are newer and more prone to security-sensitive crash bugs than image codecs. | |||
-[[User:Sidstamm|Sid]] | |||
==javascript: URIs by user (<span style="color:red;">CLOSED</span>)== | |||
If javascript: URIs are disabled by the site, and the user wants to execute some bookmarklet , it would still work ? I am pretty sure that the answer is yes, but just wanted to confirm. --duryodhan | |||
See [[Talk:Security/CSP/Spec#User_Script_interaction_.28OPEN.29|User Script Interaction]]. I think bookmarklets should fall under this umbrella, but not sure if they really do in implementations. | |||
-[[User:Sidstamm|Sid]] | |||
I am not sure either :). But I think as a spec, the document should think about these corner cases and clearly write out the expected behaviour. --duryodhan | |||
Let me clarify -- I'm not sure if bookmarklets are deployed as user scripts or content scripts in various pieces of software (browsers). I haven't checked how different browsers behave. It '''is''' clear that user-provided scripts should not break (as per the CSP spec). I'm pretty sure "user provided" would include bookmarklets, since they're initiated by the user. I'll add the word "bookmarklets" to the spec to make this more explicit. | |||
-[[User:Sidstamm|Sid]] | |||