Review Your Cross-Scripting Defenses with 2 New Google Tools
WordPress, the most popular content management system of all time, is used by 59.3 percent of all websites based on content management systems. As of Sept. 29, this represents 26.7 percent of all websites on the web. Being a modern, flexible and efficient content management system, WordPress is the tool of choice for many users around the world. Of course, popularity comes with a cost.
If you skip on security essentials, especially those outlined here, your WordPress installation could be impacted by one of the 5,237 WordPress core, plugin and theme vulnerabilities that we know about. It would be wise to run a search here, and see if your site is using one of the vulnerable plugins or themes.
One of the most common attacks is cross-site scripting. Sixty percent of payouts under Google’s Vulnerability Reward Program are awarded to researcher discovering XSS vulnerabilities. A search on the WordPress vulnerabilities database reveals that there are more than 1,000 instances of cross-site scripting.
However, the flexibility of CSP is also its biggest problem. In a recent Internet-wide study, Google analyzed 100 billion pages from over 1 billion hostnames and identified CSP deployments on 1,680,867 hosts with 26,011 unique CSP policies. Ninety-five percent of the deployed CSP policies were ineffective in protecting against XSS, mainly because of developers loading external scripts from domains exposed to patterns which allow attackers to bypass CSP protections, or developers implementing CSP policies which allow inline scripts (script-src ‘unsafe-inline’).
“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.” – CSP Is Dead, Long Live CSP! On the Insecurity of Whitelists and the Future of Content Security Policy, Google 2016
To assist developers in deploying effective CSPs, Google introduced two tools to evaluate the viability of particular CSP policies:
- CSP Evaluator: Gives developers a practical oversight of the effects of setting a policy.
- CSP Mitigator: A Chrome extension which will assist developer in CSP deployment. CSP Mitigator is a step forward in eliminating traditional CSP policies based on URL whitelists and implementing CSP3 policies based on cryptographic nonces. Supported by Chrome and Opera (and soon by Firefox), it’s time to benefit from the extra protection a nonces based policies provides.
In conclusion, there are two scenarios when a CSP policy is not necessary:
- For a static application, hosted on an individual domain.
- For applications known to be vulnerable to XSS. Reviewing the code or adopting a safer framework should do the trick.