WordPress isn't secure.

Prove it.

[lorax]

I'm serious. I've heard many people say/write that WordPress is a security nightmare - that it has security holes. This may be true but I haven't found it to be so and I have yet to see anyone offer proof of it. On the other hand, the WordPress core development team has been working hard and the general message I get from the WordPress community is that WordPress is secure. What to believe?

I believe that a hacker might be able to find their way into a WordPress install but I believe WP is no less secure than a Drupal or Joomla or any CMS script out there. If you have proof to the contrary, I'd like to know about it. Please don't post hearsay and suppositions. If you know of a security issue, let's have it so we can examine it and discuss it and see if there's a solution or work around.

Please keep the tone professional.

[explorador]

There is something else: try your best to disguise your CMS.

There is a lot to say but it's always good to make your WP site appear as anything but WP, remove the classic lines, classic signatures, even the metas. WP gives it away too easy revealing specific versions of this and that, you can search the web for the WP version VS specific vulnerabilities and play. And sure this advice applies to other CMS, not only changing those signatures but also changing the usual logins and open door locations.

I agree on hosting WP on the official web or official experts but anyway I woulds still keep constant backups.

It's not just CMS specific: I built mine and it does automatic backups every day, one master every week and 4 monthly sent to 2 diff places. I used to raise an eyebrow when I read things like this in the past but not anymore, problems teach a lot. Perhaps you can't keep your CMS fully secure 100% but yes you can try your best to keep your data safe, do constant backups!

[Storyman]

Regarding WordPress plugin security...

Maybe this deserves to be a new topic and if so let me know, but thought since the conversation has been specific to WP security this question directly relates to that issue.

How important is it to remove unused plugins? Is this a known vulnerability?

[lorax]

@Storyman
It's not a vulnerability per se. Having an unused plugin sitting there is just one more possible point of attack. It all depends upon the plugin.

If the plugin has minimal code - it's not likely to be an issue unless there's an exploit that could be used to leverage it AND you haven't kept it up to date (but that's true of all plugins). It's more about forming the right habits around how to manage plugins. Plugins can consume server resources even when they aren't being used. So why keep them? Keep your server lean and safer by removing unused plugins.

[lorax]

>> It's my first go-to tool for a simple site.

Oh ergo... I can't wait to show you what I've been working with WordPress. You and me, laptops, and some whiskey at PubCon. Deal? ;)

[incrediBILL]

So why keep them? Keep your server lean and safer by removing unused plugins.

Best advice in the whole thread.

If you aren't using it, uninstall it.

[netmeg]

Yea, if there were one thing I could impress upon my clients, this would be the second thing (after keep it updated). I've been handed installs with ten active plugins and forty deactivated ones.

[ergophobe]

@lorax - definitely. But you didn't make it this year (or were hiding effectively) and we'll see about next year for me.

I've gotten a little behind the times with Worpdress since I've been focusing on other things, but I've been thinking that I need to really get up to 2014 (coming soon) on Wordpress.

Care to give a teaser?

[lorax]

@ergo - I didn't make it to LV but was hoping for New Orleans. Or maybe you can only get to LV? Let me know.

As for 2014 - I assume you mean the newest theme?

[ergophobe]

I just mean rolling my sleeves up and getting in there and mucking with the innards - theming, plugins, whatever.

I've been doing so much Drupal stuff lately, that I tend to see Drupal solutions for everything. I think it's always good, whatever your tool of choice is, to get off the reservation every once in a while and see how things are done elsewhere.

[lorax]

OT

Ah! True enough. One thing that I read not too long ago was about how there may be a move by developers of Drupal, WordPress, and Joomla to sitting down with each other to learn/pick the best of each and bring it back to their own camps. That could be very beneficial if they actually do this.

[ergophobe]

I think this is already happening. One of the things you hear a lot in the Drupal world is:

"There's no point in becoming Wordpress. Wordpress is already Wordpress. What we want is to take those parts of Wordpress that will enhance Drupal and make Drupal better."

One example is the default content entry screen in Drupal 8 that is inspired by Wordpress - simple media insertion, "content" column and a "meta" column - but I think moving the mark a little further down the line.

Another motto you hear a lot lately is "Proudly not invented here." The idea being that if someone already has an excellent and widely used something (JS library, CSS framework, menu routing component, web services component), why would you build your own?

[graeme_p]

ergophobe, I really like the sound of Drupal. They seem to be (at least with Drupal 8) doing a lot of things the way I think they should be done.

How good is Drupal at getting a small site up quickly? Can it compete with Wordpress?

[explorador]

How good is Drupal at getting a small site up quickly? Can it compete with Wordpress?

The short answer is: yes.
Not so short answer: not only can compete, it wins IMHO

Long answer? perhaps not so quickly (depending on the developer). Yes I choose Drupal over Wordpress if I can and my client is fine with it but there are important differences:

Wordpress is ready out of the box with default category, easy and nice editor for posting your stuff, a nice menu builder with drag and drop features and also the archive function ready (along with some other minor stuff), should we take in count the ability to import and export data?.

Drupal on the contrary when you install it has no nice editor, no WYSIWYG, just plain text, simple default structure for articles and pages, no autopost, no friendly urls enabled, no way to import or export data in a simple way, no archives, no calendar-posts. It's just the basic structure waiting for you to make it what you want it to be and once you add those functionalities and modules, it shines.

At first I felt it was kinda boring, then I built my list of stuff to add. At times I use a pre-cooked drupal install with all the features making the job last like 5 minutes and ready to feed it. This is the reasons many don't like Drupal because it needs extra work but from my experience: it pays and it pays well.

[Storyman]

@graeme_p

My experience with Drupal that it takes awhile for modules to be updated with full version updates (ver. 7 -> ver. 8). For some modules it can take quite a while because they are thoroughly field tested; including Beta testing and Recommended Candidates (which are not recommended for production sites).

If it is a small site go with WordPress. Drupal has more power under the hood (IMHO) it also has a steeper learning curve.

A difference between WordPress and Drupal users can be seen in their forums. WordPress users are generally willing to help out newbies. Newbie questions in Drupal forums tend to go unanswered.

I'd suggest you consider taking time to play with a local install of Drupal before installing on a public server.

[Kendo]

Can Drupal compete with Wordpress?

Totally different fish for totally different cuisines and diners.

[lorax]

Let's not get into a who's better thread. Please stay on topic. Thx

[ergophobe]

Some of these threads are getting old, but if you want to start a discussion on the merits of a particular CMS, probably best to start here
CMS FAQ - Best Content Management Systems for Web Development [webmasterworld.com]

And then start a new thread on the topic since some of those are getting old.

Apologies Lorax - didn't want to divert the discussion and that's why I tried to bring in Apache and Ubuntu. I was looking to compare security practices among open source projects, not to start a CMS shootout!

[graeme_p]

Sorry, my fault too - perhaps a mod should move these comments to a new thread?

To get back on topic:

The parts of Wordpress I see (such as the theme system) are pretty ugly. From what I have read and remember about other bits, it is not decoupled for a start. It is the price of having evolved from a blogging platform to a flexible CMS that is used as a framework.

This is not directly a security issue, but bad architecture is likely to lead to bad security - the problem of template developers being able to access too much that I described above is just one example.

[ergophobe]

I think you're right that it is a *potential* security issue. You're opening up the entire PHP function set to themers and that's a bad idea.

Most CMS work that way, but it is a major reason for moving to Twig or Smarty for the template layer - it limits dramatically what a themer can do. I'm not worried about malicious intent, but ignorance.

I came across something like this in a Drupal site not too long ago

$where = $_GET['filter'];
$query = "SELECT * FROM `tablename` WHERE `filter` LIKE '$where';
$db->query($query);

No checking at all because some themer was either in a hurry or didn't know any better (if you don't know why this is really bad, see [xkcd.com...] ).

Again this was on a Drupal site and this was most definitely pilot error, but Wordpress is similarly wide open to a similar pilot error and makes it easier than most systems by creating an interface to edit PHP files live on the server, which is a collosally terrible idea.

Is a system that is inherently secure when used correctly, but insecure when abused in stupid ways "insecure"? I would say that the existence of childproof caps, anti-kickback technology on chainsaws, airbags in cars (the primary advantage of which is to protect people who are not wearing their seatbelts) and so forth suggest that, in fact, good security depends on protecting people from their own idiocy.

With software, that implies exposing power on a curve that roughly follows knowledge. Exposing a PHP editing interface to the average site user is, in my opinion, not a security best practice and I'm surprised it has lasted so long in Wordpress.

>> poor separation

And that's really the root of it. Wordpress, like most open source CMS, has poor separation between content and configuration - config is strewn all about the database, which means that the same APIs that handle content editing expose the very roots of the system.

[graeme_p]

There are multiple problems there:

1) That should not be how your database layer works. The usual way of creating a query should sanitise anything by default. Sending a raw input to the database should require extra work, rather than being the easy way to do it.

It also means that you can audit the db layer for vulnerability to SQL injection without worrying too much about the rest of the code base.

2) That code should be abstracted out to a plugin, rather than being in a theme (although possibly wrapped so the query only runs IF it is used in a theme).

3) Code becomes quite verbose, and relies on the developer to do things like caching queries manually.

Allowing editing of PHP code is a result of the philosophy behind Wordpress - making it easy to hack (in the good sense!) is preferred making it secure. In this case it saves developers the trouble of installing a text editor that works over ftp or (far better) sftp. Wordpress is successful because it easy to get started - if you know a bit of PHP and SQL you can create useful plugins so I cannot see this changing.

The combination of this and Wordpress's popularity means it is less secure - in the sense that a Wordpress install is a lot more likely to be compromised than a site based on many other platforms.

So the answer to the original question is that it is insecure - but:

1) It may be the best choice anyway because of the huge number of plugins and themes available.
2) It may not be any less secure than your alternative. What would you use instead? If the alternative is Django, RoR, Symfony or Drupal 8 then its less secure. If its Joomla or Drupal 7, maybe not.

Yes I am comparing CMSs to frameworks, and I think thats OK because there are times when both are viable choices.

[ergophobe]

>>Django, RoR, Symfony

This really goes to the heart of lorax's original question.

Everyone rags on Wordpress as insecure, but the massive user base means lot of eyes on that code. Building your own CMS from RoR is likely, I think, to have more exploitable code than Wordpress.

[graeme_p]

Massive user base cuts both ways: it also means a lot of the bad guys targeting Wordpress. For example, can you imagine something like the massive brute force attacks on Wordpress sites earlier this year on RoR sites?

Secondly, popular does not necessarily mean lots of eyes on the code. A lot of people use Wordpress because existing plugins and themes mean you can put together a customised site without learning much more than the theme system. These people are never going to look at the source.

In any case the number of eyes on the code is just one factor. Code quality, security audit, history, developer priorities, etc. OpenBSD is a lot less popular then Linux, and standard Linux is a lot less popular than Android, but OpenBSD is probably more significantly secure than Linux, and Linux in general is a more secure than Android.

Building your own CMS from RoR is likely, I think, to have more exploitable code than Wordpress.

Are you suggesting RoR has more holes than Wordpress, or that you will introduce vulnerabilities while building your own CMS?

[lorax]

>> ...has more holes than Wordpress

I don't think ergophobe is saying that. WordPress core code is secure and solid. The vulnerability is in the theme and plugin development. While each theme and plugin is reviewed, the process may not be as stringent as the core code reviews. But the pure volume of people looking over the theme & plugin code, using it, testing it, breaking it, etc can be a good thing. The chance of uncovering and bringing forth security and performance issues is greater with more people. Smaller communities == less people == less testing and checking. That's what I believe he's saying.

[ergophobe]

>>That's what I believe he's saying.

And lo, your faith shall be rewarded by confirmation. Yes, that's the essence of it.

When I mention the "number of eyes", I'm not talking about the user base, so much as the developer base. Wordpress has a large dev base and with funding from Automattic, has some resources to put into security review. As I mentioned, I don't think it gets the priority it does in some other open source projects, but it gets more attention than Bobby's Great New App (typically, unless Bobby is a security specialist).

Of course, if you have a top-notch professional security team vetting your very small code base, you'll end up with a secure app at a very high price and unless people have big budgets and need HIPAA or a high-level of PCI compliance, they don't typically spend for it.

OpenBSD is a lot less popular then Linux... but OpenBSD is probably more significantly secure than Linux

I don't think you need a "probably" in that sentence. I don't know anything about OpenBSD, but FreeBSD is unquestionably more secure if run right than Linux.

But, I would argue, this is not a question of code quality, but of architectural decisions.

It's more analagous to WP choosing to give you an interface that allows you to edit PHP files, whereas almost nobody else does. So on WP install, if you have one dumb user with a weak password and privs to edit files via the admin interface, the hacker owns your server. With Drupal, if I lock down SSH to only allow login with public/private keys, the challenge is much greater and there's only so much someone can do if he cracks into the CMS.

Similarly, FreeBSD has the concept of "jails" which allows separation of functions (so someone who owns your web server, doesn't necessarily have access to server admin or the DB and vice versa) which is harder to achieve in Linux.

For a cool rundown of differences between a Linux stack and a FreeBSD-based "Armored Stack" look at the table near the bottom of this article:
[drupalwatchdog.com...] (I have the print copy fo this article and every few months give it another read).

The article is by the guy who ran ha.ckers.org, which was hit by 1,000,000 attacks per year for the seven years he ran it, without getting compromised. That's some serious armor!

So in short, as I think about it more, I agree with you overall - if you design your custom app with security in mind and know what you're doing, it will be more secure than wordpress because you'll be in a position to make architectural decisions that encourage a secure design. No amount of code review from any community can compensate for a less secure architecture. So you're definitely right there.

My only caveat is that with a given architecture/feature set, I'll take the app with a bigger dev base and a bigger security team. But you're quite right that if you start from fundamentally different architectures like FreeBSD vs Linux, you end up with a very different security environment and your Wordpress = Linux analogy is well taken.

[graeme_p]

A custom CMS built on a good framework (especially a full stack one) will have a better architecture than Wordpress - the architecture is mostly dictated by the framework, not by the site/app specific code. Unless you do something really silly you should pretty secure!

To go back to your example above, if you build SQL queries with an ORM (or something else equally safe), then SQL injection vulnerabilities like the one above are very unlikely to occur.

For example, the Django equivalent of your code above would be:

where = request.GET['filter']
MyModel.objects.filter(contains=where)

Although it would not run the query immediately (its lazy) AND it would cache the results when it did run the query.

The code above is safe from SQL injection as

where

would be properly escaped when the query is built.

That link is interesting - its easy to forget about the need to secure the entire stack.

[graeme_p]

Sorry messed up code example:

where = request.GET['filter']
queryset = MyModel.objects.filter(filter__contains=where)

After that

queryset

is an object which will run the query when required (e.g. if you iterate over it, or cast it to a list etc.)

[ergophobe]

Yeah, I think we're in agreement there

ergophobe:
>>protecting people from their own idiocy.

graeme_p:
>>Unless you do something really silly

:-)

[graeme_p]

There are limits to how much you can do it though :) -especially if they are writing code.

You can provide a safer system, but if you think something is foolproof, you have just not found a big enough fool yet :)

[lorax]

>> can provide a safer system

Which begins to enter the M$ mentality of doing everything for the developer. :)

In a way, the WordPress approach is much like parenting. They don't prevent you from shooting yourself in the foot (or crashing the car) but they do provide guidance and do their best to create an environment that allows both freedom & responsibility for doing the right thing.

[ergophobe]

Which begins to enter the M$ mentality of doing everything for the developer.

Well, I would say that the problems MS has had are in fact that they provided such an open architecture and exposed so many APIs and so deeply. It's actually a good analogy to Wordpress - Microsoft made it easy for developers to hook into Windows at a fairly low level which helped fuel the adoption of Windows in the developer community, but because that open architecture offered few constraints on developers, the opportunity for security holes resulting from apps was significant.

Where Microsoft has gone is somewhat analagous to the frameworks graeme_p mentioned - better security model in general, but because of a need to support legacy code, there's still a lot of room to hang yourself. Similarly, the problem with any framework like Symfony is that you can't expose Symfony to a developer without exposing all of PHP, so a developer can use Symfony but just decide to accept unsanitized input or to write his own authentication routines and you can't really lock that down.