This is done to ensure that the files have not been modified. sha-384
is a cryptographic summary of the SHA-2 family, in short it's a hash encryption. This feature is sensitive to any change, ie any change in the file, even minimal, will generate a different hash, I believe this explanation is minimally sufficient.
The integrity
is just so you can ensure that the changed file is not downloaded by the user.
Imagine the situation:
Several sites use https://maxcdn.../bootstrap.min.js
.
A malicious person can gain access to the server that is storing this file.
This person changes the file. This change is a JavaScript that attempts to find by form
and when filled sends the data to it.
Result:
Everyone who used this file ( https://maxcdn.../bootstrap.min.js
) will have the website compromised, because it will load an altered JS, which will send information (eg login / password) to such a malicious person, after all a lot of sites have login / password forms, so everyone who types will send information to that attacker.
This can be likened to an XSS, except that instead of a user injecting a code, you injected it yourself indirectly.
There are other ways to prevent the above case by using the CSP (Content-Security -Policy) , it may even force you to report integrity
, but that's out of the question here.
How to avoid this? Theoretically using hash.
Since this file will not be changed, you put:
<script src="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.6/js/bootstrap.min.js"integrity="sha384-0mSbJDEHialfmuBBQP6A4Qrprq5OVfW37PRR3j5ELqxss1yVqOtnepnHVP9aJ7xS" crossorigin="anonymous"></script>
This will ensure that this file has not changed and remains identical. If an attacker changes the file it will have another hash, which will not be equivalent to what it reported in integrity
, the browser will ignore the downloaded file.
You can use link to get the hashes of files already hosted, obvious you should do this when the file is reliable if not you will compute the hash of the modified file .
Of course you can also use functions of the language itself or libraries as openssl
to calculate the hash of the files and use them.
Using automated mechanisms, using openssl ( or hash_file
, in PHP ) is very useful if you use a CDN (eg CloudFlare), you can create a init()
, function started when running , which already calculates the hashes of its own files, which will later be stored in the CDN . So, if the CDN gets compromised your site will not suffer much impact, at least not that it seriously compromises security .
The reason for using SHA-384 instead of another algorithm from the same family (eg SHA-512) has not yet been found. However, the reason may be because SHA-256 and SHA-512 are vulnerable to length extension attack, but I have not found information that proves that this is the reason.