rehansaeed.github.io
rehansaeed.github.io copied to clipboard
RehanSaeed
[Comment] Subresource Integrity TagHelper Using ASP.NET Core - Part 1
https://rehansaeed.com/subresource-integrity-taghelper-using-asp-net-core/
It isn't just CDN's that get hacked. My mobile ISP (optus) had their dns hijacked, which served a hacked version of ga.js.
http://forums.whirlpool.net.au/archive/2479474
It isn't just CDN's that get hacked. My mobile ISP (optus) had their dns hijacked, which served a hacked version of
ga.js.http://forums.whirlpool.net.au/archive/2479474
That's a great example Justin! It's not just ISP's getting hacked though. Sometimes the ISP's are the ones deliberately doing the hacking in authoritarian regimes. In those cases, Content Security Policy (CSP) saves the day in most cases. Security is all about layers, the more layers you have the safer you will be and Subresource Integrity (SRI) is just one layer in the cake.
You can confirm the presence of SRI hashes on your website with: https://sritest.io Disclaimer: I am the developer of this service
You can confirm the presence of SRI hashes on your website with: https://sritest.io Disclaimer: I am the developer of this service
Cool service. Does it check that the URL has a scheme? Firefox has different behaviour when it doesn't. How would you feel about me recommending your service to check SRI's?
Cool service. Does it check that the URL has a scheme? Firefox has different behaviour when it doesn't. How would you feel about me recommending your service to check SRI's?
Sritest.io works with http:// as well https:// as URLs. Does Firefox check SRI differently depending on the URL scheme?
I would be happy if you wrote something about the service.
Sritest.io works with http:// as well https:// as URLs. Does Firefox check SRI differently depending on the URL scheme? I would be happy if you wrote something about the service.
In my testing having no scheme e.g. //foo.cdn/jquery caused an error in Firefox which stopped the resource loading completely, so perhaps your service should raise a warning/error for this. I did not try http:// in my testing but I would suggest that your service raises a warning/error in this case also, because having a secure connection will act as an added protection.
In my testing having no scheme e.g.
//foo.cdn/jquerycaused an error in Firefox which stopped the resource loading completely, so perhaps your service should raise a warning/error for this. I did not tryhttp://in my testing but I would suggest that your service raises a warning/error in this case also, because having a secure connection will act as an added protection.
Hmmm interesting, I was not aware. I will look into that.
In my testing having no scheme e.g.
//foo.cdn/jquerycaused an error in Firefox which stopped the resource loading completely, so perhaps your service should raise a warning/error for this. I did not tryhttp://in my testing but I would suggest that your service raises a warning/error in this case also, because having a secure connection will act as an added protection.
I created a test html file with // as the URL scheme, and Firefox loaded the page without errors.
Could you please have a look and take me a screenshot perhaps? The file is hosted on http://www.himalaya-taska.hu/sritest.html and https://www.himalaya-taska.hu/sritest.html I am running Firefox 44.0.2
I created a test html file with
//as the URL scheme, and Firefox loaded the page without errors. Could you please have a look and take me a screenshot perhaps? The file is hosted on http://www.himalaya-taska.hu/sritest.html and https://www.himalaya-taska.hu/sritest.html I am running Firefox 44.0.2
When navigating to http://www.himalaya-taska.hu/sritest.html, I get the following warning and then error in Firefox 44.0.2:
Warning: Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://maxcdn.bootstrapcdn.com/bootstrap/3.3.6/js/bootstrap.min.js. (Reason: CORS header 'Access-Control-Allow-Origin' missing). Error: None of the "sha384" hashes in the integrity attribute match the content of the subresource.
Perhaps this is one of my extensions causing the error. I'm using UBlock Origin, Ghostery and HTTPS-Everywhere because I'm paranoid and don't like advertisements.
If the CDN gets hacked then ... won't this then start serving up hashes for the hacked content?
In my testing having no scheme e.g.
//foo.cdn/jquerycaused an error in Firefox which stopped the resource loading completely, so perhaps your service should raise a warning/error for this. I did not tryhttp://in my testing but I would suggest that your service raises a warning/error in this case also, because having a secure connection will act as an added protection.
Possibly it is the extensions, I also had similar issues with them earlier.
Possibly it is the extensions, I also had similar issues with them earlier.
Yes, I think so too. I think it's safer to add https at the start. Perhaps your site could raise a warning about this?
If the CDN gets hacked then ... won't this then start serving up hashes for the hacked content?
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.
Here is a link to a discussion about a further improvement to this tag helper which I plan to release this weekend.
In my testing having no scheme e.g. //foo.cdn/jquery caused an error in Firefox which stopped the resource loading completely, so perhaps your service should raise a warning/error for this. I did not try http:// in my testing but I would suggest that your service raises a warning/error in this case also, because having a secure connection will act as an added protection.
I will have a look, I appreciate your feedback.
[…] Subresource Integrity TagHelper Using ASP.NET Core - Muhammad Rehan Saeed […]
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.
Here is a link to a discussion about a further improvement to this tag helper which I plan to release this weekend.
I think it's a build-time concern. Possibly have a build step that calculates the SHAs and writes them to a known file location then the tag helper looks for them first before falling back to calculating on the fly.
If the CDN gets hacked then ... won't this then start serving up hashes for the hacked content?
Duncan makes a good point. Potentially, you could allow hacked resources in this way. However, given that the SRI hash is cached indefinitely, and assuming you're using a reasonably persistent cache store (basically anything other than in-memory), the odds that the hash would be calculated at the exact point that the resource was compromised (which itself is a pretty wild occurrence, if you're using one of the big global CDNs) are pretty high. It's important to be aware of, but I doubt it would actually be a true security concern.
That said, this method could probably be improved by comparing to a local copy of the resource. ASP.NET Core already has functionality for providing fallback local scripts, should CDN resources fail. This same fallback could be used to compare with the remote version and a mismatch could be either logged or raised as an exception.
Duncan makes a good point. Potentially, you could allow hacked resources in this way. However, given that the SRI hash is cached indefinitely, and assuming you're using a reasonably persistent cache store (basically anything other than in-memory), the odds that the hash would be calculated at the exact point that the resource was compromised (which itself is a pretty wild occurrence, if you're using one of the big global CDNs) are pretty high. It's important to be aware of, but I doubt it would actually be a true security concern.
That said, this method could probably be improved by comparing to a local copy of the resource. ASP.NET Core already has functionality for providing fallback local scripts, should CDN resources fail. This same fallback could be used to compare with the remote version and a mismatch could be either logged or raised as an exception.
Take a look at part 2 of this post. That basically does what you suggest.
Hi @RehanSaeed , Unable to resolve service for type 'Microsoft.AspNetCore.Mvc.Infrastructure.IActionContextAccessor' while attempting to activate 'Boxed.AspNetCore.TagHelpers.SrcSubresourceIntegrityTagHelper'.
I'm getting the below exception while using the tag helper in asp.net core application Can any one help??
Hi @RehanSaeed , Unable to resolve service for type 'Microsoft.AspNetCore.Mvc.Infrastructure.IActionContextAccessor' while attempting to activate 'Boxed.AspNetCore.TagHelpers.SrcSubresourceIntegrityTagHelper'.
I'm getting the below exception while using the tag helper in asp.net core application Can any one help??
You need to register IActionContextAccessor like so:
services.AddSingleton<IActionContextAccessor, ActionContextAccessor>();