Request to Support Dynamic Resource Validation

[gulachek]

Transitioning a large dynamic web SPA to using CSP proves difficult. The initial page load needs to anticipate every possible resource that may need to be embedded and needs to list out all of them in the initial request. This is both problematic from a security standpoint (very many false positives that don't actually need to be allowed all the time), and it doesn't scale well, since there's a technical limitation to the maximum size HTTP headers can be, so enumerating every possible domain that's anticipated becomes infeasible.

I'm aware that it's questionable that a web page really needs all of this 3rd party content, but breaking currently supported configuration to load 3rd party links and content is also very undesirable. If there were a way for the server to indicate updates to the user agent's current CSP, or if there were a similar structure to report-uri where the server responded if a violation is okay to serve, this would make supporting these kind of security transitions vastly easier. This issue serves to document this need, and if what I'm currently describing is possible already, I'm happy to learn more.

Potential alternatives include proxying all 3rd party content through the server, but that seems to introduce additional challenges (including more security challenges, which CSP is trying to address in the first place) that could be solved with a seemingly simpler solution to the problem, such as "img-src: 'dynamic(uri)'" or something of that nature.

[annevk]

Did you attempt to start out with a report-only policy to learn what the policy needs to be and account for? That's typically how these transitions are done as I understand it.

[gulachek]

Yes - we're deploying a report-only policy initially to log and see if there are sweeping simplifications we can make, but that's not going to solve the fundamental problem that we're an SPA framework that doesn't know all external content at initial page load and there's no theoretical limit on what framework consumers can embed. Some potential workarounds are to break anything that loads 3rd party content and require them to be in an iframe that serves its own CSP, or we could serialize our client state and reload the page the user is on with an updated CSP. Those sound like poor solutions and I'm skeptical that other SPAs won't run into very similar issues, and it seems like the high level idea of dynamically validating a request would better equip CSP to protect use cases like these and incentivize adoption with a feasible path forward.

…

On Mon, Oct 18, 2021 at 03:44 Anne van Kesteren ***@***.***> wrote: Did you attempt to start out with a report-only policy to learn what the policy needs to be and account for? That's typically how these transitions are done as I understand it. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#518 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALOZK3VQQSKOFWYP5FOYG53UHPNABANCNFSM5GC2LN6Q> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[mozfreddyb]

If you have a high confidence in the scripts you're loading directly (e.g. through <script> elements that the parser sees), then you can use strict-dynamic which will allow subsequent scripts loads transitively. Wouldn't that help?

[gulachek]

Isn't that just for scripts? I'm more concerned about images and iframes.

…

On Tue, Oct 19, 2021 at 02:15 Frederik Braun ***@***.***> wrote: If you have a high confidence in the scripts you're loading directly (e.g. through <script> elements that the parser sees), then you can use strict-dynamic <https://w3c.github.io/webappsec-csp/#strict-dynamic-usage> which will allow subsequent scripts loads transitively. Wouldn't that help? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#518 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALOZK3WG3UC2BDP7APIRIBTUHULHTANCNFSM5GC2LN6Q> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[mozfreddyb]

I'm surprised that images and iframes are of concern. In that case, I think you'll have to implement this yourself in a Service Worker (SW) (though there are caveats when using a ServiceWorker as a "security"-proxy, e.g., the SW's scope, shift+reload override etc.).

It's unlikely CSP will gain this kind of functionality.

[dveditz]

Yes, it's just for scripts--which are what is adding the other content, right? Do you trust them or not?

Unfortunately CSP is not a good fit at limiting content when you don't know what that content is going to be ahead of time.

[gulachek]

I'm curious what you're proposing with a service worker. @daniel I thought strict-dynamic doesn't allow a script to load whatever it wants if it's not another script. And we do know ahead of time what content is going to be embedded. It's just not at the time of the initial page load, and I'm suggesting that a dynamic validation mechanism would make CSP more usable for existing web applications that want some security benefit. Does W3C not support web frameworks that dynamically render components in the same frame that can embed 3rd party content? It seems like a pretty valid and common use case. Do we not want those frameworks to transition to the CSP standard to gain the standard security benefits? How is this transition supposed to be done without listing the entire internet in frame-src if we know which components expect which external resources? CSP currently assumes that every component is either in its own frame or is statically loaded to be included in the initial page load. I'm suggesting this assumption doesn't cover existing valid use cases that would like the benefits of CSP.

…

On Tue, Oct 19, 2021 at 13:03 Daniel Veditz ***@***.***> wrote: Yes, it's just for scripts--which are what is adding the other content, right? Do you trust them or not? Unfortunately CSP is not a good fit at limiting content when you don't know what that content is going to be ahead of time. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#518 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALOZK3RDQAMGW4S264LLAPDUHWXHNANCNFSM5GC2LN6Q> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[mozfreddyb]

I'm curious what you're proposing with a service worker.

I ran a web hacking challenge to enforce Subresource Integrity for all resources using a ServiceWorker-in-the-middle. Unfortunately, my summary is a bit.. chaotic, but I think the included code snippets might still be useful.

[dveditz]

I thought strict-dynamic doesn't allow a script to load whatever it wants if it's not another script.

strict-dynamic only controls script loading and doesn't otherwise restrict what scripts can do. Other parts of a CSP might, of course!

we do know ahead of time what content is going to be embedded. It's just not at the time of the initial page load, and I'm suggesting that a dynamic validation mechanism would make CSP more usable for existing web applications that want some security benefit.

How does a browser distinguish between a page legitimately changing its CSP dynamically, and injected content changing the CSP maliciously? A scripting interface was proposed at one point but we never came up with a mechanism that could be used safely. Embedding a security mechanism in the very content that mechanism considers a priori untrustworthy is far from trivial. We've dabbled with it by letting sites dynamically add CSP through <meta> tags, with the restriction that it can only make a CSP more strict, never less strict (and even with that there's potential for mischief).

But let me back up and ask what "security benefit" you're looking for. CSP tries to do many things. We, the creators of CSP, tend to think stopping XSS is the most important since that is one of the top vulnerability classes in web applications. But when you look at how CSP is actually deployed only a minority of CSP-using sites are configured to combat XSS.

Does W3C not support web frameworks that dynamically render [...] Do we not want those frameworks to transition to
the CSP standard to gain the standard security benefits?

Of course we want to. Are you accusing us of acting in bad faith? Please review our Code of Ethics and assume folks here are well-intentioned even when we disagree.

The different frameworks all work differently and will likely have to cooperate with browser controls in creating and enforcing policies that combat security problems as they affect their framework uniquely. Unfortunately we don't see many of their creators here working with us.

CSP currently assumes that every component is either in its own frame or is statically loaded to be included in the initial page load.

Not quite, but you're right that CSP was conceived in an era where most web content worked like that. In fact the two types of XSS CSP is most effective in addressing (reflected and stored XSS) are largely artifacts of that kind of web page. "Fixing" CSP to address the same set of issues in dynamic content may not be structurally possible. So setting CSP aside for a moment

• what vulnerability scenarios are you trying to stop in dynamic content?
• how do you expect to communicate the changing policy?

Here's a proposal off the top of my head that might get you thinking: a new <link> relation that declares a Security Policy Websocket. As your page loads dynamic content the socket can push the appropriate policy updates that the browser will enforce on the document. To be clear this is NOT a good proposal: may not be implementable in browsers, timing issues will lead to vulnerabilities, and probably not usable by websites in any event. What would you want to use?

[dveditz]

I also invite you to take a look at the "Trusted Types" proposal. It is designed to deal with problems with dynamic content creation that CSP alone can't do much about, although it was not intended to address all the issues CSP tries to address. Trusted Types is usable now in Chrome, Edge, and probably other chromium-based browsers. You could write a flexible and dynamic set of sanitizers, although they would become hugely complex. Even if it doesn't work out in the end, the exercise might help you crystalize what kinds of controls you need a browser to support.

[gulachek]

I feel like my rhetoric is being misinterpreted and I'm not accusing you of being malicious, but I won't fret about it over text-based communication. I'm convinced we're both well intentioned. My initial proposal was that if we want a dynamic validation mechanism, we could have some URI listed in the CSP header from the server similar to how report-uri is listed. Maybe we list it alongside existing static URI match expressions and the dynamic uri would be the last attempt for the browser to load something if it's not already approved. There'd need to be some simple request/response protocol for how it'd validate. Sure it's not as good of performance as one request, but if it's already for 3rd party content, it doesn't seem like a big deal to eat that cost for easier maintenance. Http cookies would give the server a session id to look up what content we approve and respond. So that's how we'd "update" the policy, in that it doesn't all need to be cached in the browser. I'm with you on avoiding a scripting API to relax the CSP delivered from the server. I don't know much about service workers, but that's my first hesitation with that proposal earlier in the chain. It's a good question to loop back to the use case. Our web application targets sensitive information and we want to do what we can to restrict things we embed to only things we expect to embed. For frames, it seems like a best practice defense mechanism to not allow arbitrary sites that might trick users or take advantage of some newly found security issue with frames. Obviously it's good to question how those got embedded in the first place, but the CSP seems like a good line of defense to have if viable. For images, I admittedly haven't looked to see if there're obscure XSS attacks with those, but if we can even just avoid inappropriate images from being embedded, that also seems like a win.

…

On Tue, Oct 19, 2021 at 19:49 Daniel Veditz ***@***.***> wrote: I thought strict-dynamic doesn't allow a script to load whatever it wants if it's not another script. strict-dynamic only controls script loading and doesn't otherwise restrict what scripts can do. Other parts of a CSP might, of course! we do know ahead of time what content is going to be embedded. It's just not at the time of the initial page load, and I'm suggesting that a dynamic validation mechanism would make CSP more usable for existing web applications that want some security benefit. How does a browser distinguish between a page legitimately changing its CSP dynamically, and injected content changing the CSP maliciously? A scripting interface was proposed at one point but we never came up with a mechanism that could be used safely. Embedding a security mechanism in the very content that mechanism considers a priori untrustworthy is far from trivial. We've dabbled with it by letting sites dynamically add CSP through <meta> tags, with the restriction that it can only make a CSP more strict, never less strict (and even with that there's potential for mischief). But let me back up and ask what "security benefit" you're looking for. CSP tries to do many things. We, the creators of CSP, tend to think stopping XSS is the most important since that is one of the top vulnerability classes in web applications. But when you look at how CSP is actually deployed only a minority of CSP-using sites are configured to combat XSS. Does W3C not support web frameworks that dynamically render [...] Do we not want those frameworks to transition to the CSP standard to gain the standard security benefits? Of course we want to. Are you accusing us of acting in bad faith? Please review our Code of Ethics <https://www.w3.org/Consortium/cepc/> and assume folks here are well-intentioned even when we disagree. The different frameworks all work differently and will likely have to cooperate with browser controls in creating and enforcing policies that combat security problems as they affect their framework uniquely. Unfortunately we don't see many of their creators here working with us. CSP currently assumes that every component is either in its own frame or is statically loaded to be included in the initial page load. Not quite, but you're right that CSP was conceived in an era where most web content worked like that. In fact the two types of XSS CSP is most effective in addressing (reflected and stored XSS) are largely artifacts of that kind of web page. "Fixing" CSP to address the same set of issues in dynamic content may not be structurally possible. So setting CSP aside for a moment - what vulnerability scenarios are you trying to stop in dynamic content? - how do you expect to communicate the changing policy? Here's a proposal off the top of my head that might get you thinking: a new <link> relation that declares a Security Policy Websocket. As your page loads dynamic content the socket can push the appropriate policy updates that the browser will enforce on the document. To be clear this is NOT a good proposal: may not be implementable in browsers, timing issues will lead to vulnerabilities, and probably not usable by websites in any event. What would *you* want to use? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#518 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALOZK3VWQQTSY3RSO5LV6TDUHYGZVANCNFSM5GC2LN6Q> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.