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.

[lorax]

>> Much of the code 'calls home' for various reasons

I'm checking on this.

@bwnbwn - exactly. Big bullseye and getting bigger everyday.

@explorador - not boring.

User errors and poor maintenance/upkeep - yes - plenty of ways to leave the door open but that's not WP's issue. There will always be user error/ignorance issues - unless we automate updates - oh wait... ;)

[jojy]

While working freelance, I found a guy who was asking for wordpress plugin customization. When I asked details, he said I have downloaded few plugins from wordpress plugin site and now I want to customize them i.e. place casino links, popup, etc. You should only download popular plugins with lots of reviews.

I also noticed people download themes from unknown sites without knowing the original developer and they end up losing their hardwork because such themes contains malicious code and they are likely pirated copies.

WordPress is a great CMS and you can't complain if your site was hacked because you have installed some malicious plugins/themes.

[Storyman]

There are things I like about Drupal, but there are clients who are better suited for WordPress. I always recommend those clients to get an account on Bluehost and sign up for their pro backup program (I never recommend Bluehost for Drupal). With the pro backup program it makes for a rapid recovery from hacks and wayward upgrades.

Also recommend WordFence because it tracks users much like Drupal does. The plugin enables you to block brute force hackers. I also like that it notifies you if any core files have been modified. It does the same with most of the popular plugins. Another feature that is helpful is it lets you know when a plugin (or WP) needs updating.

Every time I've gotten a call to fix a hacked site it is because the site owner failed to update the software. What a lot of site owners don't appreciate is that miscreants program bots to determine what version of what program is installed on which sites. Once a vulnerability becomes known for a particular version of a CMS they know exactly which sites to attack.

The best thing any WP site owner do is to keep their software up-to-date, then backup their site regularly either using Backup Buddy or something like Bluehost's backup pro.

[graeme_p]

@jojy, you have touched on one of the bits of bad security design in Wordpress, which that it uses PHP as its template language, so themes get access to everything.

It is not too bad a choice when you write your own themes, but if you use other peoples, you have to trust theme developers as much as core and plugin developers.

[not2easy]

One of the simplest, most basic things people who use WordPress can do to help security is to replace the defaults for the WP sql tables. I caught several attempts at hacking over the years of working with WP just by not having any wp_ prefixed tables. It needs to be set in the wp-config file also. It is not too terribly difficult to change for an existing site, but it is simple when done for a new install. Just need a plain text editor with find/replace that does not alter the character set. I do it when I move domains to a new host also. And changing file permissions for config files doesn't hurt.

[Storyman]

@not2easy,

For those who didn't change the DB prefix when installing WP, here's a plugin that makes the task easier: Change DB Prefix

[wordpress.org...]

[graeme_p]

@not2easy, what you are saying is that you have experienced multiple SQL injection attacks that would have succeeded on a standard install?

This really should be taken care off by a database library/layer that sanitises everything without a lot of work or care on the part of the developers of the code that uses it - Bobby Tables should not be a problem: [xkcd.com ].

It would not do anything about malicious plugins, but it would mean that security flaws in both WP itseld and plugins would be MUCH rarer.

Drupal should have this (if it does not already) once it moves to using Symfony.

This thread is going a long way to convincing me that I should move my only WP stite (my personal blog) to something else.

[not2easy]

I am sorry, I have spent more time than I had available trying to find some examples, which I know I have saved but possibly on a rescued hard drive and not on the two I have searched this evening. The closest I came to the types of attempts that were foiled by just not having the standard wp_ table prefixes is this line:

[23-May-2011 17:23:54] WordPress database error Illegal mix of collations (latin1_swedish_ci,IMPLICIT) and (utf8_general_ci,COERCIBLE) for operation '=' for query SELECT comment_ID FROM wp_comments WHERE comment_post_ID = '266' AND comment_approved != 'trash' AND ( comment_author = 'kpss kitapları' OR comment_author_email = '[e-mail]' ) AND comment_content = 'Apple now has Rhapsody as an app, which is a great start, but it is currently hampered by the inability to store locally on your iPod, and has a dismal 64kbps bit rate. If this changes, then it will somewhat negate this advantage for the Zune, but the 10 songs per month will still be a big plus in Zune Pass\' favor.' LIMIT 1 made by wp_new_comment, wp_allow_comment

which was just an attempt at auto approving a spam comment. This error was not caused only by altering the table prefixes because it was also badly coded but it is similar to attempts to frame sites, images and links in auto approve comments that were prevented because wp_comments does not exist in the WP database. I would have preferred to find one of the worse attempts because several were stopped only because of the wp_ edits.

[lorax]

@graeme_p - yes, as a rule the core code sanitizes input and output. It's up to theme & plugin developers to use the tools available. As noted before, all plugins and themes go through a review process. Data validation functions are well documented: [codex.wordpress.org...]

@not2easy - I assume the attempt was via a comment form?

[lorax]

bad security design in Wordpress, which that it uses PHP as its template language, so themes get access to everything

How is it bad security design? Any db driven CMS relies on the same functionality - access to the database. How would you make it different? Or are you saying that PHP is the issue? If so, what would be the difference if the CMS use PERL or another script language?

[graeme_p]

The problem is that WP gives themes UNRESTRICTED access to the database, and everything else you can do with PHP.

The problem can be solved using PHP, by using a template language such as Twig [twig.sensiolabs.org] (which comes with Symfony) or mustache.php [github.com]

I have not used either, but Twig is based on Django Template Language so should have similar restrictions: this, for example means that the only damage themes can do is to delete unfiltered sets of data, which is likely to be very obvious (it cannot UPDATE, or SELECT).

Mustache looks even better, and does not seem to allow any alteration of data from a template at all.

Neither would allow the template access to variables outside the template, or to read or write files, etc.

as a rule the core code sanitizes input and output. It's up to theme & plugin developers to use the tools available

The problem is that it takes an effort to sanitise the output (you have to bother to use the tools available), whereas a good database access layer would sanitise by default and a developer would need to make an extra effort not to sanitise. I use the Django ORM and it does this consistently - and other layers of Django are similar - e.g. CSRF protection is turned on by a single setting, and you then have to deliberately remove it where it is not appropriate.

From what I have read of their documentation there are PHP frameworks (and standalone ORMs) that do the same.

The problem is not PHP as a language, but PHP as a platform by itself. A PHP framework is fine.

[lorax]

Thanks for the explanation. What you wrote makes sense.

So the issue isn't with data pass through from the theme (creating a post for example) but the theme itself modifying the database. Just thinking outloud here - I wonder if this would limit WordPress in some other aspect unintentionally.

Thanks for the Twig & Mustache mentions. I will look into those resources.

[explorador]

I believe graeme_p is talking about templabes going in one place and then being parsed or merged with the code, something WP doesn't do: the templates are PHP files. Not every CMS treat code and templates the same way, I came across a few who didn't (in the past) but I moved permanently to Drupal, WP and my own CMS. From a developer standpoint it seemed easier to me to build my cms around code templates but at the end I decided not to, my CMS work with code in one place, HTML in other and CSS elsewhere. Not saying is perfect but depending the situation or CMS it might work better.

I was playing with Symfony a few weeks ago (I'm still stuck) but I did see the benefit of having cod in one place and templates separated.

As for the DB access I totally agree, that's how it works and security depends on cleaning inputs and protecting the database, something not quite easy as it sounds.


Errors and refusing connections, etc... It's funny but a long time ago I stopped protecting data and code via refusing connections or displaying error messages, my cms are quiet in that sense, why? because many hacking attempts go that way, trying and trying, trial and error. Returning error messages or permission errors it's often a good way to guide hackers. I have received attempts that were refused but my code doesn't return any errors so the attempt comes and then goes away, doesn't work for everything but it does work for a lot of situations.

[graeme_p]

Small typo - it should read "the only damage templates can do". Obviously, if you based a theme system on a template engine the same would apply to themes, but the template languages I mentioned do not deal with themes as such.

[graeme_p]

To expand on what explorador said, templates should be written in a different, restrictive language. This typically allows you to display information passed to the template from a view function, but does not allow you to write database queries, or set variable outside the scope of the temple, or open files, etc.

Look at the Sjango template language or Twig documentation to see how it works.

[4serendipity]

I think ergophobe's post does a great job of summing things up, especially if you want to think about wordpress vs. drupal.

Wordpress just wasn't create by developers as skilled and security-focused as those who created drupal, so it's been a bit up an uphill battle to get it up to snuff.

Wordpress may have (and I think that they, in fact, have) improved security a great deal. With this being said, there's still quite a bit of room for improvement, and wordpress could stand to learn much from drupal in this area.

The level of oversite that modules receive in drupal is perhaps its biggest advantage.

Another great thing about the drupal security team is that they are quite transparent and tend to provide useful descriptions of the vulnerabilities and patches. Oftentimes, the vulnerability and patch aren't applicable to a specific installation, since the vulnerability might require that anonymous users be given a particular permission, for example.

Wordpress, on the other hand, tends to take more of a 'microsoft' approach to things and simple rolls out updates and tells everyone to blindly update ASAP.

[Storyman]

WordPress vs. Drupal

Of the two Drupal is my favorite. There are two disadvantages though.

First, there is a step learning curve to Drupal.

Second, if you are installing on a virtual server (like Bluehost) you are limited on the number of installations--even if you're using a multi-install. WordPress on a basic installs creates around 10 database tables, whereas Drupal creates over 300 db tables on a basic install. On both systems the number of tables increases with plugins/modules.

The problem is that hosting companies (like Bluehost) limit their basic multiple hosting accounts to 1,000 tables. So, at most you'll be limited to 3 installs of Drupal versus over 50 basic installs of WordPress.

As for free WordPress templates. Some of the coding is sloppy and insecure. One thing for sure is that every one that I've installed for a client has had errors with CSS--every one. Usually they also do a poor job with SEO.

In most cases free themes are used by designers to promote their work. If they have problems with CSS, I can only imagine that they don't do any better with PHP.

[ergophobe]

@Storyman

There are things I like about Drupal, but there are clients who are better suited for WordPress.

In the vast majority of cases where someone wants a simple site where he will be able to edit content himself, I recommend Wordpress. It is the best thing out there for simple use cases. I am not debating the relative merits of WP versus other systems, but commenting on what I see as a weak point in WP "security ecosystem".

@lorax - for examples, see my previous posts. One more example - people always complain that Drupal updates are harder than WP updates and the answer has always been that the Drupal core developers have always said that they do not feel they can ever make an auto-updating script secure. There is always a tug and pull between security and convenience and WP has always leaned toward convenience. That is NOT a bad thing - it is the major reason for WP's success. But it is also something that is baked into Wordpress culture.

Also, compare the results you get for the following searches

• Apache Security Team [google.com]
  
• Ubuntu Security Team [google.com]
  
• Drupal Security Team [google.com]
  
• Joomla Security Team [google.com]
  
• Wordpress Security Team [google.com]
  

Note that the result with the title "Wordpress Security Team" is an absolute crap 8-page mini-site.

I don't think you can look at those results and say that WP is a security-oriented as other major open-source projects.

a template language such as Twig

Actually, the next version of Drupal will ship with Twig as the default templating engine, primarily for security segmentation (you can give designers full access to the templating engine without also giving them access to the full gamut of PHP, and thus the ability to inject things in the DB or simply bork the site accidentally.

[edited by: phranque at 12:55 am (utc) on Nov 6, 2013]
[edit reason] fixed some urls [/edit]

[lorax]

@ergophobe - which previous posts?

Links on your list all point to the same SERPs.

I've posted the question about a security team/protocol over on the WordPress Forums. [wordpress.org...]

[phranque]

Links on your list all point to the same SERPs

combination of 2 problems:
- google's ill-advised use of fragment identifiers in urls
- how the forum software handles urls with fragment identifiers

i hacked the search urls in ergophobe's post so they work now.

[ergophobe]

Hmm... some cut and paste errors there I guess

Try these

Apache Security Team - [google.com...]

Ubuntu Security Team - [google.com...]
Drupal Security Team - [google.com...]
Joomla Security Team - [google.com...]
Wordpress Security Team - [google.com...]

Again - the difference between what you see in the Wordpress community and what you see in the other open source communities is striking.

As for the previous posts - I'm referring to the same ones that 4serendipity references.
- 6:17 pm on Oct 30, 2013
- 3:28 pm on Nov 1, 2013 (PT -8)

[RPMedia]

Still we have more then 50 websites with using wordpress cms, here we never faced such security issues. But I heard sometimes wordpress websites are hacking for plugin issues. I'm not sure which plugins you are using for, but make sure your used plugins are safe to use.

[lorax]

I'm finally getting somewhere. While a Google search may not yield good results, an onsite search at WordPress did.

WordPress Security Team - [wordpress.org...]

Also was pointed to this article by Jason Cosper, self-described @WordPress geek for WP Engine: [wpengine.com...]

[explorador]

Thanks graeme_p for expanding, that sounds more clear.

Still we have more then 50 websites with using wordpress cms

That's good to know. I had half of that over the years and only two had security problems, no plugins, no nothing.

The thing is not only security itself (by the code) it's also about exposure on subject, topic, ideology (as for any other website). The company I worked for is a media company and this includes a huge newspaper, this is why the old sysadmin refused to use WP because there were many daily attempts to hack diff websites including the newspaper, but they went mostly after the digital magazines and ads-like-sites.

In other words certain works will put your cms on the spot and to the test, be it Joomla, Drupal or WP. I don't know why but the country management decided to use Joomla as their default CMS and whoa, many webs went down time after time. I had the chance of developing one for them but I used Drupal, no problem. Anyway is not about WP vs Drupal, as I said before I have used WP in several cases.

[lorax]

I finally uncovered some real numbers. In a preso given by Andrew Nacin, Lead Developer of WordPress.org.

The WordPress Security Team consists of:

• 25 experts including lead developers and security researchers
  
• About half are employees of Automattic (Matt Mullenweg's company)
  
• A number work in the web security field
  
• We consult with well-known and trusted security researchers and hosting companies.
  

Source: [slideshare.net...] (slide 16)

Slide 17 explains their process for handling issues when they are uncovered. General rule of thumb is there's a plan for a fix within 48-72 hours. This does not include the proactive work they're doing.

It's worth noting the famous one click upgrade has made it extremely easy for anyone to keep their WordPress install up to date. Which also applies to security patches.

[lorax]

>> Wordpress allows direct editing of files on the server from the admin interface.

Can be disabled in the wp-config.php file.

define( 'DISALLOW_FILE_EDIT', true );

From: [codex.wordpress.org...]

[incrediBILL]

Can be disabled in the wp-config.php file.

Irrelevant.

If I already have access to the admin control panel I can possibly add a new plugin and if so, it's game over. Even if I can't add a plug-in, I can edit pages and any opportunity WP allows someone to insert PHP code in a page or post, is an open opportunity to hack. Those WP plug-ins that allow PHP code in posts offer a lot of customization opportunity, including free services from your friendly hacker.

Having .htaccess password protection over WP admin making it double tough is the only way to fly IMO.

BTW, if you don't think people can hack at your site unnoticed, I do debugging work on live servers all the time and my code is wrapped in a conditional for my IP address only so the rest of the world is oblivious to what's happening.

Just to be cheeky, my tagline on my personal WP site is a slight modification of the default and says "Just another WordPress site waiting to get hacked."

With that said, I think in general WP out-of-the-box is reasonably secure for the most part but it's also reasonably bland. The more useful and flexible you make WP with plugins the more vulnerable you make it, simple as that. I like to call it "Plugin roulette".

If WP is just a blog along side your main site, I'd recommend jailing it in it's own account something and use DNS and CSS magic to blend the sites together. Using WP hosting service makes it even better as they're experts in securing it, you're not.

If WP is your entire site, harden it best you can and brace for impact.

Do your due diligence on all plugins and you should be OK.

[lorax]

>> Irrelevant.

Not irrelevant! It's relevant when we're talking about stupid users attempting to edit the code using this option. This shuts them off.

[ergophobe]

It is, however, once again indicative. This should be off by default. And as Bill points out, if I can add a plugin straight from the admin panel, all I need to gain access to the server is one stupid user on one account with a published username (probably in the byline) and a weak password.

Again, I am not anti-Wordpress. It's my first go-to tool for a simple site. It is *wonderful* tool for it's simplicity and convenience. I love it's convenience. However, that clear bias toward convenience implies a bias away from security.

And again, I am not saying it is a *bad* thing. It's just a thing. But it does make Wordpress less secure than other open source projects that are willing to impose more inconvenience in return for more security, but those other projects pay a price in terms of usability, adoption and overall hassle.

I think this is appropriate:

Why, then, 'tis none to you, for there is nothing either good or bad, but thinking makes it so. To me it is a prison.
-- Hamlet in Hamlet, Act 2, Scene 2

[Storyman]

@ergophobe,

We're on the same page for WP. If WP users want to sleep at night, then B-A-C-K-U-P! And frequently.

A Wordfence feature that is helpful (beyond upgrade notifications) is that core files can be compared with their depository and any changes are highlighted in a side-by-side comparison of installed core files and those in the Wordfence's depository.