Subresource Integrity (SRI) is a technique that can help protect web applications against attacks originating from content providers. When using javascript from external sources on your website, you do not have control of the server or CDN that is hosting the content, you are relying on third party data without any guarantee that the content will be served as expected.
If the external source is compromised, the website could be defaced or used to spread malware. Although it seems like a hypothetical attack, this problem has occurred before in many companies, below we demonstrate a real case example and how to use this resource.
In this article, we will explore the benefits of SRI and provide a step-by-step guide on how to implement it in your web application.
Development
In 2018, researchers at RiskIQ Inc. discovered that “MageCart” (umbrella term used to define at least 7 groups of fraudsters) was running a digital skimming campaign, which resulted in a violation at Ticketmaster. The researchers identified that a provider of web functionality known as Inbenta, used for language processing to answer users’ questions, had been compromised, allowing attackers to steal users’ credit card information.credit card cloningcredit card cloning
As part of the attack that resulted in the Ticketmaster breach, Magecart compromised Inbenta and inserted malicious JavaScript into Inbenta’s JavaScript code, which is used by the Ticketmaster website. The malicious JavaScript acted as a keylogger, so any data sent to the site was also sent to a server managed by the attacker, allowing Magecart to steal credit card information.
The online merchant Newegg was also the victim of a similar attack carried out by MageCart, the image below shows the code injected by the attackers, which sends the credit card information to a domain controlled by the crackers (neweggstats.com):
The domain registered through the Namecheap service three days before the attack still has a TLS certificate, allowing it to obfuscate the data that was being sent, a common practice among the group.
Since around 2015, MageCart has been observed modifying or injecting JavaScript codes into payment web pages of various organizations to steal credit card data and customer PII. Based on currently available details, in most cases, compromised third-party services or the compromise of the target’s web server was the initial infiltration vector.
Solution: Subresource Integrity (SRI)
An effective solution to prevent JavaScript file compromise attacks is the implementation of subresource integrity (SRI) functionality. This security measure consists of generating a cryptographic hash of the original JavaScript file, compared with the hash of the file received by the browser. If the hashes do not match, the execution of the modified JavaScript code is blocked by the browser, ensuring the integrity of the sub-resources used by the website.
How to use Subresource Integrity
As its concept, the implementation of the SRI is relatively simple and is done through the “integrity” attribute in the <src> or <link> elements, the attribute value is composed of a prefix of the hash algorithm used, followed by a dash and the base64 encoded hash value. The example below shows the use of SRI in the inclusion of bootstrap via CDN:
<script src=”https://cdn.jsdelivr.net/npm/bootstrap@5.2.3/dist/js/bootstrap.bundle.min.js” integrity=”sha384-kenU1KFdBIe4zVF0s0G1M5b4hcpxyD9F7jL+jjXkk+Q2h455rYXK/7HAuoJl+0I4″ crossorigin=”anonymous”></script>
This way, the browser will download the file and, before executing it, calculate the base64 hash and then use the hashing algorithm to confirm that the hash indeed matches the file.
However, it’s important to note that the third-party service delivering your file must support CORS to work correctly with SRI. The “crossorigin” attribute tells the browser to fetch the file in a way that allows it to be read later, failing if CORS is not supported. Fortunately, many CDNs already enable CORS by default.
Generating SRI hashes
There is some ways you can use to generate the SRI hash, the first one is by using a command-line
with openssl:
cat ExternalFile.js | openssl dgst -sha384 -binary | openssl base64 -A
with shasum:
shasum -b -a 384 ExternalFile.js | awk ‘{ print $1 }’ | xxd -r -p | base64
Alternatively, you can use a tool called srihash.org, it’s the easiest way, you just have to paste your file URL and the application will retrieve the code.
SRI and CSP
Another interesting thing to note is that you can use SRI within your content security policy (CSP), you can define which types of files you want to enforce the integrity check in your application. For example, if you want all JavaScript files to use SRI integrity you can use the following:
Content-Security-Policy: require-sri-for script;
You can also combine script and style into one single rule, covering all JS and CSS files:
Content-Security-Policy: require-sri-for script style;
Conclusion
Finally, loading external resources in the application can present a potential risk, even if you trust the source, nobody knows if it will suffer a violation, using the integrity attribute it is possible to guarantee that no malicious code from a third-party file is executed.
This feature is yet another small piece in the security chain to stay one step ahead of threats and should be considered in your secure development process, in addition to being yet another attribute that can be used in SCA (Software Composition Analysis) methodology tests.
References:
- Inside Magecart
- Magecart: Javascript Injection used to breach Newegg, steal PCI
- Magecart claims another victim in Newegg merchant data theft
- Subresource Integrity
- Ticketmaster Chat Feature Leads to Credit-Card Breach
