Content Security Policy

magnus · February 9, 2021, 5:41pm

Hello,

I'm using Radzen Blazor for a Blazor WASM PoC and so far it's seems pretty neat.

However, I have a problem setting the correct Content Security Policy header without resorting to 'unsafe-inline' directive. I would prefer a sha-256 or maybe a nonce if possible?

Microsoft has documented CSP for Blazor WASM here:

Thanks in advance for any help!

enchev · February 10, 2021, 8:59am

Hi @magnus,

I'm not sure I understand your question. You don't know where to declare the meta tag?

magnus · February 10, 2021, 9:29am

Thanks for the answer.

I set the header in web.config so that's not a problem, it's what least "priveledges" needed for Radzen to run.

For latest Radzen.Blazor.js the hash 'sha256-pRMAucOBdMdC2z5zEOUr2nMkyE9Y06L6PBeBKrjyKjY=' works.

But it's also running inline javascript sometimes (noticed on fileupload), and there I haven't been able to calculate a working hash. I'm not sure, maybe the inline script could come with a nonce set?

korchev · February 10, 2021, 10:02am

The Radzen Upload does not use inline script elements. The complete source is available here.

magnus · February 10, 2021, 10:45am

I investigated a little further. When I look at the generated code on the client/browser for RadzenUpload-input it looks like this:
<input id="450ce315-3e26-4920-a526-ed4b64aacac0" type="file" onchange="(function (e) { if (true) { Radzen.upload(e.target, '', false, true); e.target.value = ''; } else { Radzen.uploadChange(e.target) } })(event)" _bl_33="">

It's the onchange javascript that is inline as also seen in source code:

github.com

radzenhq/radzen-blazor/blob/master/Radzen.Blazor/RadzenUpload.razor#L15


    @ChildContent
</CascadingValue>
@if (Visible)
{
<div @ref="@Element" style="@Style" @attributes="Attributes" class="@GetCssClass()" id="@GetId()">
    <div class="rz-fileupload-buttonbar">
        <span class="rz-fileupload-choose rz-button  rz-button-text-icon-left">
            @if (Multiple)
            {
                <input id="@Id" @ref="@fileUpload" type="file" multiple accept="@Accept"
                       onchange="(function (e) { if (@Auto.ToString().ToLower()) { Radzen.upload(e.target, '@Url', @Multiple.ToString().ToLower(), true); e.target.value = ''; } else { Radzen.uploadChange(e.target) } })(event)" />
            }
            else
            {
                <input id="@Id" @ref="@fileUpload" type="file" accept="@Accept"
                       onchange="(function (e) { if (@Auto.ToString().ToLower()) { Radzen.upload(e.target, '@Url', @Multiple.ToString().ToLower(), true); e.target.value = ''; } else { Radzen.uploadChange(e.target) } })(event)" />
            }
            <span aria-hidden="true" class="rz-button-icon-left rzi rzi-plus"></span><span class="rz-button-text ">@ChooseText</span>
        </span>
    </div>
    @if (files.Any())

This results in "Refused to execute inline event handler because it violates the following Content Security Policy..." unless you set Content Security Policy to 'unsafe-inline'

This post explains the problem:

It would be great if this sort of javascript could be moved to the Radzen.Blazor.js (best) or an inline block with nonce (second best), otherwise users of Radzen Blazor won't be able to use without having unsafe Content Security Policy settings.

korchev · February 10, 2021, 11:09am

Thanks for the investigation. We will consider your feedback for a future release of Radzen.Blazor. For now you would have to use unsafe-inline.

egranty · February 10, 2021, 3:27pm

'nonce-value' is not applicable for Blazor WASM because of client side rendering. Nonces should be generated with fresh value each page loading. It's possible on server side only.
Also 'nonce-value' can be used only to allow inline scripts kind of <script>...</script>. But Radzen Blasor code use a lot of other kinds of inline scripts - inline event handlers in tags (you have found part of them) and also javascript:-navigation like href="javascript:void(0)", for example:
RadzenAccordion:
<a @onclick="@((args) => SelectItem(item))" href="javascript:void(0)" role="tab" tabindex="0"

RadzenPager:
<a class="rz-paginator-first rz-paginator-element" href="javascript:void(0)" tabindex="-1" @onclick="@(() => FirstPage())">

There is no way to avoid of using 'unsafe-inline' token, because of 'unsafe-hashes' token designed for these cases, is not supported by Safari.

The best you can do, it's to use the policy:

script-src 'self' 'unsafe-inline'; script-src-elem 'self' 'sha256-...' (all hashes here); script-src-attr 'unsafe-inline';

It will mitigate consequences of 'unsafe-inline' for Chrome browsers - injection of <script>...</script> will be prohibited. Firefox and Safari will follow script-src 'self' 'unsafe-inline' rule.

Also Radzen Blasor code use a lot of style= attributes in tags, therefore you have to use 'unsafe-inline' in style-src directive too.

magnus · February 10, 2021, 3:41pm

Thanks, very informative! Content security policy is a bit tricky to get right...

Couldn't I make it:

script-src 'self'
'unsafe-eval';
script-src-elem 'self'
'sha256-...'
'sha256-...';
script-src-attr 'unsafe-inline';

With the 'unsafe-inline' removed from script-src?

egranty · February 10, 2021, 3:56pm

With the 'unsafe-inline' removed from script-src?

No, Safari and Firefox do not support script-src-attr / script-src-elem directives, therefore they will use script-src. Without 'unsafe-inline' all inline scripts (event handlers in tags, javascript-navigation and <script>) will be blocked in Safari/Firefox.

script-src will apply for Safari and Firefox, and script-src-attr / script-src-elem - for Chrome. That's why Chrome users will be protected against XSS much better.

PS: why do you wish to add 'unsafe-eval'? You do use eval() or new Function() in the app?

Scotty · February 8, 2022, 4:37am

Is there any update on this? It seems we still have to use script-src 'self' 'unsafe-inline'

korchev · February 8, 2022, 6:14am

No, there isn't an update. The changes required to support restrictive content policies are too broad for us to consider at this time. We would probably accept pull requests though as long as they:

Don't overcomplicate the implementation
Don't break existing functionality