We are glad to announce that our paper Who’s Hosting the Block Party? Studying Third-Party Blockage of CSP and SRI was accepted to NDSS 21. This post constitutes a brief summary of our main findings and insights gained during the project. For more information and pointers to related works and references, please take a look at the paper.

Brief Summary

In this work, we investigated to what extent third parties contribute to the lacking deployment of the Content Security Policy (which is a mitigation against XSS and unwanted script inclusions) and Subresource Integrity (pins specific versions of libraries included from third-party servers). If third parties contribute code that is incompatible with such mechanisms, the developer can either accept that they will not be able to deploy a security mechanism(since this would break the functionality), or they need to replace a particular third-party with an equivalent one that fulfills the business needs, and is compatible with security mechanisms. However, if the first party is reliant on those incompatible parties’ code, there is little incentive for them to start the process of making their own codebase compliant.

We can divide our work into roughly three parts:

1. How can we accurately differentiate between first and third-party scripts, but also how can we distinguish if two third party hosts are operated by the same entity?
2. How exactly can third-party behavior impact the ability of a site to deploy CSP? How prevalent is this pattern?
3. Can first-party developers make use of SRI to restrict all of their external inclusions?

Same-Party or not?

First party CDN’s (e.g., facebook.com and fbcdn.net), but also multiple eTLD+1’s owned by the same entity (e.g., alibaba.com and alipay.com) are prevalent throughout top sites. This observation shows that we cannot merely rely on the eTLD+1 to figure out if any given hostname should be considered as the same entity as the first party or to distinguish among different third-party entities. We introduce the notion of an extended Same Party, which we approximate using co-occurrence patterns that we extract from inclusion relations collected in a longitudinal experiment over the course of twelve weeks from 8,041 of the top 10,000 sites, which we were able to analyze. We manually vet those relations and can identify 1,146 same party relations.

Impact on CSP

We can analyze the impact which third parties have on three aspects of CSP, i.e., the feasibility of host-based allowlists, the necessity of unsafe compatibility modes(i.e., unsafe-inline, unsafe-eval), and the impact on strict-dynamic based policies.

Stability of Allowlists

We are able to show that the continuous influx of new hosts necessitates rapid allowlisting from the first party. Otherwise, new inclusions from third-party scripts will lead to functionality breakage. Additionally, many of our seen hosts also vanish from being included in pages, such that leaving them in the allowlist would violate the principle of least privilege, exposing the application to a needlessly large attack surface. More than half of the updates that need to be done to the allowlist(for additions alone) during our analysis period stem from new inclusions from third-party resources. Contrarily, throughout our experiment, 74% of sites would need to remove hosts due to third parties no longer including resources from those hosts, to keep their allowlist as strict as possible.

We can conclude that third parties contribute to the hardships that first-party developers face when keeping such a host-based allowlist up to date.

Impact on Compatibility modes

Next, we analyze to what extent first-party developers would need to deploy a CSP with either unsafe-inline or unsafe-eval due to the behavior introduced by third parties. A total of 6,041/8,041 (75%) require unsafe-inline, and 4,911/8,041 (61%) require unsafe-eval. Additionally, 4,573 and 2,943 have multiple third parties that jointly contribute incompatible code, which means that all involved stakeholders need to contribute to the first party’s security jointly. A categorization of the incompatible hosts unveils that sites labeled as advertising related are the biggest culprits, yet, even if we imagine a world where all ad-related hosts would suddenly only contribute compliant code, 6,213 (77%) sites would still be incompatible with unsafe-*-free policies due to third-party code unrelated to ads.

	unsafe-inline	unsafe-eval
mandated by any	7,667	6,334
mandate by first party	7,643	4,424
mandated by third party	6,041	4,911
mandated by multiple third parties	4,573	2,943

Impact on strict-dynamic

strict-dynamic was envisioned as a means to ease CSP deployments for the first party, as it allows trusted scripts (e.g., via a nonce) to include arbitrary other scripts programmatically. Importantly, constructs such as document.write are not programmatically adding scripts; rather, they burden the parser with the addition of such scripts. Also, inline events (e.g., written via document.write or added via setAttribute to the respective event) are not supported by strict-dynamic without the usage of unsafe-hashes (yet another compatibility mode). If we only look at the inclusion of additional scripts issued by the parser, this leaves 1,414 of our 8,041 sites incompatible due to third parties assuming that they do not want to break functionality. Concerning the inline events, 5,977 sites have third parties that write inline event handlers, rendering strict-dynamic inapplicable without breakage. Overall, only 1,894 of our 8,041 (23,5%) sites could make use of this mechanism as no currently included party conducts incompatible inclusions of further scripts.

Impact on SRI

We are able to show that the contents of third-party inclusions change rapidly over the course of a single crawl. We found instances, in particular for libraries of large providers, that such changes are often minuscule and do not impact the library’s functionality, e.g., changes in comments indicating the JIT compile time of the library. Even though such providers might have an incentive to make their libraries incompatible with SRI (to allow for seamless updates), this robs the first-party from protecting against compromise of the third-party servers without hosting a local version (increasing load on their own servers as well as reducing responsiveness if those resources were already cached in the browser of their users).

Conclusion

We were able to show that the deployment of CSP and SRI cannot solely be burdened on the shoulders of first-party developers, as any such undertaking requires the support of all the involved stakeholders (be it direct business partners or such entities that have no direct business relationship and are only ever included via third parties). This leaves third parties in a unique position, where a shift of their coding practices will have an immense effect on the Web’s security. Unfortunately, as it stands now, they are contributing to the lacking adoption of security mechanisms. Orthogonally, recent proposals of browser vendors hint at possibilities of hiding dangerous features (such as SharedArrayBuffer) behind the deployment of sane security mechanisms(e.g., sane CSP). While this seems to be an exciting approach to increase the adoption of sane defaults, we want to highlight that first-party developers might not be able to adapt their site to those requirements. Contrary, the third party that contributes incompatible code faces no repercussions, as the code that they deliver to others may not even run in their own sites (thus enabling them to use those features on their own site).

We open-sourced our data collection methods as part of SMURF, which we envision helps developers understand the dangerous practices employed by their dependencies.