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.
Cross-site scripting is a bug, typically found in web applications, which allows the addition of malicious JavaScript code onto HTML pages displayed to your visitors. Once executed by the victim’s browser, this code will alter the behavior or appearance of the website, potentially compromising private data, or will perform actions on behalf of the user. Some of the results of a successful XSS attack are watering hole attacks, malicious advertising campaigns and drive-by attacks. The latter are particularly dangerous since the mere act of opening the affected web page may have severe consequences for your user. Extensive documentation on the vulnerability can be found here.
To mitigate an XSS attack, web developers are implementing content security policies. Initially named Content Restrictions, CSP is a computer security standard, currently a Candidate Recommendation of the W3C working group on Web Application Security, supported by most modern web browsers. Firefox 4 was the first browser to adopt the standard. CSP provides a standard method for web developers to declare sanctioned origins of content that browsers are allowed to load on a particular website. CSP is a flexible tool allowing developers to implement content policies regarding CSS, JavaScript, web workers, fonts, images and many other HTML5 features.
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.
