Hacker News Reader

While I agree with the overall assertion that Wordpress is ridiculously bloated, slow and insecure, a lot of the specific things you mentioned have nothing to do with it and actually are pretty sensible features for websites of a certain size.

For example, the built-in Cron thing is invaluable for smaller shared hosting installations, which do not allow you to schedule actual Cron jobs. Moreover, it allows you to copy Wordpress (or unroll if from a database backup) without having to worry about recreating those Cron jobs.

Not everyone has root access to their hosting. Heck, not everyone has shell access to their hosting. Even people who do do not always have time and expertise to set up, maintain and use Docker/Puppet/openVZ or whatever you use for sysops.

one PHP file which rules them all

What do you mean?

> What do you mean?

`/index.php` is the default handler for most requests which go through Wordpress, so even if you block access to a .php file further down the tree, there are generally ways to gain access to that file via `/index.php`.

> the built-in Cron thing is invaluable for smaller shared hosting installations

I don't disagree that it's useful; after all, reading Email is a useful feature for quite a few different pieces of software. The problem lies in that features like this also makes larger, dedicated hosting installations significantly harder to secure, and opens up a number of potential attack vectors.

> Not everyone has root access to their hosting.

No. And again, what makes a piece of software valuable for an individual can make it a liability for a corporation. Since I work for a corporation, having to deal with WordPress is a pain.

I don't understand why you say WordPress is difficult to secure. Just disconnect the ethernet cable, turn off the wifi and lock the machine in a steel box. Or you can go with absolute security and just disconnect the power cable from the machine; problem solved.

He/she is referring to WordPress' use of the Front Controller design pattern (http://en.wikipedia.org/wiki/Front_Controller_pattern), which of all the things about WordPress you could choose to hyperventilate over seems like a strange one to go with.

Isn't this a decent amount of PHP frameworks? I mean taken from the Wiki link;

* MVC frameworks written in PHP. For example Yii, CakePHP, Laravel, Symfony, CodeIgniter and Zend Framework

* Drupal

* Microsoft's ASP.NET MVC Framework.

* Spring Framework

* Cairngorm framework in Adobe Flex.

* Yesod web application framework written in Haskell.

So is this a knock on WordPress, or any application that uses the Front Controller Pattern

Looks like that's the one.

> which of all the things about WordPress you could choose to hyperventilate over seems like a strange one to go with.

Straw, camel, back, etc. Anything that makes it harder to secure against access against arbitrary code execution makes for an aggravating day.

"I can tell just from your headers that you're running on Apache 2.4.6, on PHP 5.6.6, and using Varnish 4 as your caching mechanism"

or maybe that's just what they want you think...

Everything you say about Wordpress is totally true in my experience. But I expect this team is in a much better position than most Wordpress hosts in terms of security potential.

For the scale of someone like Wired, I expect they have an internal network they can restrict the administrative interface to. And I would also presume they are doing some aggressive caching to a CDN or to some sort of dedicated public-facing servers that. There's no reason to even worry about letting Wordpress itself respond directly to user requests. Or if they do, they can trim out the riskiest bits of code--no reason to run a vanilla install. This sort of separation would pretty much negate the standard issues with Wordpress's security.

Nope:

http://wired.com/wp-admin

It would be hilarous if that was a honeypot that led to a completely useless, sandboxed admin panel..

I think you are far too confident about the usual business approaches to security.

I never said I thought it was likely. But for a Wordpress site it would be funny.

Security by obscurity. Yeah, that's a valid strategy.

Let's listen to security advice from the person who thinks obscurity means anything. :-)

Obscurity gains you many things. It gains you protection from non-targeted attacks. Sure, for Wired this means less, but if you're not Wired, moving your SSH port will reduce the number of drive-by attacks made against SSH.

Removing the version from your headers will reduce the number of "use Google to find vulnerable wordpress versions", and require an attacker to expend significantly more resources to identify vulnerabilities in your site.

Obscurity means you only have to worry about being directly targeted, not randomly targeted. It certainly won't make you secure, but neither does it reduce your security, either.

> Let's listen to security advice from the person who thinks obscurity means anything. :-)

People shouldn't publish their login credentials on the net.That's security by obscurity. If you think of an alternative to that,let me know. Security is a matter of layers. The more layers you add, the more secure it gets. A smart thing to do is not to choose site.com/wp-admin.php as an admin URL accessible all over the net. Unfortunatly WP makes it very hard not to do that.

Using WP is bad for small businesses that think WP makes webdev easy,because it tends to promote non secure habits for the sake of easy installation and use. WP is bad for big businesses because it's an serious attack vector. WP is good for security consultants on the other hand that make quite a lot of money fixing all WP security flaws,basically rewriting a good chunk of the CMS.

> WP is bad for big businesses because it's an serious attack vector.

That's FUD. WordPress is not hard to secure if you follow some best practices and do not use crap plugins.

That said, one would hope with the projects budgets that big businesses offer to agencies that agencies would hire competent people to build their sites.

Full disclosure: that's what we do; build WP sites for agencies on behalf their big business clients.

I'm not aware of an security implications of knowing the application version.

If it's properly patched, it doesn't matter if the bad guys know you're running the patched version.

If it's not properly patched, automated exploit attempts will succeed whether or not they can see the version number.

It's simple: "No Easy Buckets".

Yes, some people just want to compromise a lot of sites, and don't care what they are. Those attackers will just blast huge swaths of the internet with an automated tool. But there is a spectrum of attackers, and "someone who only uses an automated tool" is just one extreme of it. Many attackers want a specific site, and Wired is a good example of a high profile target that attracts that kind of attention.

If you are telling me your version number, andthere are known CVEs, but an automated exploit seems to be failing, I will try other things. Maybe there is a WAF or IDS in place I need to evade. Maybe there is an encoding issue I can use to work around it. Maybe its just a honey pot and you are lying to me about the version number. Or maybe there are no known issues, but I take the version number and go look at the source...

Your security posture should not be "I don't think this will help an attacker, so its OK". It should instead be, expose as little information as possible for the site to function.

(Update: Years ago during an audit, I found a version string inside an HTML comment. The software was open source, and I learned that this version stored sensitive data in an oddly named file in the web root. This sensitive file was not on a list of juicy files like what you find in Nikto or a similar tool. The version number is what did it. Granted, this was a targeted attack, but Wired is the type of site that gets targeted attacks from determined attackers who do more than run w3af or Nikto or Nexpose with default options)

> If you are telling me your version number, andthere are known CVEs, but an automated exploit seems to be failing, I will try other things.

But that has nothing to do with you knowing the version number. The problem there is running an old version with known CVEs. In that scenario you're vulnerable whether the version number is public or not.

Keep your software up to date and it won't matter if an attacker can get the version number, because all it will tell them is that there's no old exploits they can take advantage of.

It is not a given that an older version will be unpatched. For example, RHEL (and by extension CentOS) backports patches without updating the version number.

Ok, you have a good point that version numbers do have a security implication.

However, I'm now going to say something a bit different and claim that it is what I meant the whole time. ;-)

Hardening applications, like any development, is a matter of focus, and I would argue that hiding version numbers should be pretty far down the list of priorities.

In your update example, the real problem is that the software stored sensitive data unsecured in the web root. Solving the problem would mean patching the software so that the sensitive data is properly secured. Once that's done, it no longer matters that you know the version number.

So: I agree with you that version obscurity can help, but I think it's only a little. I think most teams can find more productive ways to spend their security time.

> Hardening applications, like any development, is a matter of focus, and I would argue that hiding version numbers should be pretty far down the list of priorities.

Actually, for as simple of a task as it is, I'd consider it to be low hanging fruit.

For Nginx:

    server_tokens off;
    fcgi_hide_header via;
    fcgi_hide_header X-Powered-By;

etc.

> It can even install its own plugins, if you give it the credentials to FTP to the server which hosts it.

If it's asking for FTP credentials, you need to fix your file permissions[1]

  [1] http://codex.wordpress.org/Changing_File_Permissions

Here's the problem with that - most of these recommendations are for convenience, and tend to run counter to security recommendations.

Files and directories on a web server should never be owned by or writable by the web user. They typically don't need to be world readable either (if they are, and your web server is compromised, then you start to leak a lot of unrelated data out over the compromised service).

Here's a pretty minimalistic list of recommendations worth looking at on properly securing a web server:

http://resources.infosecinstitute.com/securing-linux-web-ser...

Yep. Welcome to administering systems for a web site. There's always a trade-off between convenience & security. If you make it hard for people to install plugins, they're not going to use your software (or your server).

If you add "define('DISALLOW_FILE_MODS', true);" to wp-config.php, it removes the ability to install themes & plugins through WordPress itself. Then it's more like a traditional web application.

WP is a perfectly fine tool for many scenarios. There's something nice about having a blogging platform that's easy to install and use. The problem I see if that this blogging platform gets shoe-horned into a CMS-like role with half-assed extensions and modifications, many of which are written by amateurs running a freemium-style model and often have little to no community source code review. I find popular extensions are okay, its just when you start looking at more obscure stuff because now your WP needs to be Drupal-light and SugarCRM-like that you run into trouble. WP is pretty much a victim of its own success. Lots of people have made sure the Wrong Way to do things is easy in the WP ecosystem and that hurts the core product.

I'm really surprised to see a site that gets as much traffic as Wired using WP. I could see Drupal taking this role. Drupal, of course, is not without its faults. I've been part of a few Drupal roll-outs and have done development on it, and my god, there's an ugly learning curve here. If money is an issue, you can get a decent WP dev a lot less a Drupal shop would charge you. I imagine Wired, being a print magazine in the age of dying print, probably didn't have a big budget.

Personally, I'd love to see something as solid as Drupal but with the ease of WP. Maybe this middle ground is impossible, but it would be nice to whip up a Drupal instance and have certain roles or templates ready to go, like WP does. Instead, stock Drupal is pretty much nothing out of the box and the dollars/time involved to make it something usable and finished can be significant.

>an average of four cookies for every visit (which messes with some caching attempts)

That's a trivial fix in Varnish. I run Varnish in front of WP for my own personal blog.

>, I can tell just from your headers that you're running on Apache 2.4.6, on PHP 5.6.6, and using Varnish 4

If that's the worst sin they've committed, then I'd say they're doing pretty well. Securing WP isn't that tough. I find most LAMP apps are security nightmares and WP is just the posterboy for this and because of its popularity gets all the attention. If you're not running an IDS/IPS and locking down WP, securing permissions on your server, running SELinux, etc then you're just asking for trouble.

I used to feel pretty confident about Drupal from a security POV until SA-2014-003. Considering how bad that was, it scared me a bit and makes me wonder why no one can make a CMS without major security issues in this day and age. I need to do the same amount of locking down with Drupal as I do WP. From a server admin role, there's not much difference between the two. I still need to do all that security stuff and admins who say, "Oh Drupal is secure I dont need to do that stuff" are the ones who are going to continue to get burned.

> That's a trivial fix in Varnish. I run Varnish in front of WP for my own personal blog.

Yup. We use Nginx, but do something similar. However the point remains that it's something that you have to identify as a problem and secure in the first place. All of the fixes are relatively trivial, but tracking down and solving a hundred trivial problems quickly becomes a big mess.

> If that's the worst sin they've committed, then I'd say they're doing pretty well.

Agreed.

> Securing WP isn't that tough.

I disagree. Sure, you could follow the dozen or so different recommendations on the web for securing WordPress, but that only gets you to 90%. That remaining 9.999% is much harder, and is going to depend heavily on how you're using WordPress. As a result, you'll have to be intelligent about which threats this opens you up to, and the best ways to work around them.

I think your latter point is true, but it pretty much applies to any LAMP application. Maybe there's slightly more hair-pulling with WP. I still need to do the same amount of legwork with Drupal. Sure, Drupal's major exploits are less rare, but they do happen. There's no bulletproof CMS and if you believe in bulletproof software, you probably shouldn't be administrating a server.

WP wakes people up to the work they should have been doing in the first place. Grumbling about setting permissions, locking down directories, using captchas/honeypots, doing timely updates, running an IPS, running mod_security, etc because "its WP" is unfair. You should be doing those things to all your web applications. The wild-west of the web needs to end. If WP is the wake-up call for securing LAMP servers, then that's actually good in the long run.

> WP wakes people up to the work they should have been doing in the first place.

Well, not really. WordPress doesn't wake anybody up about anything if they are not already security conscious. It will happily serve wp-admin files over a non-SSL connection all day long [0], setting cookies which make the user vulnerable to any number of interception attacks. It will happily suggest [1] you make your WP files all writable by the web server user, to simplify the act of upgrading WordPress. It (with a simple plugin) will be happily allow "authenticated" folks upload anything they want to your S3 account and serve it from there [2].

> There's no bulletproof CMS

Actually, there is. It's a CMS which generates static files for the webserver to serve to the public. Sadly, I haven't located it in the real world quite yet. Anybody care to disrupt the CMS scene on behalf of beleaguered sysadmins?

[0] SSL Administration requires the manual configuration of wp-config.php files: http://codex.wordpress.org/Administration_Over_SSL [1] http://codex.wordpress.org/Changing_File_Permissions [2] https://wordpress.org/plugins/amazon-s3-and-cloudfront/

> Sadly, I haven't located it in the real world quite yet.

Static site generators were popular about 10 years ago. I inherited a legacy install of a popular one called Collage. It was more or less a nightmare to work with and a PITA compared to what you can do with a proper CMS. SSG's aren't the solution for most, if any, modern cases. You more or less have all the problems of a CMS, save security, and all the headaches of a deployment system in one, without the ease of things like add-ons or extensions.

A lot of your dynamic stuff will be custom code, so you have all the security problems as well, except without a worldwide community of coders reviewing your stuff. I've seen what jr webdevs or rushed sr devs do and its horrible. I'd rather take my chances with WP. From a monetary perspective loading up a module is much easier than constantly reinventing the wheel.