To hash or not to hash: A security assessment of CSP’s unsafe-hashes expression

More and more people use the Web on a daily basis. We use it for communicating, doing bank transactions, and entertainment. This popularity of the Web has made it one of the main targets of attacks, most prominently Cross-Site Scripting (XSS). To mitigate the effect of those attacks, the prevalence of the Content Security Policy (CSP) is increasing. Such a policy allows developers to control the content that should be allowed on their Web applications precisely. Because this content includes JavaScript (via the script-src directive), it can also be an effective tool to mitigate the damage of markup injections such as XSS. Developers can specify fine-grained policies for scripts to only allow trusted third parties and disallow the usage of functions like eval and its derivatives that directly execute strings as code. As the whole Web is still evolving, so is CSP. The experimental source-expression unsafe-hashes aims to ease the adoption of secure CSPs, by allowing trusted scripts to be used as inline event handlers for HTML tags, which is currently only possible by blindly allowing all inline scripts to be executed. Our goal is to analyze if this expression is able to improve the security of a Web application or if it mainly provides a false sense of security because it still enables attackers to bypass the CSP. We built an automatic crawler utilizing dynamic JavaScript analysis using taint tracking and forced execution to detect security vulnerabilities of inline event handlers. This crawler visited 753,715 unique URLs from the Alexa Top 1,000 domains up to a maximum of 500 URLs per domain. We collected a total of 735,105 individual event handlers, where 443 of those had attribute values that flow into a dangerous JavaScript sink. Our manual analysis of the event handlers revealed that 370 of those handlers on 34 different domains are still vulnerable in presence of a CSP that contains the unsafe-hashes expression. We show that attackers can exploit these flows with only partial injections, such as adding new attributes to existing tags in most cases and discuss the impact of our findings on the future of the CSP standard.