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 |
|||
| (2 intermediate revisions by one other user 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 124: | Line 168: | ||
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>)== | == "font-src" and "xhr-src" directives (<span style="color:red;">CLOSED</span>)== | ||
| Line 143: | Line 177: | ||
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. | 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]] | -[[User:Sidstamm|Sid]] | ||
== Distinguishing Keywords (<span style="color:red;">CLOSED</span>)== | == Distinguishing Keywords (<span style="color:red;">CLOSED</span>)== | ||
| Line 172: | Line 200: | ||
--[[User:Sidstamm|Sid]] | --[[User:Sidstamm|Sid]] | ||
== <tt>frame-src</tt> Consistent Across Navigation (<span style="color:red;">CLOSED</span>) == | |||
== <tt>frame-src</tt> Consistent Across Navigation (<span style="color: | |||
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 | 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 | ||
| Line 235: | Line 240: | ||
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 | 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 | 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 | ||
| Line 247: | Line 257: | ||
-[[User:Sidstamm|Sid]] | -[[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 | 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 | ||