New CSP Requirement

[jmanico]

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.

[elarlang]

For "non-related" development there is now opened separate issue #1958.

This issue is focusing only allow-list vs nonces in Content-Security-Policy.

As discussed here, it does not make sense to require it, but we can write recommendation for that.

[jmanico]

I am sticking around. If you cannot stop being abusive, then I suggest you find somewhere else to donate your time. Being respectful is critical to a standard body and all technical comments are welcome.

I disagree Elar. I think your comments are downright abusive and it needs to stop.

This is not true, and it is pure demagogy. In another issue, you said that I didn't understand the topic, the same in the email, but at the end, you were the one, who did not read the issue (again) and failed to understand the topic. The summary is here: #1589 (comment)

Here, yes, you started the issue. The discussion here has been developing to the place, where it is.

From issue to issue you throw in comments, without reading and analyzing, what has been said before, causing noise in the issue, and then no one wants to dig through all the comments that are there.

If you think after all that behavior, that I'm the one who needs to change, then the result is quite simple - one of us will not continue as leader for ASVS.

[jmanico]

As I listed above, strict-CSP is rather complex. I am happy to convert that into a series of requirements if I have your support for this @tghosth

[ryarmst]

I think specifying the use of the Strict CSP approach may ambiguous as there are different definitions/understandings of what the requirements are. For example, Google's definition here is at odds with the definition above. Notably, (as one example) it includes the use of unsafe-inline which is ignored when nonces are supported (as such, I don't think it's necessarily appropriate to prohibit unsafe-inline as a possible source when used alongside a strict policy).

If I am understanding correctly, I agree with @elarlang's direction abstracting from the specific directives/policies.

I think an allow-list approach would be appropriate requirement for initial level(s), but for L3 I think a more strict approach may be appropriate (as @jmanico noted, there is sufficient evidence on the allow-list approach failing due to insecure implementations). Here is a rough effort at generalizing these:

1. A CSP should ensure the browser only loads/executes trusted content or content from trusted sources.
2. A CSP should ensure the browser only loads/executes trusted content.

[ryarmst]

To put these into requirement form for suggestion (not suggesting level associations, however):

1. Verify for all pages that a Content Security Policy (CSP) is implemented to ensure the browser only loads/executes explicitly trusted content or content from trusted sources.
2. Verify for all pages that a Content Security Policy (CSP) is implemented to ensure the browser only loads/executes explicitly trusted content.

I used the term page which I assume is appropriate for where this type of policy ought to be implemented. Other resources that do not embed content may use CSP differently. The 2. requirement necessarily follows the strict approach without dictating the method (nonce, hash, something else?) as it specifies that all loaded content must be trusted (not just content from trusted sources). Both 1. and 2. implicitly prevent the use of unsafe-inline which is a method that fails to explicitly trust loaded content.

[jmanico]

How about we get a little at least a little more specific. There are a limited number of ways to implement CSP.

So perhaps:

• Verify for all pages that a Content Security Policy (CSP) is implemented to ensure the browser only loads/executes explicitly trusted content or content from trusted sources using one or a combination of allow lists, CSP-nonces or CSP-hashes.
• Verify for all pages that a Content Security Policy (CSP) is implemented to ensure the browser only loads/executes explicitly trusted content using CSP-nonces and/or CSP-hashes.

[Sjord]

In my experience, using a strict CSP with either nonces or a watertight allow-list is really difficult for an existing application. Simply allow-listing the currently used domains is often not sufficiently secure, if those domains host other people's scripts or scripts that can be used as gadgets. Nonces don't work for event handlers, so in an existing application the developer has to rewrite all JavaScript event handlers. Slapping a header on an application is easy, but making an existing application work with a strict CSP is hard.

Caution AI content

I think copy/pasting AI-generated content is not helpful.

I suggest that mentioning the use of nonces or hashing with strict-dynamic (also know as “strict CSP”) is exactly what we should be suggesting.

I think the agreement thus far is to recommend this, but not require it. The quoted part is a bit ambiguous on what you think, @jmanico, so it does not really connect well to the discussion thus far. But from your last comment I gather you want to require a strict CSP, preferably with nonces or hashes. That is indeed more secure, but it is also an impossible amount of work for some existing applications. So I don't think requiring this for all applications is a good idea.

[jmanico]

There are a lot of level 3 requirements that are difficult to implement. Strict-CSP is challenging to implement in some cases, but I still think we need to push in that direction since it’s the main way, statistically, to implement CSP with good security properties.

Again, many other level 3 requirements are very difficult to implement, that’s why they are level 3.

[tghosth]

---

My thoughts on what has been written:

Instead of saying "Do not use 'unsafe-inline'" we should try to explain the goal of the restriction.

@elarlang I agree that setting out the goal of the requirement is key and ideally focusing the requirement around the goal rather than specific

• Verify for all pages that a Content Security Policy (CSP) is implemented to ensure the browser only loads/executes explicitly trusted content or content from trusted sources using one or a combination of allow lists, CSP-nonces or CSP-hashes.
• Verify for all pages that a Content Security Policy (CSP) is implemented to ensure the browser only loads/executes explicitly trusted content using CSP-nonces and/or CSP-hashes.

This definitely seems like the right direction to me @ryarmst @jmanico :)

Slapping a header on an application is easy, but making an existing application work with a strict CSP is hard. (@Sjord)

This is an important point but I also agree with @jmanico that L3 requirements are usually hard and that

I think copy/pasting AI-generated content is not helpful.

@jmanico I think I have to agree with this, the guidance tends to be a little unfocused unfortunately.

---

My questions

@Sjord @ryarmst @jmanico @elarlang:

• We have two requirement suggestions above, do we think either of them can be L2?
• Do we definitely want/need both CSP requirements here?
• Do we need any other CSP requirements or would these be sufficient together with a reference in the notes to the CSP cheatsheet?

[ryarmst]

@tghosth on your questions:

• A full nonce/hash based approach may be too much of a burden for L2, so I would ask: is the effort required to implement an allow-list based approach appropriate for L2 and worth the benefits? Despite the existing evidence of widespread bypasses for this approach in practice, it can be effective depending on the implementation. One of the problems here is how to determine whether an allow-list based approach is sufficiently secure for a given application, but I think this is out of the scope of ASVS requirements. I think perhaps there may even be value in encouraging adoption/implementation, even if the stated requirements are not strict. On that point, perhaps a reasonable requirement for L1 would simply be the implementation of a CSP that defines permitted resources with no specific requirements for how to achieve it. However, as @Sjord noted, implementing any reasonably secure policy may be infeasible for many existing applications and CSP is ultimately a defense in depth mechanism for this use case (restriction of content/resources). I have encountered applications vulnerable to XSS that could not be exploited due to an effective allow-list implementation. I have never encountered an application using unsafe-inline that could not be exploited (if there was a XSS vector).
• I do not feel strongly either way. They could be combined-as with inline references to L2 vs. L3 requirements, but I think the question of what the core requirements are for each level is best answered by ASVS experts on whether these requirements align in general with L2 and L3 in terms of benefit/effort.
• I think other CSP use cases are better handled by vector-specific requirements (as noted by @elarlang and as in v4.0.3). I will also comment on #1958

[jmanico]

Because Allow-Lists are overall bypassable (93% bypassable) I want to make sure we encourage nonce/hash policies in a very strong way. I vote for L2. Also, CSP policies that try to prevent exfiltration are also weak, and the standard has moved away from trying to plug all the exfiltration vectors. I suggest we focus ASVS CSP requirements on just XSS/content injection defense.

[Sjord]

I think having a best-effort CSP using allowlists should be L2, and having a watertight CSP using nonces should be L3.

I think script-src 'self' can be part of a watertight CSP. Also, when there is an injection point inside a <script> block, XSS is still possible even with nonces.

and the standard has moved away from trying to plug all the exfiltration vectors

@jmanico This sounds interesting, outside the context of this issue. Do you have additional information on this where I can read more about this?

[jmanico]

Here is the research on CSP bypasses and similar.

https://speakerdeck.com/lweichselbaum/csp-a-successful-mess-between-hardening-and-mitigation?slide=16 and https://speakerdeck.com/mikispag/defense-in-depth-techniques-for-modern-web-applications-and-googles-journey-with-csp-michele-spagnuolo-and-lukas-weichselbaum

.. even with a strict allow list, bypasses include: 1) JSONP endpoints 2) BASE tag jumping 3) Object-tag injection and more

[Sjord]

I didn't really ask about CSP bypasses, but about exfiltration vectors. They talk about that in the presentation, but that's only focused on data exfiltration through JavaScript. It still seems valuable to prevent e.g. CSS injection to prevent exfiltrating the CSRF token.

Here's another interesting slide from the same presentation, which could help us determine which CSP directives to require at which levels:

However, I think their level 1 won't allow inline event handlers (i.e. <button onclick="...">, so if an application has that it won't be that easy to deploy.

[jmanico]

In general, the CSP standard body has stopped trying to prevent data exfiltration with CSP. There are just too many vectors. CSP is really about stopping the initial injection.

[Sjord]

@jmanico Do you have a source for that? Some publication of the CSP standard body that confirms this?

[jmanico]

@jmanico Do you have a source for that? Some publication of the CSP standard body that confirms this?

For sure. Let me do a little digging on this and I'll get back to you.

But basically, attackers have developed rather sophisticated techniques that can bypass CSP protections, such as using trusted domains or exploiting browser bugs. CSP is less effective in stopping data exfiltration, especially when attackers use legitimate channels for data transmission.

I'll give you a reference soon.

[jmanico]

This is from one of the CSP standard body members:

"It's true that CSP isn't suited to prevent data exfil. E.g. it's trivial to use navigation to extract data and there's nothing you can do with CSP to prevent this.

Once the attacker has script execution it's game over. So the primary goal is to prevent that from happening.

I'm not sure if there's an official w3c stance on it, but indirectly this position is confirmed by consensus of deprecating the navigate-to CSP directive.

iirc we also had a slide on this in our 2019 locomocosec talk"

[tghosth]

@jmanico, having read back through the comments above and especially @ryarmst's comment I think that it is a little unrealistic for a strict nonce/hash based policy for L2 and an allow list based policy might be more difficult than it is worth.

It makes me thing that the L2 requirement should be non-prescriptive on how it is achieved and the L3 requirement should specify nonce/hash based policy.

For the specific wording, I think it will depend on the discussions in #1958.

[jmanico]

It makes me think that the L2 requirement should be non-prescriptive on how it is achieved and the L3 requirement should specify nonce/hash based policy.

I like this approach. 👍🏼