1

Almost all of the articles I read about subresource integrity cover loading scripts (and CSS) from CDNs and third-party resources, which makes sense.

Is there any value in adding the integrity attribute to my own (i.e. first-party) scripts?

My site is served using HTTPS so the scripts shouldn't be modified in transit (if an attacker can modify the information in transit from my server then they can modify the HTML anyways).

With regards to the scripts themselves being modified, I would think that if an attacker is able to modify the contents of the files on my server then I have much bigger problems than that can be protected by SRI.

Should I put in the time to implement SRI for first-party scripts? I have a build process already so it isn't difficult to generate the hashes but populating the <script> tags is a tad difficult in my current workflow.

I know it is not supported by Microsoft Edge but that is an orthogonal concern AFAIK.

rink.attendant.6
  • 2,247
  • 4
  • 23
  • 35
  • See https://security.stackexchange.com/questions/238441/solution-to-the-browser-crypto-chicken-and-egg-problem for some interesting reading on this subject. – mti2935 Nov 20 '21 at 23:22

2 Answers2

2

I agree with your assessment that if the scripts are being served off the same server as the HTML then integrity does not gain you much security. It would be a strange compromise where the attacker managed to write to the script files but could not write to other files including HTML (or server-side equivalent PHP,.jar,.dll etc).

If the attacker can modify files on your server and they want to change the javascript served they can just remove, or update the integrity attribute in your HTML.

If you scripts are coming off a different server (physical or virtual) then the integrity attribute will mean the attacker needs to compromise both machines to change the javascript.

David Waters
  • 2,802
  • 2
  • 14
  • 14
  • To be fair, I can imagine pathological cases where a site has been misconfigured and a limited exploit which allows control of user-uploaded content also grants access to static files... so I'd say the value would depend on whether you're writing something you're going to deploy and maintain yourself. If not, defense in depth all the way. – ssokolow Jan 23 '17 at 04:16
0

Hackers does not nescessarily get full control of the server by guessing the logindetails. They may exploit a security hole in a specific page and so get access to whatever they get. So there might be a value in adding the integrity attribute to same origin scripts but no guarantee.

I am myself thinking about (for hosted domains) to simply have an extra (B) domain which is used for storing copies of code from my other domains(A). And then make a cronjob on the B domain, which regularly checks if the code is the same and sends a warning if not. This is to keep the advantages of same origin scripts and add some security to the A domains. This is also usefull for full html pages with js code. The workflow should be relatively simple with a need to update the B domain by entering an URL from the A domain whenever changes are made to the A domain URL.

Hanne
  • 1
  • 1