OWASP
New CSP Requirement
I suggest we have a CSP requirement that moves folks away from allow-lists to a nonce or hash strict-dynamic policy (CSP3 stuff) which is much easier to deploy and more secure.
I would also recommend CSP3 with nonces, but I would not require it. For some applications a CSP with allow-lists works fine and provides adequate security. I would not require these applications to move to CSP with nonces.
Seemed to be support for CSP staying as Level 1 in #1297 so I closed that but I think we still need to decide how we want it to read in 5.0. Currently it looks like this:
[MODIFIED] Verify that a Content Security Policy (CSP) response header is in place that helps mitigate impact for XSS attacks like HTML, DOM, CSS, JSON, and JavaScript injection vulnerabilities.
@jmanico or @Sjord could you make any sensible or more prescriptive modifications here?
Problem 1: Content-Security-Policy also is defense against ClickJacking or User Interface Redress in general. At the moment it's covered with separate requirement (14.4.7), but hopefully soon we can get rid of X-Frame-Options part as IE is almost not used already.
Problem 2: maybe we should set the focus of the wording from "mitigating XSS" to "loading and communicating only with allow-listed resources". Or we can ask "fetch, document, navigation and reporting directives are all set" / for loading and communicating only allow-listed resources / for mitigating XSS attacks
Ok, to me Content Security policy is a well known enough control that we don't need to see what it protects against but rather be more prescriptive about how it should be considered which is what I am looking for suggestions for :)
We could also split into multiple requirements for L1, L2 and L3
I totally agree with @Sjord comment: here.
IMO the end solution should be minimum set of CSP rules that should be applied at each level eg. not allowing script-src=unsafe-inline from L2 etc.
In order not to make it too verbose it can be based on CSP tools (like Google CSP Evaluator or CSP Auditor - Burp Suite Extension) and not allow for High severity finding from L2 and Medium severity finding from L3
If we want say in details what CSP should do, we need entire paragraph of requirements for that.
Using nonces are better and more flexible, but at the same time - I would not say we should block using allow-list method, it does not provide less security. Also, the context - from "XSS" perspective, this requirement is a 2nd layer of defense.
What the requirement should say is that the header must be present for every rendered HTTP responses, including error messages from the webserver.
I also agree with @tw2as here and @Sjord here but I also agree that the requirement cannot be too long.
Can someone come up with a proposed wording or split for the levels?
This should be also considered in #1230
to be honest, I would like it to be slightly more prescriptive but I don't want to have to define the text myself :)
Do we talk about new CSP Requirement like the issue title says or we talk about updating current requirement?
With current requirement I would use my previous proposal as input: Or we can ask "fetch, document, navigation and reporting directives are all set" / for loading and communicating only allow-listed resources / for mitigating XSS attacks.
allow-lists are not at all recommended for CSP policies. Nonce based policies are way more secure.
https://research.google/pubs/pub45542/ https://www.researchgate.net/publication/313452289_Adopting_Strict_Content_Security_Policy_for_XSS_Protection
I would recommend the following:
For the CSP section description:
Any new web project should have a CSP implemented at the beginning of the project and initially be set very strictly. Then during the implementation it might be loosen up depending on the specific needs and accepted risks in the project.
For legacy applications CSP implementation should start with using Content-Security-Policy-Report-Only with report-uri (over https) in order to report CSP violations.
The initial CSP can start with:
default-src 'self';
script-src 'self' 'unsafe-inline';
style-src 'self' 'unsafe-inline';
img-src 'self' data:;
font-src 'self';
form-action 'self';
frame-ancestors 'self';
base-uri 'self';
object-src 'self';
Please note:
- 'unsafe-inline' should be removed if possible
- any of 'self' should be replaced with 'none' if possible
It's highly recommended to use CSP validator (like csp-evaluator.withgoogle.com) to verify the strength of the CSP rules.
The actual ASVS requirements:
From Level 1: CSP should be implemented without 'unsafe-eval', should be checked with CSP validators and be as strict as possible.
From Level 2: CSP should be implemented without 'unsafe-inline' in script-src
From Level 3: CSP should be checked with CSP validators and have no Red / High severity findings. Every finding should be and addressed and secured in some other way.
I really like this idea @tw2as.
For your L1 control, is "should be checked with CSP validators and be as strict as possible." practical/testable?
For me it's wrong direction. This requirements does not describe any rules other than "it should exist".
What is "valid" validator? What is "as strict as possible"? The requirement does not describe, what must be achieved.
In "initial CSP" - why not object-src with none, base-uri with none etc? My point is, we can not say any starter CSP as every application is different.
Basically we just need to sent the message, at via browser, (in HTML or JavaScript; injection or execution situation - it should not be possible to do any communication for loading resources or send requests which are not valid based on application needs.
@elarlang - I get your point that initial CSP wouldn't work for some projects. How about the following CSP section description?
Any new web project should have a CSP implemented at the beginning of the project and initially be set very strictly by disabling every CSP directive by setting it's value to 'none'. Then during the implementation it might be loosen up depending on the specific needs and accepted risks in the project.
For legacy applications CSP implementation should start with using Content-Security-Policy-Report-Only with report-uri (over https) in order to report CSP violations.
It's highly recommended to use CSP validator (like csp-evaluator.withgoogle.com) to verify the strength of the CSP rules.
@tghosth - I get your porint that some of those requirements are not testable. If we can to base the requirements on external CSP validator (which I believe is updated more often then the ASVS itself) then I would base it on https://csp-evaluator.withgoogle.com.
Ideally I would prefer to force no high severity findings from L2 and no medium severity findings from L3 but I guess for some projects (especially legacy) it could be to difficult to achieve therefore I propose the following:
From Level 1: Verify that a Content Security Policy (CSP) response header is in place which helps mitigate impact for XSS attacks like HTML, DOM, JSON, and JavaScript injection vulnerabilities and that it does not have 'unsafe-eval' value. From Level 2: Verify that a Content Security Policy (CSP) response header does not have 'unsafe-inline' value in 'script-src' directive. From Level 3: Verify Content Security Policy (CSP) response header value with CSP validator (https://csp-evaluator.withgoogle.com/) to make sure that it does not have any High severity findings.
Strongly disagree to suggest whitelist policies like this. Nonce & strict-dynamic policies are much much stronger.--Jim @.*** Coding Education+1 (808) 652-3805On Jan 5, 2023, at 12:56 PM, Tomasz Wrobel @.***> wrote: @elarlang - I get your point that initial CSP wouldn't work for some projects. How about the following CSP section description?
Any new web project should have a CSP implemented at the beginning of the project and initially be set very strictly by disabling every CSP directive by setting it's value to 'none'. Then during the implementation it might be loosen up depending on the specific needs and accepted risks in the project. For legacy applications CSP implementation should start with using Content-Security-Policy-Report-Only with report-uri (over https) in order to report CSP violations. It's highly recommended to use CSP validator (like csp-evaluator.withgoogle.com) to verify the strength of the CSP rules.
@tghosth - I get your porint that some of those requirements are not testable. If we can to base the requirements on external CSP validator (which I believe is updated more often then the ASVS itself) then I would base it on https://csp-evaluator.withgoogle.com. Ideally I would prefer to force no high severity findings from L2 and no medium severity findings from L3 but I guess for some projects (especially legacy) it could be to difficult to achieve therefore I propose the following:
From Level 1: Verify that a Content Security Policy (CSP) response header is in place which helps mitigate impact for XSS attacks like HTML, DOM, JSON, and JavaScript injection vulnerabilities and that it does not have 'unsafe-eval' value. From Level 2: Verify that a Content Security Policy (CSP) response header does not have 'unsafe-inline' value in 'script-src' directive. From Level 3: Verify Content Security Policy (CSP) response header value with CSP validator (https://csp-evaluator.withgoogle.com/) to make sure that it does not have any High severity findings.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>
@elarlang I think that @tw2as is on the right track as long as the suggestions are testable/verifable.
@tw2as Jim's original request was to focus around a "nonce or hash strict-dynamic" type policy but it looks like that is not specified by your requirements, are you able to clarify that in your suggested text?
From @jmanico
Strongly disagree to suggest whitelist policies like this. Nonce & strict-dynamic policies are much much stronger.
Jim, fight mode on and not reading? :)
Where exactly in my comment (https://github.com/OWASP/ASVS/issues/1311#issuecomment-1372370316) I say anything about whitelist?
Basically we just need to send the message, at via browser, (in HTML or JavaScript; injection or execution situation - it should not be possible to do any communication for loading resources or send requests which are not valid based on application needs.
In fact, I don't. It's achievable using allow-lists, it's achievable using nonces. And like we have discussed here before - nonce and strict-dynamic is not something we can force to be used over allow-list approach. Application is not more vulnerable when it uses allow-listed sources correctly.
With nonces I think you may have problems when you try to cache static content, as nonce itself is not static and cacheable.
I still stand for my previously linked comment and we should not say anything about script-src in CSP, because this is "hidden client-side architecture requirement in CSP"
If we want to force script-src or unsafe-eval or whatever similar to (not) being used, we should declare them as separate requirements and CSP is just "block the functionality if it's not done correctly or an attack (attempt) happened".
From @tw2as
For the CSP section description:
Any new web project should have a CSP implemented at the beginning of the project and initially be set very strictly. Then during the implementation it might be loosen up depending on the specific needs and accepted risks in the project.
For legacy applications CSP implementation should start with using Content-Security-Policy-Report-Only with report-uri (over https) in order to report CSP violations.
I agree with all the content, but I'm not sure, it's a content for the ASVS. Feels more like Cheat Sheet content for me.
From Level 3: Verify Content Security Policy (CSP) response header value with CSP validator (https://csp-evaluator.withgoogle.com/) to make sure that it does not have any High severity findings.
I don't like dependency on external tools, as we don't know what those will do in the future. In a way it's against ASVS versioning - let's say application A was valid against CSP rule on date X, then it was retested again on date Y and it was not valid anymore. In ASVS it could be breaking change. If someone has idea to link requirement text to some tool, then we actually need to point clearly, what we need to achieve (with this tool and without mentioning this tool).
@tghosth - it's testable as it requires verification of the CSP response header. @jmanico - it's a good point to include Nonce although it's important that it's generated every time and it's generated with crypto secure generator.
I understand the point that we don't want to include external tools (I guess it more suitable for Cheat Sheet). I propose the following:
- From Level 1: Verify that a Content Security Policy (CSP) response header is in place which helps mitigate impact for XSS attacks like HTML, DOM, JSON, and JavaScript injection vulnerabilities and it does not contain 'unsafe-eval' value.
- From Level 2: Verify that a Content Security Policy (CSP) response header does not contain 'unsafe-inline' value in 'script-src' directive or if it contains 'unsafe-inline' it also must contain a 'nonce' value (which makes 'unsafe-inline' only work with older browsers for compatibility)
- From Level 2: If Content Security Policy (CSP) response header contains a 'nonce' value, verify that it was generated on every load with a cryptographically secure pseudo-random number generator (CSPRNG).
I am not sure if forcing strict-dynamic over allow-list is nesesery. @jmanico if you think so that it's a case of adding the following:
- Verify that a Content Security Policy (CSP) response header contains 'strict-dynamic' value if it loads scripts from external domains.
Application is not more vulnerable when it uses allow-listed sources correctly.
94% of whitelist policies are bypassable. They are much less secure. I can point out the research if it helps. It is much more difficult to build a secure CSP allow-list policy than it is to build a nonce based one.
@jmanico - it's a good point to include Nonce although it's important that it's generated every time and it's generated with crypto secure generator.
Agreed. If you need that level of scale also consider csp hashing based policies which even work with CDN's and are static policies unlike nonces!
I agree that loading scripts with nonce is more secure then allow list but I am not sure if ASVS should force it and force 'strict-dynamic'. Maybe it should be recommended in the cheat series instead.
I do agree it's a slippery slope trying to make suggestions for CSP requirements....
Yes it is, but I still believe that together we can come up with some general minimum CSP requirements in ASVS
I feel that we are on loop here already, but I try to explain it once more.
We can say in CSP only, that browser should not load any other resource etc than application needs.
If we are going to disallow <script>javascript here</script> tag from HTML via CSP, it's an hidden requirement and forces to change building HTML and JavaScript part differently (not using any inline script tags). I don't say it's wrong thing to ask, I say, it's wrong place to ask it. Especially when it's forced via external tool and in ASVS requirement you don't have basically any hint on this.
Another things with CSP - rules are usually per application, but requirements are really different per page or URL. If we want to address something, then with level 3 we can keep this in mind. It's done that way for requirement 14.4.7.
@elarlang based on what you are saying in https://github.com/OWASP/ASVS/issues/1311#issuecomment-1377853036, do you have a suggestion of how you would reword the suggestion from @tw2as: https://github.com/OWASP/ASVS/issues/1311#issuecomment-1375350144
I would suggest we raise the current L1 requirement to be L2 and move towards something more prescriptive for L3 such as:
Verify that a strict nonce or hash based Content Security Policy (CSP) response header is in place to provide increased simplicity and security.
We should then make sure we have a link to the CSP cheat sheet.
https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html
If no one has objections, I will open a PR next