This is done to ensure that the files have not been modified. The sha-384
It’s a cryptographic summary of the SHA-2 family, so it’s an encryption hash. This feature is sensitive to any change, ie any change in the file, even minimal, will generate a different hash, I believe that this explanation is minimally sufficient.
The integrity
precisely serves to ensure that a modified file is not downloaded by the user.
Imagine the situation:
- Several websites use the
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 tries to locate by
form
and when filled out sends the data to it.
Upshot:
Everyone who used this file (https://maxcdn.../bootstrap.min.js
) will have the site compromised because it will load a modified JS, which will send information (e.g. login/password) to that malicious person, after all most sites have login/password forms, so everyone who types will send information to that attacker.
This can be compared to an XSS, only instead of a user inject a code, you injected it yourself, indirectly.
There are other ways to prevent the above case by using the CSP (Content-Security-Policy), she can even compel you to inform the integrity
, but that’s out of the question here.
How to avoid this? Theoretically using hash.
Once this file will not be changed, you place:
<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 been changed and remains identical. If an attacker changes the file it will have another hash, which will not be equivalent to what you reported on integrity
, the browser will ignore the downloaded file.
You can use the https://www.srihash.org/ to get the hashes of already hosted files, obvious you should do this when the file is reliable, otherwise you will calculate the hash of the modified file.
Of course you can also use language functions or libraries such as openssl
to calculate the hash of the files and use them.
The use of automatic mechanisms using openssl (or hash_file
, in PHP) is quite useful if you use a CDN (example Cloudflare), you can create a init()
, function started when performing, who already calculates hashes from his own files, which will later be stored on the CDN. So if the CDN is compromised your site will not suffer great impact, at least not seriously compromising safety.
The reason for using SHA-384 instead of another algorithm from the same family (e.g. 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 couldn’t find any information to prove that this is the reason why.
I am grateful for the reply, but I still do not understand the real importance of this, whether it is a rule or an option and what impact it would have if it were removed.
– Lucas Henrique
@Lucashenrique An example of
crossorigin
is disabled: let’s say an exception happens in your bootstrap and it generates a message like "undefined style" or something like that. This error message by mentioning in which JS line is happening the call stack error would only be passed to your site ifcrossorigin
is enabled. Otherwise you would only get a generic JS error, without saying call stack, no error description.– DH.
Already the
integrity
you probably don’t understand what checksum is. Checksum is a method of generating a hash, a text, that represents the file. If the contents of the file are different, the checksum is different. Useintegrity
ensures that the checksum is checked, preventing a file that has been downloaded and is corrupted from being used, or even some wrong version of the file. If the checksum of the browser file does not match the quoted tag it will download again until the two checksums are equivalent.– DH.
Perfect collaboration @DH. I also had these doubts, thanks man!
– Luiz Augusto Neto