SRI tag helper security\fallback #79

Closed
KLuuKer opened this Issue Mar 8, 2016 · 3 comments

Projects

None yet

2 participants

@KLuuKer
KLuuKer commented Mar 8, 2016

As Damian on the asp.net community standup noted.
It's not secure to compute the hash on the server directly from the cdn (even if you cache the result).
Because the file could become compromised at some point in time.
Another note is this > CDNs fail, but your scripts don't have to - fallback from CDN to local jQuery

I would recommend uploading the required file to the server, use that to compute the hash (saves on download time).
And generate a fallback script for when the cdn fails or becomes corrupted like so:

<script src="http://ajax.aspnetcdn.com/ajax/jquery/jquery-2.0.0.min.js"></script>
<script>
if (typeof jQuery == 'undefined') {
    document.write(unescape("%3Cscript src='/js/jquery-2.0.0.min.js' type='text/javascript'%3E%3C/script%3E"));
}
</script>

and of course you could add the SRI tag to both script elements

@RehanSaeed
Member

My initial thinking was that you could check the files at deployment time when the tag helper first runs. Then the tag helper would have calculated the hash and cached it without any expiration time, so you are good from then on. That's still more secure than 'every site on the internet' as Jon Galloway put it in the ASP.NET standup.

I suppose that checking the files on every deployment is not great for the developer. So for the next iteration I will add an alternative source, basically a local file from which the SRI is calculated. Someting like this:

<script src="https://somecdn/jquery.js" 
            asp-subresource-integrity-src="~/js/jquery.js"></script>

In this scenario, the developer would have to check the file for validity every time they upgrade it. I'm not 100% sure if dropping the call to the CDN resource is the way to go. If we kept the call, we could compare the SRI and log an error, giving the developer some quick feedback to something they might otherwise miss if they are using script fallbacks. Perhaps this should be an option?

There is already a fallback script tag helper built in which pretty much generates the code you wrote. However, I prefer not to use them because they are not compatible with Content Security Policy (CSP) because they require the use of inline scripts.

@RehanSaeed
Member
@KLuuKer
KLuuKer commented Mar 14, 2016

Looks great, I totally forgot about the fact that asp.net core already has it included (I'm currently still stuck on asp.net until I get my app rebuilt for core).

As far as I'm concerned you can close this issue.

@RehanSaeed RehanSaeed closed this Mar 14, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment