Aspnetcore.docs: Add guidance on how to enable CSP for Blazor

[javiercn]

[EDIT by guardrex to add the topic metadata]

• We looked into enabling this on the templates but deemed it too hard.
• Instead we want to offer some basic guidance on how to use CSP within a project to protect against XSS

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: b1a9f84a-feaa-d2b0-409a-01f75f9101a0
• Version Independent ID: aeec639f-a9d6-2f00-b61f-2c316ef6afb6
• Content: Secure ASP.NET Core Blazor Server apps
• Content Source: aspnetcore/security/blazor/server.md
• Product: aspnet-core
• Technology: aspnetcore-security
• GitHub Login: @guardrex
• Microsoft Alias: riande

[javiercn]

Some notes

As part of the security model for blazor server-side we are exploring how feasible is to use CSP to protect against XSS. CSP is a general security mechanism that informs the browser of what are valid sources for different content items loaded on a page or actions taken by a component on a page. For example, CSP can limit the the sources for scripts, stylesheets, images, etc. or limit the origins to which outgoing requests can be sent through different methods.

CSP allows a developer to specify one or more policies that get applied to the document. These policies can be specified either on the Content-Security-Policy header or on the meta tag. A document needs to pass all specified policies to be correct/valid, this means policies don't combine, in any form, but that aspects of a policy can subsume aspects of other policies.

Policies are evaluated while the document is loading. The user-agent (browser) inspect every candiate source and determines if it meets the policy. When it does not, it simply blocks loading that element. For example, a policy might not allow third party scripts in a document. When a document contains a script (for example in the src attribute of a script tag) to a third party origin, the browser sees that it is not included on the policy and prevents it from loading.

CSP in the context of Blazor.

• We can apply CSP to blazor to force users to white-list any potential source for XSS, like third party scripts, common in ad technology. In addition to CSP we want to use other things like SRI on the scripts in the page to prevent a roge script from injecting malicious code.
• The way we should apply CSP in blazor is through the use of the meta tag on the host page in the templates. CSP on the meta tag doesn't support the full range of options but it supports the ones we need, and by having the policy in the template its easy for customers to modify and adapt to suit their needs.

Challenges with CSP

• CSP, while incredibly powerfull is not something easy to undertand, so enabling it in our templates will require some documentation/guidance on how to create and test a good policy.
• Errors apprear in the blowser console and are usually easy to understand. Chrome gives information about elements that don't comply with the policy and indicate how to modify the policy to allow for the blocked item.
• Some of the techniques used in ASP.NET Core and blazor server-side are problematic with CSP. Specifically:
  
  
  
  • The way we craft the UI for disconneced scenarios causes CSP issues due to inline scripting.
  
  
  • The way we check for fallback sources for CSS also causes issues due to inline scripting.
  
  
• The policy only works on browsers that support all included directives, for example. Edge doesn't support block-all-mixed-content

A minimal policy to use with our templates

• We could enable a policy to use with blazor server-side (and any other template we care about) as follows:

<meta http-equiv="Content-Security-Policy" content="block-all-mixed-content; upgrade-insecure-requests;">
<meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src data: https://*; script-src https://stackpath.bootstrapcdn.com/ 'sha256-34WLX60Tw3aG6hylk0plKbZZFXCuepeQ6Hu7OqRf8PI=' 'self'; style-src https://stackpath.bootstrapcdn.com/ 'unsafe-inline' 'self';">

There are actually two policies (the document needs to comply with both):

• The first policy relates to HTTPS, prevents loading mixed content and tries to upgrade HTTP requests to HTTPS automatically. This is important to guarantee the integrity of the scripts and stylesheets loaded in the page. (HTTP doesn't provide any integrity guarantee)
• The second policy deals with the content and establishes the following:
  
  
  
  • default-src 'self': Unless specified otherwise, the only source valid for content is our same origin.
  
  
  • img-src: Images can be loaded from data urls and any https source. This is required for bootstrap to work.
  
  
  • script-src 'self' https://stackpath.bootstrapcdn.com/ 'sha256-34WLX60Tw3aG6hylk0plKbZZFXCuepeQ6Hu7OqRf8PI=';: Scripts can be loaded from our origin, the Bootstrap CDN or be an accepted inline script. The hash corresponds to the script inlined to perform fallback detection.
  
  
  • style-src https://stackpath.bootstrapcdn.com/ 'unsafe-inline' 'self': Stylesheets can be loaded from our origin, the Bootrap CDN or inlined. The inline piece is the most troublesome and its caused by how we craft the UI for the reconnect case. We should consider changing it to something else that doesn't require inline styling.
  
  

Compatibility

• block-all-mixed-content: All but Edge/IE
  
  
  
  • https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/block-all-mixed-content
  
  
• upgrade-insecure-requests: All but Edge/IE
  
  
  
  • https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/upgrade-insecure-requests
  
  
• img-src: All but IE
  
  
  
  • https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/img-src
  
  
• script-src: All but IE
  
  
  
  • https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src
  
  
  • https://www.caniuse.com/#feat=contentsecuritypolicy2
  
  
• style-src: All but IE
  
  
  
  • https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/style-src
  
  

Conclusion

CSP is a good fit for blazor to protect the source and target origins for content, so it is good to prevent the leackage of circuit ids. That said, CSP is complex to handle to understand and requires browser support, which is spotty across browsers. For that reason, I think we should enable it in our templates but not use it as the sole mechanism to protect circuit ids, as we want to allow users to remove the policy if its causing issues with their apps.

[serpent5]

On the off-chance you haven’t seen it before, it might be worth running the suggested policies though Google’s CSP validator. It complains about use of a host whitelist and a missing object-src. I understand that neither of those would be a high risk in this case but I just wanted to make the suggestion. Don’t feel obligated to respond if this is already something that’s been considered. 😄

[javiercn]

@serpent5 Thanks that's a neat tool. The above policy is just an example and the result of me tinkering a bit. There is something more tightened that can likely be crafted.

[guardrex]

Plz correct the labels if I guessed wrong (e.g., if this is for Pre6 and will be worked by the PU).

[mkArtakMSFT]

@javiercn can you add the missing content here, so @guardrex can start working on this. I see you've got a lot covered here but also mentioned that some more need to be done here.

[guardrex]

I can probably work out the draft from what's here.

@javiercn Recommend that u add anything else that you think would be helpful. If your remarks ☝️ cover it, then I'll take it from there.

EDIT Upon review, CSP is applicable to Blazor WebAssembly apps :point_right: they can leverage CSP for their assets, too.