When you load a file from an external server, you\u2019re trusting that the content you request is what you expect it to be. Since you don\u2019t manage the server yourself, you\u2019re relying on the security of yet another third party and increasing the attack surface. Trusting a third party is not inherently bad, but it should certainly be taken into consideration in the context of your website\u2019s security.<\/p>\n\n\n\n\n\n\n
This isn\u2019t a purely theoretical danger. Ignoring potential security issues can and has already resulted in serious consequences. On June 4th, 2019, Malwarebytes<\/a> announced their discovery of a malicious skimmer on the website NBA.com. Due to a compromised Amazon S3 bucket, attackers were able to alter a JavaScript library to steal credit card information from customers.<\/p>\n\n\n\n It\u2019s not only JavaScript that\u2019s worth worrying about, either. CSS is another resource capable of performing dangerous actions such as password stealing, and all it takes is a single compromised third-party server for disaster to strike. But they can provide invaluable services that we can\u2019t simply go without, such as CDNs that reduce the total bandwidth usage of a site and serve files to the end-user much faster due to location-based caching. So it\u2019s established that we need to sometimes rely on a host that we have no control over, but we also need to ensure that the content we receive from it is safe. What can we do?<\/p>\n\n\n SRI is a security policy that prevents the loading of resources that don\u2019t match an expected hash. By doing this, if an attacker were to gain access to a file and modify its contents to contain malicious code, it wouldn\u2019t match the hash we were expecting and not execute at all.<\/p>\n\n\n HTTPS is great for security and a must-have for any website, and while it does prevent similar problems (and much more), it only protects against tampering with data-in-transit. If a file were to be tampered with on the host itself, the malicious file would still be sent over HTTPS, doing nothing to prevent the attack.<\/p>\n\n\n A hashing function takes data of any size as input and returns data of a fixed size as output. Hashing functions would ideally have a uniform distribution. This means that for any input, Here\u2019s a metaphor:<\/p>\n\n\n\n Suppose you have a 6-sided die and a list of names. The names, in this case, would be the hash function\u2019s \u201cinput\u201d and the number rolled would be the function\u2019s \u201coutput.\u201d For each name in the list, you\u2019ll roll the die and keep track of what name each number number corresponds to, by writing the number next to the name. If a name is used as input more than once, its corresponding output will always be what it was the first time. For the first name, Alice, you roll 4. For the next, John, you roll 6. Then for Bob, Mary, William, Susan, and Joseph, you get 2, 2, 5, 1, and 1, respectively. If you use \u201cJohn\u201d as input again, the output will once again be 6. This metaphor describes how hash functions work in essence.<\/p>\n\n\n\nSolution: Subresource Integrity (SRI)<\/h3>\n\n\n
Doesn\u2019t HTTPS do that already?<\/h4>\n\n\n
How does hashing work?<\/h4>\n\n\n
x<\/code>, the probability that the output, y<\/code>, will be any specific possible value is similar to the probability of it being any other value within the range of outputs.<\/p>\n\n\n\n