Tag Archives: 3rd party component

Sub Resource Integrity – SRI

Do you rely on content distribution networks or CDNs to provide some of your resources? You may not consider some of your resources in this category, but really it is any resource that is provided outside of your server. For example, maybe you pull in the jQuery JavaScript file from ajax.googleapis.com rather than hosting the file on your server.
These CDNs provide a great way to give fast access to these resources. But how do you know you are getting the file you expect?

As an attacker, if I can attack multiple people vs just one, it is a better chance of success. A CDN provides a central location to potentially affect many applications, vs. targeting just one. Would you know if the CDN has modified that file you are expecting?

Welcome Sub Resource Integrity, or SRI. SRI provides the ability to validate the signature of the file against a predetermined hash. It is common for websites that provide files for downloads to provide a hash to validate the file is not corrupt. After downloading the file, you would compute the hash using the same algorithm (typically MD5) and then compare it to the hash listed on the server.

SRI works in a similar way. To implement this, as a developer you create a hash of the expected resource using a specified hashing algorithm. Then, you would add an integrity attribute to your resource, whether it is a script element or stylesheet. When the browser requests the resource, it will compute the hash, compare it to the integrity attribute and if successful, will load the resource. if it is unsuccessful, the file will not be loaded.

How it works

Lets look at how we would implement this for jQuery hosted at google. We will be including the reference from https://ajax.googleapis.com/ajax/libs/jquery/3.2.1/jquery.min.js

Initially, we might start by just creating a script tag with that as the source. This will work, but doesn’t provide any integrity check. There are a few different ways we can create the digest. An easy way is to use https://www.srihash.org/. The site provides a way to enter in the url to the resource and it will create the script tag for you.

Another option is to generate the hash yourself. To do this you will start by downloading the resource to your local system.

Once the file is downloaded, you can generate the hash by executing the following command:

openssl dgst -sha384 -binary Downloads/jquery.min.js | openssl base64 -A

Make sure you change Downloads/jquery.min.js to your downloaded file path. You should see a hash similar to:


Now, we can build our script tag as follows (Don’t forget to add the hashing algorithm to the integrity attribute:

<script src=”https://ajax.googleapis.com/ajax/libs/jquery/3.2.1/jquery.min.js” integrity=”sha384-xBuQ/xzmlsLoJpyjoggmTEz8OWUFM0/RC5BsqQBDX2v5cMvDHcMakNTNrHIW2I5f” crossorigin=”anonymous”></script>

Notice that there is a new crossorigin attribute as well. This is set to anonymous to allow CORS to work correctly. The CDN must have CORS set up to allow the integrity check to occur.

If you want to test the integrity check out, add another script tag to the page (after the above tag) that looks like the following:


When the page loads, it should alert with some jQuery information. Now modify the Integrity value (I removed the last character) and reload the page. You should see a message that says “undefined”. This means that the resource was not loaded.

Browser support is still not complete. At this time, only Chrome, Opera, and Firefox support this feature.

Handling Failures

What do you do if the integrity check fails? You don’t want to break your site, right? Using the code snippet we tested with above, we could check to make sure it loaded, and if not, load it from a local resource. This gives us the benefit of using the CDN most of the time and falling back to a local resource only when necessary. The following may be what the updated script looks like:

<script src=”https://ajax.googleapis.com/ajax/libs/jquery/3.2.1/jquery.min.js” integrity=”sha384-xBuQ/xzmlsLoJpyjoggmTEz8OWUFM0/RC5BsqQBDX2v5cMvDHcMakNTNrHIW2I5f” crossorigin=”anonymous”></script>
<script> window.jQuery || document.write(‘<script src=”/jquery-.min.js”><\/script>’)</script>

When the integtrity check fails, you can see the local resource being loaded in the image below:


If you are using resources hosted on external networks, give some thought about implementing SRI and how it may benefit you. It is still in its early stages and not supported by all browsers, but it can certainly help reduce some of the risk of malicious files delivered through these networks.

Jardine Software helps companies get more value from their application security programs. Let’s talk about how we can help you.

James Jardine is the CEO and Principal Consultant at Jardine Software Inc. He has over 15 years of combined development and security experience. If you are interested in learning more about Jardine Software, you can reach him at james@jardinesoftware.com or @jardinesoftware on twitter.

ImageMagick – Take-aways

Do your applications accept file uploads? More specifically, image uploads? Do you use a site that allows you to upload images? If you haven’t been following the news lately, there was recently a few vulnerabilities found in the ImageMagick image library. This library is very common in websites to perform image processing. The vulnerability allows remote code execution (RCE) on the web server, which is very dangerous. For more specific details on the vulnerability itself, check out this post on the Sucuri Blog.

There are a few things I wanted to focus on that are less about ImageMagick and more focused on better security solutions.

Application Inventory

I know, enough already. I get it, I mention application inventory all the time. It is with good reason. We rely heavily on 3rd part components just like ImageMagick and there are bound to be security flaws identified in them. Some may be less critical, while others demanding the highest priority. The issue at hand is that we cannot defend against the unknown. In this case, even if we are aware of a vulnerability, it doesn’t help us if we are not aware we use the vulnerable component. Time is important, especially when it comes to critical type issues. You need to be able to quickly determine if your company uses the vulnerable component, which apps are effected, and what types of data resides in those systems. Performing fire drills for every vulnerability announced is very inefficient. Being able to quickly identify the effected areas allows for a better understanding of any risk changes.


When you are configuring your applications, think about the type of permissions the application has on the server. Does it have the ability to write to specific folders, execute specific files, read data, etc.? Does the application run as an administrator with full rights? To help reduce the attack surface we must understand what the app needs to do, and then make sure the permissions are aligned with those needs. In this case, the files may be stored on the file system to be used later so write permissions may be required. It is still possible to limit those write permissions to specific folders and even limiting execution permissions.

Application Configuration

How you design and configure your application plays a significant role in how security is handled. In regards to allowing file uploads, how do you handle storing the files? Are they on the file system or in the database? How are features configured? In the case of ImageMagick, there are configuration settings that can be set to limit the vulnerabilities. Make sure that you are only accepting file types that are needed and discarding others. These configurations can take many forms, but will help provide security when they are truly understood.

Importance of Input Validation

The vulnerability in ImageMagick highlights the importance of sanitizing input and performing solid validation. In this case, the file name is not properly handled which allows an attacker to run unintended commands. We have to check to make sure that the data passed to our applications is what we are expecting. If it is not, then it must be discarded.

This is not the last time we will see a vulnerable component that is used by lots of applications. It is part of the risk of using external components. We can do more on our side to make sure that we know what we are using and preparing for the event that something goes wrong. Take the time to understand your applications and think about the different ways security may be effected.