CSP - Ambiguities in allow directive
While reading through https://wiki.mozilla.org/Security/CSP/Spec , I noticed some ambiguities for handling allow 'none'. *1) Is allow optional or required?* The allow specification (https://wiki.mozilla.org/Security/CSP/Spec#allow) indicates that allow is an optional field. Quoting that section: If the allow directive is not explicitly specified, no content from any source will be loaded. This is equivalent to the policy allow 'none'. However, earlier on that page ( https://wiki.mozilla.org/Security/CSP/Spec#Policy_Language_and_Syntax) there's the following: A policy is composed of directives with their corresponding values. Any number of directives can be defined, but the *allow directive must always be present*. In addition, the formal policy syntax seems to require an allow field. policy::= allow-directive;directive-list allow-directive ::= allow source-list source-list ::= source | source-list source source::= 'self' | schemehostport Suggestion: The documentation should be updated to indicate that allow is a required field. *2) Is allow 'none' allowed?* Throughout the CSP documentation, there are references to allow 'none', for example: A policy is composed of directives, such as allow none. Each directive is composed ... or ... raise a CSP console error and enforce the most restrictive (allow none) policy. or If the allow directive is not explicitly specified, no content from any source will be loaded. This is equivalent to the policy allow 'none'. etc... However, the formal policy syntax does not seem to allow allow 'none'. policy::= allow-directive;directive-list allow-directive ::= allow source-list source-list ::= source | source-list source source::= 'self' | schemehostport Suggestion: The formal policy syntax should be updated to indicate that allow 'none' is allowed. Thanks, -- Nick ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Why is it an error to have both X-Content-Security-Policy and X-Content-Security-Policy-Report-Only ?
https://wiki.mozilla.org/Security/CSP/Spec#Report-Only_mode If both a X-Content-Security-Policy-Report-Only header and a X-Content-Security-Policy header are present in the same response, a warning is posted to the user agent's error console and any policy specified in X-Content-Security-Policy-Report-Only is ignored. The policy specified in X-Content-Security-Policy headers is enforced. Why is this? This seems like an unnecessary burden which prevents groups from tightening their security policies over time. For example, here at Google, I'm interested in helping resolve some of our Mixed Content warnings, so I might run the following header on all Google HTTPS sites: X-Content-Security-Policy-Report-Only: allow https://*:443; options inline_script eval-script; report-uri /someUri This will allow me to collect information on all the mixed-content violations which may occur. However, in the future, a different group may decide that they want to enforce a tighter policy, and may add the header: X-Content-Security-Policy: [something else] All of a sudden, two reasonable changes by two different people will result in a user visible error, and will suppress my ability to collect information about mixed-content errors. To me, it seems valuable to support both X-Content-Security-Policy and X-Content-Security-Policy-Report-Only, as it allows sites to test new restrictions without disrupting their current restrictions. -- Nick ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Why is it an error to have both X-Content-Security-Policy and X-Content-Security-Policy-Report-Only ?
Hmm, that's an interesting point. I believe the concern was around potential for confusion when a mix of enforced and report-only policies was defined, so the admin wouldn't forget to flip the switch from reporting to enforcing and end up with a false sense of confidence. There are also some implementation challenges with doing both; we'd need to track two separate set of policies, one enforced and one reporting-only, but active simultaneously. The latter is a solvable problem but we already got a lot of feedback over the perceived complexity of the model. :) Nevertheless I think your use case for parallel research / testing makes a lot of sense. Lucas. On Mar 12, 2010, at 2:45 PM, Nick Kralevich wrote: https://wiki.mozilla.org/Security/CSP/Spec#Report-Only_mode If both a X-Content-Security-Policy-Report-Only header and a X-Content-Security-Policy header are present in the same response, a warning is posted to the user agent's error console and any policy specified in X-Content-Security-Policy-Report-Only is ignored. The policy specified in X-Content-Security-Policy headers is enforced. Why is this? This seems like an unnecessary burden which prevents groups from tightening their security policies over time. For example, here at Google, I'm interested in helping resolve some of our Mixed Content warnings, so I might run the following header on all Google HTTPS sites: X-Content-Security-Policy-Report-Only: allow https://*:443; options inline_script eval-script; report-uri /someUri This will allow me to collect information on all the mixed-content violations which may occur. However, in the future, a different group may decide that they want to enforce a tighter policy, and may add the header: X-Content-Security-Policy: [something else] All of a sudden, two reasonable changes by two different people will result in a user visible error, and will suppress my ability to collect information about mixed-content errors. To me, it seems valuable to support both X-Content-Security-Policy and X-Content-Security-Policy-Report-Only, as it allows sites to test new restrictions without disrupting their current restrictions. -- Nick ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Why is it an error to have both X-Content-Security-Policy and X-Content-Security-Policy-Report-Only ?
(below is my understanding of the decision) CSP tries to be robust against an attacker who is able to inject HTTP Headers. Thus the choice of intersecting multiple policies - thus an attacker can not reduce the security that a correct policy aims to provide. In report mode, there is a concern that CSP might leak sensitive data (cookies/capabilities). If both report and policy is allowed, then an attacker could reduce the security of an application by adding a (report-only) header which leaks information, which doesn't sit well with how the rest of CSP aims to work. -devdatta On 12 March 2010 15:08, Lucas Adamski lu...@mozilla.com wrote: Hmm, that's an interesting point. I believe the concern was around potential for confusion when a mix of enforced and report-only policies was defined, so the admin wouldn't forget to flip the switch from reporting to enforcing and end up with a false sense of confidence. There are also some implementation challenges with doing both; we'd need to track two separate set of policies, one enforced and one reporting-only, but active simultaneously. The latter is a solvable problem but we already got a lot of feedback over the perceived complexity of the model. :) Nevertheless I think your use case for parallel research / testing makes a lot of sense. Lucas. On Mar 12, 2010, at 2:45 PM, Nick Kralevich wrote: https://wiki.mozilla.org/Security/CSP/Spec#Report-Only_mode If both a X-Content-Security-Policy-Report-Only header and a X-Content-Security-Policy header are present in the same response, a warning is posted to the user agent's error console and any policy specified in X-Content-Security-Policy-Report-Only is ignored. The policy specified in X-Content-Security-Policy headers is enforced. Why is this? This seems like an unnecessary burden which prevents groups from tightening their security policies over time. For example, here at Google, I'm interested in helping resolve some of our Mixed Content warnings, so I might run the following header on all Google HTTPS sites: X-Content-Security-Policy-Report-Only: allow https://*:443; options inline_script eval-script; report-uri /someUri This will allow me to collect information on all the mixed-content violations which may occur. However, in the future, a different group may decide that they want to enforce a tighter policy, and may add the header: X-Content-Security-Policy: [something else] All of a sudden, two reasonable changes by two different people will result in a user visible error, and will suppress my ability to collect information about mixed-content errors. To me, it seems valuable to support both X-Content-Security-Policy and X-Content-Security-Policy-Report-Only, as it allows sites to test new restrictions without disrupting their current restrictions. -- Nick ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: CSP - Ambiguities in allow directive
Hi Nick, Thanks for the feedback! On 3/12/10 1:39 PM, Nick Kralevich wrote: *1) Is allow optional or required?* The allow specification (https://wiki.mozilla.org/Security/CSP/Spec#allow) indicates that allow is an optional field. Quoting that section: If the allow directive is not explicitly specified, no content from any source will be loaded. This is equivalent to the policy allow 'none'. However, earlier on that page ( https://wiki.mozilla.org/Security/CSP/Spec#Policy_Language_and_Syntax) there's the following: A policy is composed of directives with their corresponding values. Any number of directives can be defined, but the *allow directive must always be present*. Yes, this is unclear in the spec: reverting to allow 'none' is supposed to be a failure, and reported quietly to an error console. I'll clear it up. If the allow directive is not present, CSP fails closed. *2) Is allow 'none' allowed?* [...] Suggestion: The formal policy syntax should be updated to indicate that allow 'none' is allowed. Yes, this is a bug in the syntax. source-list should be src-dir-value. Thanks for the catch! -Sid ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Why is it an error to have both X-Content-Security-Policy and X-Content-Security-Policy-Report-Only ?
On 3/12/10 3:18 PM, Devdatta wrote: (below is my understanding of the decision) CSP tries to be robust against an attacker who is able to inject HTTP Headers. Thus the choice of intersecting multiple policies - thus an attacker can not reduce the security that a correct policy aims to provide. This is not completely true. While adding a CSP header can't loosen a policy, this is specified as such for legit uses, not for attack scenarios. CSP is intended to protect from content flaws, not a mid-stream network attacker. Attackers who can inject HTTP headers have quite a bit more power than a simple XSS vulnerability (and these attacks are probably less common). Furthermore, it's likely that an attacker who can inject a HTTP header can also change existing ones (or delete them). In report mode, there is a concern that CSP might leak sensitive data (cookies/capabilities). If both report and policy is allowed, then an attacker could reduce the security of an application by adding a (report-only) header which leaks information, which doesn't sit well with how the rest of CSP aims to work. This is actually stopped by restrictions on where reports can be sent. An attacker who injects a report-uri can't learn anything about the victims unless he controls the server where the reports are sent -- which must be on the same public suffix and base host. Having said all that, I can see the use-case of having both headers, but it does make the implementation quite a bit more complex; i.e., we potentially have to keep two policies in parallel, and subject the content to both policies. As far as I can remember, we ignore the report-only header to make things easier on whoever implements the feature. Maybe we should start talking about supporting both at the same time, and the semantics for doing so? -Sid ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
CSP : What does allow * mean?
While reading through the Formal Policy Syntax of the CSP, it occurred to me that the meaning of allow * might be confusing. The wildcard seems to correspond to a hostname only, and not to a scheme or port. source::= 'self' | schemehostport scheme::= empty | scheme-name: | scheme-name:/ | scheme-name:// scheme-name ::= alphascheme-suffix host ::= empty | host-name host-name ::= * | ldh-str | host-name.ldh-str port ::= empty | :* | :integer In the case where source is *, the above syntax would imply that scheme is empty, host is *, and port is empty. And, according to the CSP, when a scheme or port isn't specified, it defaults to the same scheme and default port of the originating resource. https://wiki.mozilla.org/Security/CSP/Spec#Source_Expression_List Source expressions may also specify a scheme and/or port. If the scheme is not specified as part of the source expression it defaults to the same scheme as the protected document. If a port is not specified as the source expression, the port used for the source is the default port for the source's scheme (whether it is inherited or explicitly specified in the source expression). However, the examples ( https://wiki.mozilla.org/Security/CSP/Spec#Sample_Policy_Definitions) paint a different picture. Example #2, in particular, says that X-Content-Security-Policy: allow 'self'; img-src *; ... will allow an image from anywhere. However, my reading of the syntax is that it will only allow images from the same scheme and default port. (for example, an HTTP page couldn't include an image from an HTTPS source) 1) Is my reading of allow * correct? 2) How does one specify a wildcard for any protocol? The syntax allow *://*:* does not seem to be allowed by the formal specification. -- Nick ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: CSP : What does allow * mean?
On 03/12/2010 04:38 PM, Nick Kralevich wrote: While reading through the Formal Policy Syntax of the CSP, it occurred to me that the meaning of allow * might be confusing. The wildcard seems to correspond to a hostname only, and not to a scheme or port. Another great question. I've made a change to the policy syntax that I hope will clarify things. source::= 'self' | * | schemehostport What this means is that * by itself implies inherited-scheme//*:* but * can still be used as a wildcard for hostname, port, or both. We didn't think it was wise to allow sites to wildcard schemes. It doesn't seem like too much to ask sites to enumerate the schemes they want to use. X-Content-Security-Policy: allow 'self'; img-src *; ... will allow an image from anywhere. However, my reading of the syntax is that it will only allow images from the same scheme and default port. (for example, an HTTP page couldn't include an image from an HTTPS source) 1) Is my reading of allow * correct? With this change to the spec, the above policy would now allow images from the same scheme, any host, and any port. 2) How does one specify a wildcard for any protocol? I don't think we should allow that. Do you have a reason to believe we should? Thanks very much for all the detailed feedback. It's very much appreciated. Cheers, Brandon ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Allow CSP on HTML meta tags
On 2/28/10 6:43 PM, Axel Dahmen wrote: Actually I still can't find a fair reason for omitting the option of allowing HTML meta tags to provide CSP directives. * By means of the intersection algorithm, a meta CSP directive can only tighten security but not loosen. * Disallowing meta tags would cause a significant number of private websites to not being able to use this security feature. Does someone really want to exclude all these users from the spec? Just because it would cause more effort implementing it? What's more important? If we knew that there really were all these users clamoring to use CSP it might be worth working through the complexities, but until we get a working version out there we won't really know what works and what doesn't in the real world. It is far, far easier to add meta support later if we need it than to remove a feature if we decide it's not working out. Not too worried about injected meta tags, we just have to make sure it can only restrict the page further (which we already have to do to support multiple HTTP headers). How do we handle a meta tag that comes after some content which a policy should have regulated? If we decide to only honor meta tags that come first then injecting such a header can disable CSP. If we enforce CSP from that point on there's still page content that avoided the policy. We could re-parse the entire page and enforce things the second time around but the injection may have been able to do its damage already. This is not an academic question, I've seen a lot of pages with malware content injected above the normal page content. Is best effort CSP enforcement good enough? Would we be fostering a false sense of security by supporting meta? effort isn't why we cut it. The policy is designed to protect the integrity of the content and it's much easier to reason about its security properties and effectiveness when it's delivered external to that content. If CSP turns out to be an effective and accepted solution (no inline scripts is pretty radical) and there's a need for meta support we can add that during the standardization process. At the moment it's hard to imagine who would benefit from it, though. Yes, I know there are a lot of people who can't change their headers, but do those people run web applications that could suffer from XSS and other attacks CSP addresses? -Dan Veditz ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
