Defending against Malicious Activity in an Unmodified Browser
Today we present Stickler, a theoretical platform for protecting the integrity of a web application from a faulty CDN.
Benefits and Risks of CDNs
A website publisher may choose to employ a CDN for a variety of reasons:
- CDNs can serve the bulk of a site’s assets from a long lived cache, dramatically reducing load on the publisher’s servers.
- CDNs maintain edge servers around the world, so they can service cached content to clients with relatively low end-to-end latency.
- CDNs allow publishers to maintain availability in the face of a rapid spike in traffic (i.e., a “flash crowd”)
Often, CDN-cached assets are served from a CDN controlled domain (e.g. example.com). However, publishers may choose to have the CDN cache content on a particular subdomain (e.g., procdn.nytimes.com). Alternatively, a publisher may point the DNS records for her site to the CDN’s servers allowing the CDN to serve as a front-end proxy for all requests. Either way, once the website has directed the end user to retrieve content from a CDN, it is difficult for a user’s browser to verify the authenticity of that content.
Threat Model and Security Goals
Stickler is a model to secure websites and protect them against attacks in case a CDN is compromised. With Stickler, publishers can realize the scalability and availability benefits of a CDN without the integrity risks (and thus confidentiality risks) of serving assets from a third-party server.
Stickler separates authenticity of the connection from authenticity of the content by signing content directly with a private key the site owner never has to share with the CDN. In fact, if the site consists entirely of static content, even the publisher’s own web servers need not hold a copy of the publisher’s private signing key. End users can verify all site content independently of how they receive the pre-signed content, whether directly from the web site’s servers, through a CDN provider, or even via a peer-to-peer CDN like CoralCDN. Crucially, Stickler achieves these guarantees without requiring modifications to the browser. Stickler is an effective short-term solution for browsers that will eventually support W3C Subresource Integrity mechanism (SRI) and is a useful long-term solution for browsers and platforms (e.g., old smartphones) that may never support SRI.
Stickler does have some limitations: it requires publishers to sign every static asset, imposes some performance penalty on the user, and prevents the CDN from optimizing assets to their full potential.
A fully Stickler-protected demonstration website is sticklerjs.org.
As stated earlier, one of the limitations of Stickler is the inherent performance penalty it poses. While the performance with and without Stickler on Chrome is comparable, Stickler imposes roughly a 5x performance penalty when using Firefox when the number of assets on the page is large (see Figure 3). Whether or not this overhead is acceptable will depend on the particular security requirements of the application, but we expect that for especially sensitive sites (e.g., a health data site), publishers will be willing to pay a performance cost for a security benefit.
Fig: compares the time it takes to render a Stickler-protected page with the time it takes to load an unprotected static HTML page as the number of assets on the page varies.
Check out the recently published technical paper for for a more in-depth discussion. Stickler is joint work with Amit Levy and Henry Corrigan-Gibbs and was presented at the 2015 IEEE Web 2.0 Security and Privacy workshop.
By Dan Boneh, Professor of Computer Science and Co-director of the Security Lab at Stanford University