========= Deployed CSP Analysis =========

1. "Notably though, virtually all papers have focused on CSP as a means to restrict content and have treated its newly added features (such as TLS enforcement and framing control) as side notes"
2. Among the insights, we find that 56% (251/449) of Web sites that test CSP for content restriction with report-only, presumably due to its complexity, refrain from ever enforcing any policy
3. Moreover, we outline the unexpected interactions between CSP and DNS and discover that over 13% of sites attempting to control script resources whitelisted domains that have expired, contain obvious typos, or resolve to private IPs
4. In particular, we document the increase in adoption of TLS enforcement and how the security mechanism is used in practice for utility purposes.
5. Content Security Policy (CSP) is a browser-enforced security mechanism first proposed in 2010 by Stamm et al.
6. "CSPs can be specified inside the Content-Security-Policy header or by including them in meta tags inside an HTML head section."
7. "CSP provides directives to bind content types to sets of source expressions, regular-expression-like constructs used to represent the Web origins from which resources of a given type may be included"
8. "The original CSP design proved to be an inflexible security mechanism, since it required the removal of all the inline scripts and event handlers to actually provide any security benefit; hence, its adoption initially lagged behind other security headers [51]. To remedy this, the second version of CSP introduced hashes and nonces to whitelist selected inline script elements. The former allow one to whitelist inline scripts matching a given hash, whereas the latter enable execution of script tags carrying those nonces."
9. Since 2016, the third and latest version of CSP further aims to ease deployment through the strict-dynamic source expression, used to propagate trust to scripts loaded by other scripts whitelisted using a valid hash/nonce
10. "The figure does not include the CSP adoption from 2012 to 2014, since only 8 different sites deployed CSP before 2014 "
11. "First, even though CSP offers the report-only mode to enable developers to experiment with policies before deployment, this mode is not nearly as popular as the enforcement mode. This means that most developers are rolling out policies without having a chance to test them on their user base. We suspect that this is one of the main reasons why CSPs in the wild are so relaxed since they have not been appropriately evaluated and the developers eventually opted for utility over security"
12. Since CSP is one of many security mechanisms deployed by servers and enforced by browsers (like HSTS) one may think that similar to other mechanisms, once a policy is curated, that policy can be deployed and used for a prolonged period."Unfortunately, CSP — especially for its original use case of script content restriction — is way more complicated than other security mechanisms and requires constant maintenance to ensure that the appropriate sources are whitelisted so that the site remains operational and secure."
13. While we can only speculate about the exact reason for this trend, we opine that it is likely due to event handlers which cannot be whitelisted with hashes or nonces. Checking merely the start pages for the 378 sites which deployed unsafe-inline in December 2018, 180 (48%) of them carried event handlers.
14. "Whitelisting an entire scheme (such as https) and allowing unsafe-inline may result in short policies (in terms of the number of entries) which are, however, still more vulnerable than explicitly trusting hundreds of remote third parties."
15. "Despite the lack of zone files covering the full duration of our dataset, we were still able to find 9 cases of domains expiring after being added to a whitelist and 7 domains which were not registered at all during the periods they appeared in CSP whitelists."
16. "A typo entered in the whitelist permits the loading of content from an unintended domain. The typo domain may not be registered, in which case it can be bought and abused as above. If the typo domain is already owned, there is still the potential for the current owner to discover the issue and abuse the misplaced trust. Compared to traditional typosquatting where each end-user needs to mistype the domain, typos in CSPs involve a one-time mistake which results in a persistent threat."
17. "To find typos we use the fat-finger typosquatting models of Wang et al. [48] to generate a list of domains that may have been the intended ones"
18. "As the table indicates, 50/373 (13%) sites using CSP whitelists trusted at least one abusable domain."
19. "Even though Airbnb was an early adopter of CSP and made significant efforts to secure their site, they had to often effectively disable their policies for long periods of time. These gaps could have been abused by attackers to launch attacks that would not normally be possible with Airbnb’s CSP. Moreover, while they finally managed to curate a whitelist of 33 sites, it took them multiple years from when they started experimenting with CSP to arrive at this final policy."
20. "The HSTS header is set to ensure that once a site has been visited over HTTPS, it cannot be loaded over HTTP until a specified timeout occured"
21. "In particular, CSP was extended to better integrate with the Mixed Content specification, a security policy implemented by all modern browsers which regulates the use of HTTP resources in HTTPS pages"
22. "The protection offered by XFO is coarse-grained both because of the small number of configuration options, but also because of Google Chrome’s decision (shared by all Chrome-based browsers) to not support the ALLOW-FROM directive"
23. "We find that starting from 2015 when a meaningful number of sites adopted frame-ancestors (shown as CSP-FA), at least 50% of them required the flexibility of CSP. For those, we find that the most common pattern is whitelisting all origins from the same site (104 of 321 in 2018)."
24. "CSP’s initial purpose was to restrict the inclusion of content into a pages"
25. "Hence, it appears that while content restriction is clearly known as a goal of CSP, most sites are unable to deploy it due to its complexity."
26. "On the flip side, most policies make use of unsafe-inline, which makes them trivially bypassable by XSS"
27. "Of the handful of sites which managed to actually deploy a restricted whitelist, both the case studies and the feedback from our notification indicated that curating such a list takes months or even years. Hence, the overall effort of setting up and maintaining a secure policy seems unbearable to all but the biggest players"
28. "As an example, google.com stopped using strict-dynamic on July 17th, 2018 even though Google engineers originally proposed the new directive [50]. Given the insights shared by the Google team in a recent presentation"
29. "Moreover, upgrade-insecure-requests allows sites to seamlessly migrate to HTTPS by upgrading all URLs inflight"
30. "CSP is becoming a highly complex, generic Security Policy. This perceived complexity was also echoed in the notification responses, with operators explicitly naming complexity as the hurdle towards CSP deployment"
31. "In practice though, we observed up to 3,344 different event handlers on a single page. While the median is only at around 5, any update to the event handlers (for all pages!) needs to be propagated to the CSP header"
32. "Our work improves upon previous analyses of CSP in different ways. First, we present the first analysis of the security impact of typos and expired domains on CSPs, complementing previous findings of the insecurity of whitelists"
33. ""
34. ""
35. ""
36. ""
37. ""
38. ""
39. ""
40. ""
41. ""
42. ""
43. ""
44. ""
45. ""
46. ""
47. ""
48. ""
49. ""
50. ""
51. ""
52. ""
53. ""
54. ""
55. ""
56. ""
57. ""
58. ""