eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Cross Site Scripting, commonly referred to as XSS, is among the most pervasive flaws on the web today.
With an XSS flaw, an attacker is potentially able to inject a script on a site from another domain without authorization. According to Google engineers Lukas Weichselbaum and Michele Spagnuolo, XSS is a big issue for Google, which is why it has invested in efforts to reduce the risk with a technology approach known as Content Security Policy (CSP). Weichselbaum and Spagnuolo detailed Google’s CSP efforts at the LocoMocoSec conference in Kauai, Hawaii, on April 17.
“It took Google 12-18 months to refactor their JavaScript to support Content Security Policy across roughly 3/4 of their properties,” LocoMocoSec conference founder Jeremiah Grossman wrote in a Twitter message. “Now, they’ve created new development frameworks that automatically produce code with a CSP that’s invisible to the developer.”
Content Security Policy is not a new idea as developers and browser vendors, including Mozilla, have been implementing CSP in various forms since at least 2010. In its most basic form, CSP can be used by a website or application developer to declare a policy to prevent injected scripts from running if not authorized.
Google is currently enforcing CSP across more than 80 Google-owned domains and over 160 services, representing approximately 62 percent of all outgoing Google traffic. According to Weichselbaum and Spagnuolo, in 2018 more than 60 percent of all XSS attempts were blocked by Google’s CSP efforts.
Taking a Nonce-Based CSP Approach
What Google discovered during its deployment of CSP over the years is that not all approaches have the same impact. One approach for CSP is to use a whitelist, which explicitly lists which domains can inject scripts. Google’s research found that 95% of the web’s whitelist-based CSPs are bypassable.
The approach that Weichselbaum and Spagnuolo advocate is to have a nonce-based CSP. A nonce is an arbitrary value used to help make the security policy more dynamic. For example, a nonce-based CSP will only enable the execution of scripts with the correct nonce attribute. Weichselbaum and Spagnuolo also detailed how different nonce-based parameters can be used to increase the coverage for XSS risks.
Beyond just using the nonce approach, Google is also making use of new features in CSP. CSP 3 is the newest iteration of CSP and introduces several additional attributes that can be used to further reduce the risks of XSS. Among them, is the ‘script-src-elem’ tag that applies to all script requests and inline script blocks, providing a new mechanism for more granular control.
CSP Reporting
Organizations don’t have to just guess about the right CSP policy either. The CSP model provides an integrated reporting capability that can help organizations understand why something get blocked.
For example, adding the ‘report-sample’ tag to the script-src directive will provide a report in which inline script violation will also contain a sample of the blocked expression, allowing organizations to identify which script was blocked.
To help organizations better utilize and understand CSP, Google has created a number of resources:
- CSP Evaluator—CSP Evaluator allows developers and security experts to check whether a Content Security Policy serves as a strong mitigation against XSS attacks.
- CSP Guide—Google-written guide on adopting CSP.
While CSP can be an effective tool mitigating the risk of XSS, it should only be one part of an organization’s larger security efforts to improve code quality and overall security.
“CSP is a defense-in-depth mechanism. It’s meant to protect the user when primary security mechanisms (e.g. escaping) fail,” Weichselbaum and Spagnuolo wrote in their LocoMocoSec presentation. “It’s not an excuse to not fix underlying bugs.”
Sean Michael Kerner is a senior editor at eWEEK and InternetNews.com. Follow him on Twitter @TechJournalist.