As we make plans this New Year’s Eve to bid farewell to 2016, we’re continually beleaguered by headlines concerning cyber attacks. The stories range from the latest allegations of Russian malware found on a Vermont utility’s computer, to leaked e-mails ahead of the U.S. Presidential Election, and you could even include Apple’s refusal earlier this year to furnish U.S. Government law enforcement agencies with a backdoor they insisted upon to enable encrypted data access. Cybersecurity must go down as one of the leading themes of 2016, and likely will go on to concern us for years to come.
That’s why we should take a moment to recognize a most important development within the information security community during 2016: the publication of the Subresource Integrity (SRI) recommendation by the W3C. What’s that? You had not heard of subresource integrity before now? You wouldn’t be alone in that regard, but let me explain how this new standard remedies some long-troubling pitfalls inherent to the Internet.
Where the Padlock Doesn’t Protect You
Many resources constitute each and every Web page you browse or see on your smartphone: text, fonts, images, videos, stylesheets and scripts that define behavior. Script provides the interactivity that makes the Internet such a wonderful experience, but they can also hide obfuscated code with malicious intent to abscond your personal information (or worse). Each of the other resource types can likewise exploit vulnerabilities on our devices or their software, if cleverly applied.
It’s not necessarily that you’re wandering the Internet bereft of any protection. We all learn from an early age (I hope) to only carry out e-commerce transactions on sites over a secure connection. Achieved using the TLS protocol (often evidenced by the “https:” scheme you see in your browser’s address bar, frequently accompanied by a secure padlock icon or comforting green background color), they conceal the data transmitted through intermediate network nodes from prying eyes. Furthermore, we trust the X.509 certificates issued by Certificate Authorities (i.e., Verisign, GeoTrust, etc.) to vouch for the identity of a Web site’s owner. These tried-and-true precautions have long helped reassure us of the legitimacy of our communications partner on the other end of the line.
However, dangers remain wherever a hacker can introduce malevolent changes into external resources. These are not always hosted by the publisher or the provider of an online service with which you believe you’re dealing. The Internet is made-up of an entire ecosystem of carriers, subcontracted services delivered through third-parties, content-delivery networks (CDNs) such as Akamai designed to expedite delivery and local caching of the resources you see.
If a hacker can release a resource he has modified with malicious code into a CDN, or alternately poison the Domain Name Servers (DNS) that our devices depend upon to lookup IP addresses into user-friendly host names by offering a faster DNS lookup that tricks your browser into contacting their “evil” edge server when downloading resources, then he can present that to you. How can publishers ensure users obtain a bonafide copy of a resource that they’ve endorsed as safe in this dangerous network wilderness?
Verify What Was Downloaded Is What Was Intended
Enter subresource integrity for external script and link tags on Web pages. Modern browsers (such as Google Chrome and Mozilla Firefox) support SRI to automatically verify that the copy of a resource downloaded matches what had been published.
SRI functions through the addition of an integrity attribute on these tags, which specify one or more cryptographic hashes (such as SHA-256 and MD-5). A cryptographic hash is a essentially a really big number (256-bits, in the case of SHA-256) which is based upon the content of a resource, computed in such a way that the odds are astronomically against any 2 different resources yielding the same number (what is called hash collision; good cryptographic hash functions are resistant to hash collisions).
<script src="https://cdn.example.com/jquery-1.13.1.js"
integrity="sha512-Q2bFTOhEALkN8hOms2FKTDLy7eugP2zFZ1T8LCvX42Fp3WoNr3bjZSAHeOsHrbV1Fu9/A0EzCinRE7Af1ofPrw=="
crossorigin="anonymous">
</script>In this example of a script tag that supports verifying the integrity of the downloaded JQuery script library you see the Base64-encoded SHA-512 hash. This is something that the publisher pre-calculates and renders into the HTML document your browser or smartphone receives. The browser software or mobile app you’re using then looks at the contents of the “jquery-1.13.1,js” resource it’s downloaded from cdn.example.com, and recalculates it’s hash using the standard SHA-512 hash function. If the Base64-encoding of the hash it gets is (wait for it):
Q2bFTOhEALkN8hOms2FKTDLy7eugP2zFZ1T8LCvX42Fp3WoNr3bjZSAHeOsHrbV1Fu9/A0EzCinRE7Af1ofPrw==Then it confirms that the resource has not been tampered with, relative to the version the publisher originally approved for availability through the CDN.
But Can’t a Clever Edit Produce the Same Hash?
A second characteristic of these hashes is that the most minor change in the content (even to as little as a single bit, for example, changing the case of one character from lowercase ‘a’ to uppercase ‘A’) will produce a hash that is significantly different. The new hash won’t look anything like the old hash, even though the difference in the modified version of the resource is hard to discern. This makes altering the content without detection nearly impossible for hackers. SRI-supporting browsers can reject resources as untrustworthy when the hash for what was downloaded doesn’t exactly match what the publisher specifies through the new integrity attribute.
But Can’t a Hash Function Vulnerability Weaken Protection?
You are probably thinking about how cryptoanalysts found flaws in some older hash functions like MD-5 and SHA-1 that render them vulnerable to a cleverly-crafted modification that produces a hash collision. It’s true that Dutch researchers broke MD-5 hashes to produce fake certificates through collisions, allowing attackers to spoof otherwise trusted publishers like Google or Microsoft. As long as there is only one hash used, it’s conceivable a future vulnerability in a modern cryptographic hash could weaken protection.
Fortunately, the W3C includes support in the integrity attribute for listing multiple hash functions and their corresponding hash computations. You can for example specify both a SHA-384 and SHA-512 hash, simply separating the specifications by a space. An exploit that breaks SHA-384 is extraordinarily unlikely to also affect SHA-512, so you’re dealing with astronomically-small probabilities that any clever edit exists which would fool both hash functions. The W3C recommendation requires SRI-supporting browsers to choose what they consider the strongest cryptographic hash algorithm from among those listed (and encourages browser manufacturers to regularly update their logic for determining which hashes are the strongest as the security landscape evolves over time.) Consequently, so long as you specify at least two independent hash functions for subresource integrity checks, you’ll sleep more soundly.
Let’s Toast Subresource Integrity
The finalization of the Subresource Integrity recommendation will likely go down as one of 2016’s greatest contributions to our ongoing cyberdefense efforts. All Web sites, mobile apps and browser vendors should soon adopt this new standard to protect consumers from resource tampering attacks, if they haven’t done so already. Our New Year’s resolution for 2017 should include increasing our efforts when it comes to Internet security, and demanding that the organizations we do business with take similar steps. When you’re watching the fireworks sparkle in the night sky overhead, please remember to include the W3C and their development of SRI this year in your champagne toasts.
Have a happy and safe New Year!