It’s time to clear up the debate once and for all. Despite all the doubts (and some haters), WordPress core, is without a doubt one of the most incredibly secure platforms you can choose to put a site on.
Great post! "Up to date software is secure. Out of date software is a target." - this is true of Operating Systems too (like Windows and Apple). If you're running an old version of Windows....good luck.
Maybe, but remember that it's not just the money for Pwn2Own; it's also that the Pwn2Own contest uses prestige targets. It's probably not quite true that nobody cares if you find a Wordpress vulnerability, but it's certainly nothing resembling weaponizing a Chrome vulnerability.
Assuming the competition is attacking the core (with no 3rd party or themes), wouldn't the 64 million installs be the prestige given all of them could then be an attack vector to the billions of pageviews they serve?
Serious Wordpress, Joomla! or Drupal vulnerabilities and exploits can still get you a few thousand dollars. Quite a high ROI because the vulnerabilities are easier to find than in Chrome.
This is a pretty poor strawman of an argument. Wordpress Core may be secure, but it's also not what people deploy. Nobody uses "Just Wordpress" - you have to use a custom theme and a half-dozen plugins just to get a basic Wordpress install into a usable shape, and therein lies the problem - the number of Wordpress installs compromised through these "necessary" plugins is staggeringly huge.
Until that stops being a problem, "Wordpress The Product That Has 64 Million Installs" cannot be considered secure, even if wp-core is the most secure product ever written.
That's great, but all it means is that you just weren't in the crosshairs, not that you were actually secure. Automating updates is a wonderful way to open up an attack vector, as well - for example, a little while back, attackers got into the Wordpress SVN repo and back-doored a bunch of popular plugins[1]. Anyone performing "regular updates" without proper auditing would have installed malicious code that opened them up to full-scale breach.
It is much more practical to secure a single repo administered by competent techs than it is to secure a zillion web sites run by people with no technical experience.
This is just not true. There's lots of people who run their personal sites quite happily using just WP core and one of the bundled themes.
I agree that the quality of community-contributed themes and plugins is all over the map, and I fight with clients constantly to try and keep them from installing plugins on a whim for exactly that reason. (It's amazing how many people grab plugins to do stuff that WP can actually do itself, just in a way that isn't immediately obvious to the user.) But it's not impossible to run a site on just WP core.
Everyone else: if you can avoid it, don't run Wordpress. You can run a safe Wordpress site, but you do it the same way you drive fast without a seatbelt: by playing the odds.
Build a custom CMS for your website, on the basis that even though you probably won't do a better job than wordpress in terms of security you will be obscure enough that nobody will bother you?
I've actually done this in the past with no (known) compromises on something that I'm sure I could pay a smart teenager who watched a few defcon talks to rip apart in an few hours.
Or is there some platform you would recommend that is inherently more secure by design? Like an OpenBSD of the CMS world.
Use a static site generator to the extent that you can. But, honestly: I think you'd stand a good chance of doing better than Wordpress starting from scratch. There are a couple of very difficult design decisions embedded into Wordpress that make life much harder for them than it needs to be for you.
For one, a built-in theme editor that exposes you to remote command execution in the presence of another vulnerability, such as cross-site scripting (XSS).
For another, an integrated comment system that stores credentials for anonymous Internet users in the same data structure as the one used for site administrators.
Fundamentally, "X is secure" has no meaning (to me, a non-expert in any security field). If it's a term of art, so be it, but make it clear you're using it as a term of art. In the absence of that, I think "X is secure" only makes sense in comparison to other things, not as a standalone statement.
What is Wordpress as secure as? This is a flabbergastingly empirical question that could be tackled on different fronts. It hinges on which way(s) you define security.
Is security based on the number of users of your application? (I would dismiss that outright, but the author uses it as evidence.)
Is security based on the number of publicly disclosed vulnerabilities as compared to competitors?
Is security based on some formally-definable metric that can be created by examination of the code itself?
Is security based on some financial guarantee from the backers of an application?
In the end, I understand that this is a puff piece and so I shouldn't read too much into the article. But saying "X is secure" actually doesn't make it so.
(Note that I'm not saying that I think WP is or is not insecure; I just don't feel any better qualified to make that assessment after reading this article.)
I'm curious, what the answers to the comparisons you mentioned would make you conclude positively in WordPress's favor?
Is security based on the number of users of your application?
1 in 6 websites on the Internet runs WordPress.
Is security based on the number of publicly disclosed vulnerabilities as compared to competitors?
It's open source code so every discovered vulnerability is public knowledge. Many competitors are closed source and may not disclose vulnerabilities (doesn't mean there aren't any). On this point, I'm not sure what could be improved on given it's FOSS or what "winning" would look like.
Is security based on some formally-definable metric that can be created by examination of the code itself?
If you can come up with the metric, I'm sure it can given the code is FOSS. Perhaps I don't follow what you're looking for here.
Is security based on some financial guarantee from the backers of an application?
It's Free Open Source Software, no FOSS I know of has a financial guarantee by its very nature. Examples like RHEL are not free (as in beer). The guarantee of FOSS comes from the degree of sunshine placed upon the code that everyone has an aligned interest to disclose vulnerabilities.
Perhaps you could elaborate on what would make you feel "X is secure"?
> I'm curious, what the answers to the comparisons you mentioned would make you conclude positively in WordPress's favor?
My goal in disqualifying myself at the beginning of my post was to make it clear that, although I find the article to be unconvincing (the reasons for which I tried to explain), I'm not the one (at least, not given how little I've thought about it) to come up with a good way to decide what it should mean to say "X is secure." Unfortunately this means that answering my questions isn't probably a good use of your time, because to me they were off-the-cuff. (Oddly, I had answered one of the questions that you responded to.)
The list is not exhaustive. It was a mix of real questions (code metrics) and anti-questions (# of users) that was unfortunately not very logically laid out. They were just what came to mind while waiting for a 5x5' storage unit rental to get cleaned out.
To be moved, I think people want to see relevant data. Unfortunately I don't have more to offer about what that looks like than Potter Stewart did.
There is a universe of terribly unsafe open source software. The notion that Wordpress is somehow more secure because it has a different license than phpBB is wishful.
It's open source code so every discovered vulnerability is public knowledge.
Well, there is public knowledge, and there is actual action. Several examples come to mind. OpenSSL, which has been available for a very long time, does not have that good a track record. There is the example of 10-year old vulnerabilities disclosed in TOSSA that only recently came to light. The BEAST attack's underlying target was written about before.
From the point of view of labeling anything to be "secure" (whatever that means), I like to think what Steve Brown used to say about some new output from his science lab: "Not known not to work". Translated to the security world, "Not known to have security vulnerabilities."
You're right, the post is essentially meaningless. If it's secure why doesn't MI5, CIA, and banks use it as their CMS? Oh because it's not that secure.
In addition to your questions, I would ask
* What types of attack is it secure against?
* How much work is involved in doing all the ongoing maintenance?
* The risk tends to come from plugins, but those plugins are one of the main selling points of Wordpress. To what extent does this lessen Wordpress's value proposition?
* If you do ever get hacked, what kind of auditing is there? What help does it provide for damage limitation?
The OP is an overly-simplified response to typical boilerplate comments - [insert language or framework] is [fast/slow/secure/insecure]. Of course Wordpress is secure enough for the average professional site as long as it's maintained, but the OP sounds like a car salesman saying "Sure it's _real_ fast" without telling you the actual speed.
The problem with this argument is simple: to stay secure, you have to keep WordPress core current with updates. And the only way to apply updates is for an administrator to apply them, either through the admin backend or directly through the filesystem.
The vast, vast, vast majority of WordPress users are not that diligent about doing this, and their hosts don't do it for them. So they just sit on whatever version they happened to be running when they first set up the site for years. I do a lot of consulting work on WP sites and see this all the time.
So while I would be the first to agree that the WP core team has gotten much, much better about writing secure software, until there's a way for that software to stay secure when used as average users use it, it will never be truly secure.
There is a market for WP hosts who will take this administrative burden on for you in exchange for costing you more -- WPEngine is a big player in that market. But I'm at the point now where I think the only way forward is for WP to just update itself automatically when updates are released, no user intervention required. It's not acceptable for security to be something you only get from a few high-priced hosts; most people will never use those hosts. It needs to be secure for everybody, including those who run it on commodity shared hosting run by semi-competent admins, as long as "runs great on commodity shared hosting run by semi-competent admins!" is a selling point for the software.
EDIT: They illustrate this problem right in the post!
"WordPress users must be responsible for their own security, maintain strong Passwords, and keep plugins and themes up to date, as well as WordPress itself."
How many decades of experience with non-technical users will it take to get us to understand that they just don't do that stuff? They don't maintain strong passwords. They don't run updaters. All that stuff that the post puts on their shoulders, is stuff we know for a fact that many (most?) of them will never even think of doing.
If you know that's the audience for your software, and you don't design it to be secure when used as you know that audience will use it, the responsibility for the eventual hacks are as much yours as theirs.
Having to keep up with an continuous stream of patches is not a property of a secure system. "Secure as long as you keep it patched" is a bar that almost any piece of software can clear.
Yes, this is my point exactly. Except much more succinctly stated :-D
In WP's defense, though, it is not the only blog/CMS product that works this way -- the vast majority I've used require some kind of user or admin interaction to apply updates, mostly to avoid people complaining if an update should break something. And WP's update process is much easier and friendlier to non-technical users than most are.
But in practice that turns out not to matter much, because no matter how easy making that intervention is, some percentage of users are going to skip it. The only way to get around that is to not require the interaction at all. That may risk breaking some stuff, but I'd rather work in an ecosystem where everybody's secure and poorly written extensions break occasionally than one in which poorly written extensions never break at the cost of security.
this is actually a pretty cogent argument. how do you apply this logic to other systems and software?
for example, we know that running an old version of OSX is not too bad. But if you're still running 10.4 instead of 10.4.3, you're in for some trouble.
when there is a security patch to a specifc X.Y release OSX or Windows, (like X.Y.Z) it's not secure to leave that running. the same would apply to any other piece of software (like WordPress), no?
Pretty much, yeah. Any software that is exposed to the public Internet needs to be kept up to date. If it's not, it's not secure. That means either someone has to update it, or it has to update itself.
The world has been moving slowly away from manual updates to automated ones for some time now. Windows Update used to be much more oriented towards manually reviewing and applying updates than it is today. Chrome famously updates itself completely silently, and Firefox is moving in that direction. Consumer-oriented products are all headed that way, because it's the only way to keep them secure when their "administrator" is a non-technical user.
WP is kind of unique in that it's a type of software (a content management system) that usually is only installed and administered by people with some technical experience, but the ease of installing WP has attracted a huge number of people without that experience to use it. So my argument would be that as WordPress has essentially become a consumer product, it should behave like one.
The problem is that security is not a feature. It can not be simply added at some point if software was not designed with security in mind.
For example, if authorization code is spread all over the code base and mixed with business logic no patching will make this secure, at some point problems will emerge again.
I'm not saying WordPress is not secure, because I don't know its architecture. But the argument that after few critical vulnerabilities had been fixed no more were discovered does not convince me. A better argument would be to actually explain the WordPress architecture and why it is a good base for a secure system.
For example Ruby Rack architecture is in my opinion a wise design from a security perspective, because it allows to nicely isolate security critical pieces from business logic.
The biggest problem with WordPress security isn't WordPress itself, it's with WordPress' extension APIs.
You extend WordPress by writing "themes" and "plugins". Themes are supposed to change how the site looks, while plugins are supposed to change how the site works. But in practice, there's no isolation of capabilities in either case, so it's entirely possible for a plugin to do theme-like stuff and a theme to do plugin-like stuff. Users don't understand this, so they think things like "oh, it's safe to install, it's just a theme."
Worse, there's no isolation between code that comes in via either of these extension mechanisms and WordPress itself. As far as the server is concerned it's all just a big bag of PHP that runs with the same privileges. So a malicious theme or plugin has a lot of scope to do Very Bad Things once it's convinced a user to install it. Users don't understand how the attack surface increases as your installed plugins/themes increase, so they install tons of stuff, sometimes just because "oh this looks fun!"
I don't know how you untangle all this, unfortunately, especially in a system that needs to run well in commodity shared hosting. The only real defense is to be extremely judicious in what extensions you choose to install.
Couldn't some kind of PHP level sandboxing be used to isolate plugins and themes? So for example a theme would not be able to spawn OS processes, access DB connection or create a new one, read and modify HTTP headers.
Here is my opinion on that matter. As part of the security team at WP Engine, it's not only my job to educate our users on how to better stay secure, but also figure out why their site was compromised in the first place. The majority of the time, it's because of some out of date plugin that I've never even heard of. Simply searching for "plugin + version" in Google brings up publicly known exploits.
The hardest issue, will be keeping WordPress Core up to date. It's easy if you have one website, but if you're managing hundreds, it's going to be a pain to update each manually, or even through Git/SVN. I do agree though, that WordPress needs to have an "automatic update" feature for both core, and plugins. Personally, I would rather have a broken site, than a compromised one. Both scenarios will require work to fix anyways. Our latest deployment of WordPress only broke a handful of websites (I only remember working on about 4 sites that actually had to rollback to a previous version of WordPress). That's pretty impressive.
Mostly I agree. I'm not sure there's any way for you to guarantee the security of WP as long as users can install arbitrary plugins and themes. At least as WP is currently architected.
Insofar as there's a WPEngine specific piece of this problem, it's that (IMO) you guys don't do a great job of making users understand before they install that stuff that installing it can have severe consequences. If installing arbitrary plugins is how users get their sites hacked, installing arbitrary plugins (except maybe for a few whitelisted "known good" ones) should be a Very Scary Thing, full of dire warnings you have to click through before the plugin installs. Users mostly won't understand what the warnings are saying, but most have at least been conditioned to click "Cancel" when warnings start flying.
I've talked to a lot of people who think that just moving to WPEngine has solved security for them, so they don't get how their massive collection of Super Awesome Plugins are putting them at risk. They think you all are protecting them from that. Which you can't, I know, but you can make the users understand that better.
Out of the box Wordpress is configured to allow itself to overwrite its own application files--either via the GUI update process, or via the GUI theme editor. This means almost any exploit can result in arbitrary PHP code execution--which can have many nasty results all over your server.
A CMS application should not be able to write arbitrary PHP code to the server under any circumstance. It's possible to configure Wordpress this way, but that is the exception not the rule.
Anyone can invent a security system that he himself cannot break. I've said this so often that Cory Doctorow has named it "Schneier's Law": When someone hands you a security system and says, "I believe this is secure," the first thing you have to ask is, "Who the hell are you?" Show me what you've broken to demonstrate that your assertion of the system's security means something.
45 comments
[ 3.2 ms ] story [ 62.0 ms ] threadUntil that stops being a problem, "Wordpress The Product That Has 64 Million Installs" cannot be considered secure, even if wp-core is the most secure product ever written.
[1] http://wordpress.org/news/2011/06/passwords-reset/
I agree that the quality of community-contributed themes and plugins is all over the map, and I fight with clients constantly to try and keep them from installing plugins on a whim for exactly that reason. (It's amazing how many people grab plugins to do stuff that WP can actually do itself, just in a way that isn't immediately obvious to the user.) But it's not impossible to run a site on just WP core.
Everyone else: if you can avoid it, don't run Wordpress. You can run a safe Wordpress site, but you do it the same way you drive fast without a seatbelt: by playing the odds.
Build a custom CMS for your website, on the basis that even though you probably won't do a better job than wordpress in terms of security you will be obscure enough that nobody will bother you?
I've actually done this in the past with no (known) compromises on something that I'm sure I could pay a smart teenager who watched a few defcon talks to rip apart in an few hours.
Or is there some platform you would recommend that is inherently more secure by design? Like an OpenBSD of the CMS world.
What is Wordpress as secure as? This is a flabbergastingly empirical question that could be tackled on different fronts. It hinges on which way(s) you define security.
Is security based on the number of users of your application? (I would dismiss that outright, but the author uses it as evidence.)
Is security based on the number of publicly disclosed vulnerabilities as compared to competitors?
Is security based on some formally-definable metric that can be created by examination of the code itself?
Is security based on some financial guarantee from the backers of an application?
In the end, I understand that this is a puff piece and so I shouldn't read too much into the article. But saying "X is secure" actually doesn't make it so.
(Note that I'm not saying that I think WP is or is not insecure; I just don't feel any better qualified to make that assessment after reading this article.)
Is security based on the number of users of your application?
1 in 6 websites on the Internet runs WordPress.
Is security based on the number of publicly disclosed vulnerabilities as compared to competitors?
It's open source code so every discovered vulnerability is public knowledge. Many competitors are closed source and may not disclose vulnerabilities (doesn't mean there aren't any). On this point, I'm not sure what could be improved on given it's FOSS or what "winning" would look like.
Is security based on some formally-definable metric that can be created by examination of the code itself?
If you can come up with the metric, I'm sure it can given the code is FOSS. Perhaps I don't follow what you're looking for here.
Is security based on some financial guarantee from the backers of an application?
It's Free Open Source Software, no FOSS I know of has a financial guarantee by its very nature. Examples like RHEL are not free (as in beer). The guarantee of FOSS comes from the degree of sunshine placed upon the code that everyone has an aligned interest to disclose vulnerabilities.
Perhaps you could elaborate on what would make you feel "X is secure"?
My goal in disqualifying myself at the beginning of my post was to make it clear that, although I find the article to be unconvincing (the reasons for which I tried to explain), I'm not the one (at least, not given how little I've thought about it) to come up with a good way to decide what it should mean to say "X is secure." Unfortunately this means that answering my questions isn't probably a good use of your time, because to me they were off-the-cuff. (Oddly, I had answered one of the questions that you responded to.)
The list is not exhaustive. It was a mix of real questions (code metrics) and anti-questions (# of users) that was unfortunately not very logically laid out. They were just what came to mind while waiting for a 5x5' storage unit rental to get cleaned out.
To be moved, I think people want to see relevant data. Unfortunately I don't have more to offer about what that looks like than Potter Stewart did.
Well, there is public knowledge, and there is actual action. Several examples come to mind. OpenSSL, which has been available for a very long time, does not have that good a track record. There is the example of 10-year old vulnerabilities disclosed in TOSSA that only recently came to light. The BEAST attack's underlying target was written about before.
From the point of view of labeling anything to be "secure" (whatever that means), I like to think what Steve Brown used to say about some new output from his science lab: "Not known not to work". Translated to the security world, "Not known to have security vulnerabilities."
In addition to your questions, I would ask
* What types of attack is it secure against?
* How much work is involved in doing all the ongoing maintenance?
* The risk tends to come from plugins, but those plugins are one of the main selling points of Wordpress. To what extent does this lessen Wordpress's value proposition?
* If you do ever get hacked, what kind of auditing is there? What help does it provide for damage limitation?
The OP is an overly-simplified response to typical boilerplate comments - [insert language or framework] is [fast/slow/secure/insecure]. Of course Wordpress is secure enough for the average professional site as long as it's maintained, but the OP sounds like a car salesman saying "Sure it's _real_ fast" without telling you the actual speed.
As it happens, we have a number of Fortune-50 banks and financial institutions as clients who host their WordPress with us <shrugs>
The vast, vast, vast majority of WordPress users are not that diligent about doing this, and their hosts don't do it for them. So they just sit on whatever version they happened to be running when they first set up the site for years. I do a lot of consulting work on WP sites and see this all the time.
So while I would be the first to agree that the WP core team has gotten much, much better about writing secure software, until there's a way for that software to stay secure when used as average users use it, it will never be truly secure.
There is a market for WP hosts who will take this administrative burden on for you in exchange for costing you more -- WPEngine is a big player in that market. But I'm at the point now where I think the only way forward is for WP to just update itself automatically when updates are released, no user intervention required. It's not acceptable for security to be something you only get from a few high-priced hosts; most people will never use those hosts. It needs to be secure for everybody, including those who run it on commodity shared hosting run by semi-competent admins, as long as "runs great on commodity shared hosting run by semi-competent admins!" is a selling point for the software.
EDIT: They illustrate this problem right in the post!
"WordPress users must be responsible for their own security, maintain strong Passwords, and keep plugins and themes up to date, as well as WordPress itself."
How many decades of experience with non-technical users will it take to get us to understand that they just don't do that stuff? They don't maintain strong passwords. They don't run updaters. All that stuff that the post puts on their shoulders, is stuff we know for a fact that many (most?) of them will never even think of doing.
If you know that's the audience for your software, and you don't design it to be secure when used as you know that audience will use it, the responsibility for the eventual hacks are as much yours as theirs.
In WP's defense, though, it is not the only blog/CMS product that works this way -- the vast majority I've used require some kind of user or admin interaction to apply updates, mostly to avoid people complaining if an update should break something. And WP's update process is much easier and friendlier to non-technical users than most are.
But in practice that turns out not to matter much, because no matter how easy making that intervention is, some percentage of users are going to skip it. The only way to get around that is to not require the interaction at all. That may risk breaking some stuff, but I'd rather work in an ecosystem where everybody's secure and poorly written extensions break occasionally than one in which poorly written extensions never break at the cost of security.
for example, we know that running an old version of OSX is not too bad. But if you're still running 10.4 instead of 10.4.3, you're in for some trouble.
when there is a security patch to a specifc X.Y release OSX or Windows, (like X.Y.Z) it's not secure to leave that running. the same would apply to any other piece of software (like WordPress), no?
The world has been moving slowly away from manual updates to automated ones for some time now. Windows Update used to be much more oriented towards manually reviewing and applying updates than it is today. Chrome famously updates itself completely silently, and Firefox is moving in that direction. Consumer-oriented products are all headed that way, because it's the only way to keep them secure when their "administrator" is a non-technical user.
WP is kind of unique in that it's a type of software (a content management system) that usually is only installed and administered by people with some technical experience, but the ease of installing WP has attracted a huge number of people without that experience to use it. So my argument would be that as WordPress has essentially become a consumer product, it should behave like one.
For example, if authorization code is spread all over the code base and mixed with business logic no patching will make this secure, at some point problems will emerge again.
I'm not saying WordPress is not secure, because I don't know its architecture. But the argument that after few critical vulnerabilities had been fixed no more were discovered does not convince me. A better argument would be to actually explain the WordPress architecture and why it is a good base for a secure system.
For example Ruby Rack architecture is in my opinion a wise design from a security perspective, because it allows to nicely isolate security critical pieces from business logic.
You extend WordPress by writing "themes" and "plugins". Themes are supposed to change how the site looks, while plugins are supposed to change how the site works. But in practice, there's no isolation of capabilities in either case, so it's entirely possible for a plugin to do theme-like stuff and a theme to do plugin-like stuff. Users don't understand this, so they think things like "oh, it's safe to install, it's just a theme."
Worse, there's no isolation between code that comes in via either of these extension mechanisms and WordPress itself. As far as the server is concerned it's all just a big bag of PHP that runs with the same privileges. So a malicious theme or plugin has a lot of scope to do Very Bad Things once it's convinced a user to install it. Users don't understand how the attack surface increases as your installed plugins/themes increase, so they install tons of stuff, sometimes just because "oh this looks fun!"
I don't know how you untangle all this, unfortunately, especially in a system that needs to run well in commodity shared hosting. The only real defense is to be extremely judicious in what extensions you choose to install.
The hardest issue, will be keeping WordPress Core up to date. It's easy if you have one website, but if you're managing hundreds, it's going to be a pain to update each manually, or even through Git/SVN. I do agree though, that WordPress needs to have an "automatic update" feature for both core, and plugins. Personally, I would rather have a broken site, than a compromised one. Both scenarios will require work to fix anyways. Our latest deployment of WordPress only broke a handful of websites (I only remember working on about 4 sites that actually had to rollback to a previous version of WordPress). That's pretty impressive.
Insofar as there's a WPEngine specific piece of this problem, it's that (IMO) you guys don't do a great job of making users understand before they install that stuff that installing it can have severe consequences. If installing arbitrary plugins is how users get their sites hacked, installing arbitrary plugins (except maybe for a few whitelisted "known good" ones) should be a Very Scary Thing, full of dire warnings you have to click through before the plugin installs. Users mostly won't understand what the warnings are saying, but most have at least been conditioned to click "Cancel" when warnings start flying.
I've talked to a lot of people who think that just moving to WPEngine has solved security for them, so they don't get how their massive collection of Super Awesome Plugins are putting them at risk. They think you all are protecting them from that. Which you can't, I know, but you can make the users understand that better.
A CMS application should not be able to write arbitrary PHP code to the server under any circumstance. It's possible to configure Wordpress this way, but that is the exception not the rule.
Anyone can invent a security system that he himself cannot break. I've said this so often that Cory Doctorow has named it "Schneier's Law": When someone hands you a security system and says, "I believe this is secure," the first thing you have to ask is, "Who the hell are you?" Show me what you've broken to demonstrate that your assertion of the system's security means something.
http://www.schneier.com/blog/archives/2011/04/schneiers_law....