Preventing XSS with Subresource Integrity
Today I got around to reading about a new W3C draft standard: Subresource Integrity – the standard is a product of efforts by Google, Dropbox, and Mozilla. To paraphrase the abstract, it defines a mechanism by which web browsers can check that their static files (js, css, images) haven’t been hijacked.
The idea is pretty basic: websites can now include a cryptographic checksum alongside their imports. For example,
<script src="http://mycdn.com/somescript.js" integrity="sha512-EkldfklaeoqpfjqlkfFkdqp4qkfp220fjksQovjfqklj="></script>
Browsers that support this will look at the checksum and calculate it for the static file. If they don’t match, no XHR request will be made for the resource.
GreatFire and Github were once DDoSed in an interesting way: China’s government injected malicious javascript into every Baidu visitor’s browser. This script sent traffic to the targets silently as users idled or browsed. This has since been dubbed China’s Great Cannon.
Baidu of course rejected the idea that they’d been hacked, which means their site javascript may have been compromised at the CDN level. Assuming this to be true, subresource integrity would have been useful, as this kind of mechanism would mitigate CDN hijacking.
The impact of this spec will be that site operators no longer have to blindly trust CDNs when it comes to static assets. This can also be implemented in plain javascript while the standard is not yet available.