Google Data

Posted by Artur Janc, Michele Spagnuolo, Lukas Weichselbaum, and David Ross, Information Security Engineers

Cross-site scripting — the ability to inject undesired scripts into a trusted web application — has been one of the top web security vulnerabilities for over a decade. Just in the past 2 years Google has awarded researchers over $1.2 million for reporting XSS bugs in our applications via the Vulnerability Reward Program. Modern web technologies such as strict contextual auto-escaping help developers avoid mistakes which lead to XSS, and automated scanners can catch classes of vulnerabilities during the testing process. However, in complex applications bugs inevitably slip by, allowing attacks ranging from harmless pranks to malicious targeted exploits.

Content Security Policy (CSP) is a mechanism designed to step in precisely when such bugs happen; it provides developers the ability to restrict which scripts are allowed to execute so that even if attackers can inject HTML into a vulnerable page, they should not be able to load malicious scripts and other types of resources. CSP is a flexible tool allowing developers to set a wide range of policies; it is supported — though not always in its entirety — by all modern browsers.

However, 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. In a recent Internet-wide study we analyzed over 1 billion domains and found that 95% of deployed CSP policies are ineffective as a protection against XSS. One of the underlying reasons is that 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. We believe it's important to improve this, and help the web ecosystem make full use of the potential of CSP.

Towards safer CSP policies
To help developers craft policies which meaningfully protect their applications, today we’re releasing the CSP Evaluator, a tool to visualize the effect of setting a policy and detect subtle misconfigurations. CSP Evaluator is used by security engineers and developers at Google to make sure policies provide a meaningful security benefit and cannot be subverted by attackers.
Even with such a helpful tool, 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. Here’s where the idea of a nonce-based CSP policy comes in. Instead of whitelisting all allowed script locations, 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:

Content-Security-Policy: script-src 'nonce-random123'





With 'strict-dynamic', a part of the upcoming CSP3 specification already supported by Chrome and Opera (and coming soon to Firefox), adopting such policies in complex, modern applications becomes much easier. Developers can now set a single, short policy such as:

script-src 'nonce-random123' 'strict-dynamic'; object-src 'none'

and make sure that all static elements contain a matching nonce 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. This approach allows setting policies which are backwards-compatible with all CSP-aware browsers, and plays well with applications which already use a traditional CSP policy; it also simplifies the process of adopting CSP and doesn’t require changing the policy as the application evolves.

Adopting strict CSP
In the past months we’ve deployed this approach in several large Google applications, including Cloud Console, Photos, History, Careers Search, Maps Timeline, Cultural Institute and are working on many more. We believe this approach can also help other developers so today we’re publishing documentation discussing the best strategies for implementing CSP, including an overview of the benefits of CSP, sample policies, and examples of common code changes.

Further, today we’re releasing CSP Mitigator, a Chrome extension that helps developers review an application for compatibility with nonce-based CSP. 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. This includes identifying scripts which do not have the correct nonce attribute, detecting inline event handlers, javascript: URIs, and several other more subtle patterns which might need attention.
As with the CSP Evaluator, we use the extension with our applications to help speed up the process of adopting nonce-based CSP policies nonce-based policies across Google.

Encouraging broader use of strict CSP
Finally, today we’re including CSP adoption efforts in the scope of the Patch Reward Program; proactive work to help make popular open-source web frameworks compatible with nonce-based CSP can qualify for rewards (but please read the program rules and CSP refactoring tips first). We hope that increased attention to this area will also encourage researchers to find new, creative ways to circumvent CSP restrictions, and help us further improve the mechanism so that we can better protect Internet users from web threats.

To reach out to us, email [email protected].