Third-party hosted website assets, such as JavaScript libraries, are vulnerable to tampering. However, a new technique named Subresource Integrity (SRI) is here to protect these external assets.
One problem is the slow implementation of SRI, thus sritest.io was born. The new service enables website owners and frontend developers to evaluate their sites for SRI hash usage. Sritest.io aims to help the widespread implementation of SRI, thus, ultimately protect website visitors from malicious code.
Update (5 Jun 2020): The sritest.io service is discontinued.
Hosting Website Assets with Third-Parties
Frontend developers tend to trust Content Delivery Networks (CDN) to host some of their website assets such as JavaScript and CSS. Certain third-party CDN services, such as Google, jsdelivr or cdnjs, offer free services to host JavaScript libraries. Other CDNs, like Akamai and CloudFront, provide paid services to host assets.
Both free and non-free CDNs offer two benefits for website owners. Firstly, they serve the assets from geographically close data centers. It provides better visitor experience as pages will load quicker. Secondly, CDNs offer an uptime close to 100%.
The Problem with Trusting Third-Parties
However, there is a great trust involved here: third-party hosted assets are controlled by the provider, not us. JavaScript and CSS stylesheets can be abused to attack website visitors and other sites. Malicious code can exploit browsers, DDoS websites, or hijack user sessions.
(Update 15/01/2016): The sad, current practice is that website developers blindly trust free and private CDNs to host website assets for their web pages. Alas, CDNs could get compromised and start serving malicious Javascript snippets as it happened before with MaxCDN, Pagefair or Reuters.
The second example is from China, where the Great Firewall has injected extra code into JavaScript assets hosted on Baidu’s CDNs. The additional snippet was instructing the browsers of unsuspecting website visitors to launch denial of service (DDoS) attacks against GitHub and GreatFire.org.
Another use case is ISPs injecting extra content into web traffic. The intention of ISPs is to track users and sell these data to third parties for targeted advertising. Comcast, for example, was caught red handed with injecting JavaScript to push ads. There nothing stops ISPs to exploit JavaScript and CSS for adding extra banners, cookies and popups.
Subresource Integrity for the Rescue
One solution to the problem is Word Wide Web Consortium’s (W3C) new standard named Subresource Integrity (SRI). The intention of this standard is to protect third-party hosted website assets from tampering.
SRI involves a cryptographic hash, which is similar to SHA or MD5. The hash, unique to each asset, can be assigned to linked JavaScript and CSS stylesheet snippets like the following:
<script src=https://ajax.googleapis.com/ajax/libs/jquery/2.1.4/jquery.min.js integrity="sha256-ImQvICV38LovIsvla2zykaCTdEh1Z801Y+DSop91wMU=" crossorigin=anonymous></script>
The website visitors’ browser will compare the downloaded asset with the hash defined in the <script> tags. A mismatch implies that the intended JavaScript or CSS code has been tampered with. The browser will refuse to execute the code then to keep the website visitor secure.
What is the Issue with SRI then?
Although SRI is great, the main problem is the lack of widespread implementation. As of January 2016, only two sites out of the first ten from Alexa Top 500 implement SRI on their home page.
The other issue is the relatively immature tooling around SRI. The easiest way to generate SRI hashes for remote assets is to execute OpenSSL from the terminal, or use services such as srihash.org or the one at Report URI.
On the plus side, developers can also generate SRI hashes automatically. Plugins for popular build tools, like Grunt or Gulp, has started to appear lately for generating the hashes. WordPress features a plugin to bolt-on the hashes. Sadly, the popularity (download count) of these tools is still quite low compared to other popular, but unrelated plugins.
Scanning Sites for SRI Usage
To help the broad implementation of SRI, I have launched sritest.io. This service helps website owners and frontend developers alike to assess websites for Subresource Integrity usage.
The service is similar to Qualys’s SSL Server Test, where anyone can submit URLs to be scanned for SSL implementation. Another example is securityheaders.io. This one can assess any website for security-related HTTP headers, such as Content-Security-Policy or HTTP Strict Transport Security (HSTS).
On sritest.io, any website URL can be submitted to check whether JavaScript and CSS assets are protected by SRI hashes. The service generates a report, and grades the target from A to F based on the implementation level, as seen below.
The report also provides a detailed list of unprotected website assets.
Expected Benefits of sritest.io
The new service will hopefully boost the implementation of SRI. Sritest.io aims to help key people to implement the protection.
Sritest.io helps website owners to assess easily their sites without digging into the source code. Software developers can also submit production, staging or developer URLs to check the presence of SRI on their pages under development. Finally, penetration testers may also include the level of SRI implementation in their reports.
The reports can be passed around as necessary between these key people, as each SRI report is available on a unique URL.
Summary
Third-party hosted JavaScript and CSS assets are vulnerable to tampering. A cryptographic hashing technique named Subresource Integrity (SRI) has been developed to protect these assets from unexpected modifications. SRI protects visitors from browser exploits and other Internet sites from denial of service attacks.
A new service named sritest.io was born to foster the implementation of SRI. It allows website owners, frontend developers, and penetration testers can quickly evaluate any web page for SRI usage. The service is easy to use, and there is no need to read the HTML code.
Update (15/01/2016): Coverage on The Register
Update (18/01/2016): Coverage on SANS Internet Storm Center daily podcast
