Cross-site scripting attacks – the ability to inject unauthorized scripts into web applications – is pervasive, and even though developers have plenty of tools and technologies that can detect and fix XSS flaws, the attacks still keep coming.
Google’s latest developer tools, CSP Evaluator and CSP Mitigator, tackle the XSS problem from a different angle, by shoring up web application defenses to make it harder to execute those malicious scripts.
XSS is among the most common security threats plaguing web applications, and aren’t always the result of sloppy or lazy coding. Developers can avoid mistakes which lead to XSS with modern web technologies such as strict contextual auto-escaping or use automated scanners to catch vulnerabilities during testing.
“However, in complex applications, bugs inevitably slip by, allowing attacks ranging from harmless pranks to malicious targeted exploits,” Google security engineers Artur Janc, Michele Spagnuolo., Lukas Weichselbaum, and David Ross wrote in a blog post announcing CSP Evaluator and CSP Mitigator.
The new tools help developers craft and deploy strict Content Security Policy rules, which defines what content should and can be loaded by a browser, to restrict scripts allowed to execute on the page. In XSS attacks, the attackers bypass same origin policies to serve up malicious scripts to unsuspecting users. A strict CSP is designed to prevent attackers from loading malicious scripts and other resources even if they manage to inject HTML into a vulnerable page.
CSP Evaluator lets developers visualize how content policies affect application security and expose potential misconfigurations. The tool can be paired with a nonce-based CSP policy, which skips whitelisting in favor of unpredictable single-use tokens, to significantly reduce the likelihood of XSS attacks bypassing CSP. With the nonce-based CSP policy, developers don’t have to whitelist all allowed script locations.
“Building a safe script whitelist for a complex application is often all but impossible due to the number of popular domains with resources that allow CSP to be bypassed,” the engineers wrote. “It’s often simpler to modify the application to prove that a script is trusted by the developer by giving it a nonce — an unpredictable, single-use token which has to match a value set in the policy.”
Chrome and Opera already supports “strict-dynamic” from the upcoming CSP3 specification, so developers can just set a single short policy to use the nonce and make sure all acceptable script elements contain that matching attribute.
“In many cases this is all that’s needed to enjoy added protection against XSS since ‘strict-dynamic’ will take care of loading any trusted scripts added at runtime,” the engineers said. Even as the application evolves, the policy doesn’t have to change, making it backwards-compatible with other CSP-aware browsers and applications already using a traditional CSP policy.
The fact that developers can verify the policies are enabled and configured correctly with CSP Evaluator is significant, considering how it easy it is to make a mistake when crafting the policy. In a recent analysis of 1 billion domains, Google found that 95 percent of deployed CSP policies were ineffective as a protection against XSS. Out of the 15 domains most commonly whitelisted by developers for loading external scripts, as many as 14 expose patterns which allow attackers to bypass CSP protections, the company found.
Even more damning, the analysis found that “99.34 percent of hosts with CSP use policies that offer no benefit against XSS.”
“The flexibility of CSP also leads to its biggest problem: it makes it easy to set policies which appear to work, but offer no real security benefit,” the engineers wrote.
Google’s security engineers currently use CSP Evaluator for its Cloud Console, Photos, History, Careers Search, Maps Timeline, and Cultural Institute, and plans to expand the list to include other applications. With the tool now public, developers can make it really hard for attackers to find gaps in CSP and bypassing the protections to launch XSS attacks.
The second developer tool CSP Mitigator is a Chrome extension which checks the application’s compatibility with nonce-based security policies. The extension identifies scripts which do not have the correct nonce attribute. It also detects inline event handlers, javascript: URLs, and other subtle patterns.
“The extension can be enabled for any URL prefix and will collect data about any programming patterns that need to be refactored to support CSP,” Google said.
While Evaluator helps developers craft policies, Mitigator addresses the other end of the security spectrum by helping administrators apply custom policies. CSP Mitigator highlights parts that may break, giving administrators an idea of how enabling CSP would impact the application.
As applications get even more complex, XSS continues to be a serious web threat. While developers should continue to look for, and fix, XSS flaws in their code on a regular basis, both developers and administrators should make sure they take advantage of the protections offered by CSP and use them correctly.
“We believe it’s important to improve this, and help the web ecosystem make full use of the potential of CSP,” the Google engineers wrote.
