Errata for SRI functionality from our paper "Who's Hosting the Block Party? Studying Third-Party Blockage of CSP and SRI"
Jun 15, 2021
We have been made aware (kudos to Frederik Braun, also the author of the spec) that our description of how SRI works in our NDSS paper was incorrect. In this blog post, we would like to clarify our incorrect description and provide thoughts on whether or not this changes the conclusions drawn in the paper.
How does SRI really work?
Contrary to our depiction throughout the paper, SRI allows for the specification of multiple hash values within one single integrity attribute, as shown in the following code snippet.
<html>
<body>
<script src='/console.js' integrity="sha512-shRLH9ogWlVqs+a/Wcc4wHmw+XRYyLJpDRBtMP89YS/b96HiTLXDhnuv8z3vfiSBsBDWx6WdAtdcfZO/WLLLOQ== sha512-RwKyDk+Hcnqtn0q4pHDOb6EU2SDRPPiQT/7DsNtUcENthqX5kjstCeehjdSYGtM5b2Cvll//3y56V7J7g84KwA=="></script>
<!-- console.js could contain either ```console.log(1)\n``` or ```console.log(2)\n``` as those match the specified hashes -->
</body>
</html>
This means that as long as the set of scripts that the application wants to include remains stable over time, SRI could be used to prevent malicious alterations of third-party scripts (assuming the third-party origin CORS-enables these resources).
How does this change our results?
In Section VII.A, we reason about the feasibility of deploying SRI in light of the rapidly changing landscape of inclusions in modern Web applications. In particular, the use cases that we depict (e.g., changing timestamps or version numbers in subsequently included scripts) remain challenging even if we can specify an arbitrary amount of hashes per script (compilation timestamps and identifier renamings are intransparent to developers; version number changes might be guessable, yet must be monitored in case of irregularities). Yet, having dynamic scripts can no longer be equated with a Web application being incompatible with SRI for such dynamic scripts, as was alluded to in the paper.
In Section VII.A.1, we designed a mechanism that iteratively tries possible script hashes, thus allows us to specify multiple hashes per script location. As SRI already allows for this behavior, such a mechanism is no longer required, yet, the conclusions drawn from the remainder of this paragraph remain unchanged.
Similarly, results from section VII.A.2 remain sound as we analyze real-world SRI usage.
Conclusion
To conclude, the results drawn from our observations do not change drastically (mainly due to the thought experiment of what would happen if we were able to specify multiple hashes in VII.A.1). Nonetheless, I have learned a valuable lesson in that it is better to double-check in the standard rather than assuming that I know how a mechanism works. Again thanks to Frederik Braun for reaching out and clarifying our misconception!
Post by Marius Steffens