WordPress's flexibility and ease of use have made it incredibly popular. But that popularity has come with a price - WordPress sites are a huge target for hackers.
In this interview Miriam Schwab, founder and CEO of WordPress firm Strattic, explains how content security policies can help protect WordPress sites against cross-site scripting attacks.
You can find part two of our interview with Miriam Schwab here.
Miriam can you please introduce yourself a little?
MS: I'm originally from Toronto, Canada. I've been living in Jerusalem, Israel for the last 22 years more or less. I got into the world of WordPress about twelve, thirteen years ago. I started working as a freelancer after I had my fourth kid, actually. I was like "I need more flexibility" and I fell into the world of WordPress, fell in love with it. And then I actually started to offer to the service, so 12 years I ran a web development agency and more recently I founded a startup also related to the world of WordPress called Strattic.
At WordCamp Europe you have talked about cross-site scripting. Can you please explain what XSS is and why should the website owners care about it?
MS: Cross-site scripting is the most common type of vulnerability and hack that happens to this kind of website. And it involves getting into the site's database. It's the hardest to detect and the hardest to protect against. And what it does is gives hackers access to the website in ways that site owners definitely don't want. Last year at WordCamp Europe in Paris I gave a talk about different levels of security that site owners can implement to protect their site. What's good about the world of WordPress is that if you generally keep on top of your plug-in updates and your core updates, and there's a few other things you can implement as well, you're generally pretty good. But if someone gets in and there an XSS attack takes place, sometimes site owners don't even know that it has happened. Sometimes it only takes effect if someone visits the site, or someone visits from Google. There's all sorts of sneaky ways to implement it, and cleaning it up is also a challenge. So we want to try to make sure that it doesn't happen.
So how can you test your website or your web application to see if it's vulnerable to cross-site scripting and what can you do to protect your WordPress site from XSS?
It's really challenging because it could be anywhere actually. In the case of WordPress it could be on the theme level, or a plugin, or the core. If you have plugins installed that are well maintained then generally if something like that is discovered there will be a patch. But the problem is that window between when the vulnerability is discovered and when the patch and the update is released for people to implement. Generally it's a good idea to try to keep your database as well protected from the Internet as possible. So some ways to do that are to protect your login page, but people can get in other ways as well. The database is the weak point and the goal is to try to keep that protected and out of the hands of anyone else or as far away from access by anyone else as possible. There's tools that you can use to scan your site to try to detect vulnerabilities, a lot of them don't find everything. We've seen that that a site will have been attacked, have been breached and the tools can't tell, but we can tell. That's the problem with automation I think, it can't always pick up on things. Most people figure it out when something weird starts to happen or shows up on the site. What I spoke about at WordCamp Europe was the content security policies, which is like another level of protection that people can use.
So can you please explain what content security policies are and how do they work?
CSPs are a header that you can from your website to the browser. It's like a message from the website to the browser and it tells the browser how to behave in certain instances. there's like a number of different types of header security headers that exist and one of them is a content security policy and the content security policy is a whitelist. So what that means is it says to the browser "this is the content that you can load and is okay, it's like it's safe. Anything else that tries to load on the page do not load". So how does that connect to the cross-site scripting? So cross-site scripting will inject something malicious and then when the page loads in the browser the browser will load the malicious scripts or whatever because they can't tell the difference between what is malicious and what is not. If the browser is told load all of this stuff it will load all of it. But when a site has a content security policy in place, it basically says to the browser "if there's something that's not in this list of types of content that is trying to load, block it". And then it's what it does is if the site has been breached in some way it won't impact the user, the site visitor, they will stay safe. The site owner can then fix it, but in the meantime there's no threat to the site visitor themselves.
Why should WordPress developers care about content security policies?
Well unfortunately despite the fact constant work is being done on the security side of things with WordPress, it's still the most attacked platform; mainly because of its size. It's a great ROI for hackers because if you find a vulnerability in one site then the chances are it exists in thousands, hundreds of thousands or even potentially millions of sites. And it's impossible to stay on top of everything all the time, so like that window that I mentioned before between a vulnerability being exposed and being patched that's like a great opportunity for a hacker and things can still happen. So I think we all have to live with the reality that despite what we do to protect our site there's always a chance that it will be breached. And so the security of our users, our site visitors is the most important thing. We want to make sure that they're not being negatively impacted by our site. So when a WordPress developer implements a content security policy for their site, it means that in the chance that something happens to their site it won't impact their users. And also I would say that it positively impacts the site owner's bottom line from a business point of view because if their site continues to be safe visitors will return, whereas if they visit the site and it's clearly been messed with then they will hesitate.
And what kind of site are CSPs suitable for?
Really any type of site. They're tricky to implement because you can easily block your own content. CSPs works on the level of like the type of content, so you could say like images can only load from this particular domain, right? But sometimes, for example I'll give an example with our own site on Strattic, we have a CSP in place obviously and my talk from WordCamp Europe we wanted to embed in our site, but we hadn't whitelisted WordPress.tv yet. So actually it was not displaying and we had to update our CSP to support that. So it's kind of like a cat and mouse of always being on top of the types of content that you actually want to load and not block yourself. But I think it's a good practice to have in place and probably the way that every site should be. So yeah I mean it's the nature of the web, right? There's always something else to do, always a little bit more work. That's just the nature of the game, and if it keeps your users secure you should do it.
