How important is Integrity and CrossOrigin attributes?

6

I've been giving it a look, but I still have that doubt. Currently some frameworks, their link and script are coming with attributes integrity and crossorigin .

Ex:

<link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.6/css/bootstrap.min.css" integrity="sha384-1q8mTJOASx8j1Au+a5WDVnPi2lkFfwwEAa8hDDdjZlpLegxhjVME1fgjWPGmkzs7" crossorigin="anonymous">
<script src="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.6/js/bootstrap.min.js"integrity="sha384-0mSbJDEHialfmuBBQP6A4Qrprq5OVfW37PRR3j5ELqxss1yVqOtnepnHVP9aJ7xS" crossorigin="anonymous"></script>

What would be the real importance of these attributes? Is it a CDN rule or option? And what would be the impact or relevance if these attributes were removed?

    
asked by anonymous 21.01.2016 / 18:22

2 answers

4

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.

        
    10.06.2017 / 08:03
    4

    integrity is self-explanatory: integrity check. This is a checksum to ensure that the script that was downloaded did not have anything corrupted nor is it an outdated version on your hard drive, regardless of the reason.

    crossorigin is to enable CORS, and thus execution error information is received by your site. It only works if CORS is enabled on the other side, that in the case of CDN's, this is usually active.

    Source: link

        
    21.01.2016 / 19:14