WordPress has achieved the complexity promised by Zawinski's Law, and is a true nightmare to attempt to secure. Not only do you have software which writes its own full URLs (including the scheme), you have software which checks and optionally triggers a built-in cron with every request, one PHP file which rules them all, an average of four cookies for every visit (which messes with some caching attempts), a mish-mash of JS and CSS files, static assets spread throughout the wordpress base, every plugin, and every theme, executable PHP in the DB...
It can even install its own plugins, if you give it the credentials to FTP to the server which hosts it.
I'm glad this project is nearing its completion. The promises made by Wordpress to content creators is backed by the nightmares of system administrators.
Zawinski's Law: “Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.”
Dear WordPress Sysadmins:
You still have some work to do in securing your site. For example, 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 from your somewhat verbose headers.
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?
* MVC frameworks written in PHP. For example Yii, CakePHP, Laravel, Symfony, CodeIgniter and Zend Framework
* 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
> 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.
`/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.
or maybe that's just what they want you think...
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.
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.
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.
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.
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.
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)
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.
Actually, for as simple of a task as it is, I'd consider it to be low hanging fruit.
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.
If it's asking for FTP credentials, you need to fix your file permissions
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:
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.
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.
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.
> 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.
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.
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 , setting cookies which make the user vulnerable to any number of interception attacks. It will happily suggest  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 .
> 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?
 SSL Administration requires the manual configuration of wp-config.php files: http://codex.wordpress.org/Administration_Over_SSL
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.
WordPress is a great way to organize content on the web and has a robust developer community. It's always improving. Love it!
Their theme is called "Phoenix".
Being a "small time" WordPress developer I'm always fascinated by "big media" implementations of WordPress, and their decided upon hosting/server setup.
Can't say I'm thrilled with the new Wired.com design (those category icons...ouch), but it's always been somewhat of an ugly duckling, and I'm happy to see they're still taking changes.
> Wired merges 100k posts, 12 databases, and 17 blogs into 1 WordPress install
"When I took over as editor in chief in 2012, WIRED had an archive of more than 100,000 stories. That’s good! But they were spread out over -->more than a dozen<-- different databases, sections, and homepages tenuously connected by virtual duct tape and chewing gum. "
> when we migrated 17 active WIRED blogs into a single WordPress install
Isn't there some kind of rule somewhere that says 4 fonts max? On the homepage there are seven different fonts! And then you click into a link and blammo, you're hit with this crazy antique looking thing that looks like porcelain shaped words, but with far less class. Is this a technology site or a site on fine cigars and expensive yachts?
Its unreadable and seriously needs to be addressed. Just some dire constructive crit for such a great publication. This will turn away users, if only subconsciously.
Not sure if I like the idea of a dynamic news feed. It's one of my least favorite "features" of Facebook given that I have a harder time filtering what I have or haven't read. Seems to be the way the modern web is heading though. At least looking forward to see how Wired's implementation of it works out.
Btw, I'm a PHP developer.
Please, Wordpress content editor is nothing special from a UX stand point. Clients are just used to it,that's why clients ask for Wordpress.
I like how Ars Technica handles their layout. Its dense, not overly white, column based, and with a nice background gradient that keeps all that white at bay.
* The Customer Service link is broken.
* It doesn't say what you'll pay after the initial $5.
* It doesn't explain the GQ promotion. Is it 5 issues, $5 for 6, something else?
Also, it would be re-assuring to see the to-be-billed amount near the Subscribe button. Because of the other issues on the page, I don't quite trust the header which is just an image made by a designer.
I was interested enough to click but too unsure to follow through, so hopefully someone from Wired/Conde will see this and fix some of these issues.
Drupal has much stronger community than WordPress & Joomla for example, and I think this has to do with keeping all extensions in one place and discouraging premium ones.
This way all developers can get whatever they need, but because of Drupal's "complexity", you there is way less crappy code written by people who are just passing by, as in WP/Joomla.
The Drupal pumpers I always feel are just highly opinionated techno-files, and somewhat insufferable to debate with. I think most are scared of learning new technologies, and none of their opinions are based on developing solutions and workflows that easy to use for their clients or how people surf the web (google it).
All the drupal modules are 5 years old, have 30,000 installs, and don't actually do anything nicely that you want them to do. Go find a drupal module that is similar to Yoast SEO. Go find a great responsive template to base your sites design on for that matter. Setup a author-editor-publish workflow that someone who only knows how to use facebook and gmail can work with. Drupal is terrible for clients to manage.
At first I thought the publisher had changed their name to just "WIRE" as part of a rebranding.
- Whitelisting URL access in Nginx (though this can be circumvented since everything is ultimately executable through the root index.php, and there are a lot of intermediate URLs)
- Preventing writes to any portion of the WP install directory save uploads. Note - this breaks the option of automatic upgrades, but it prevents a lot of potential hacks.
- Overwriting theme portions you don't want to exist - for example even if never linked to, you can frequently access the comment page and get the default one. However, if you put in a comment theme PHP file and leave it more-or-less blank, you limit the potential harm coming from there.
- Disable many things in the settings.php file, like the cron, debug output, file_mod, etc.
- Cache as much of the output as possible.
- Block a bunch of the informational headers set by WordPress (though this only helps a bit; you can still identify the exact version of a WordPress site using fingerprinting)
- Run WPScanner against your site and plug those leaks.
- Limit what plugins you install to the bare minimum
- Keep everything up to date.
This is not comprehensive, and we're probably still at risk, but it's a start.
They left this up: https://www.wired.com/readme.html - But again, now too telling.
Site does not handle being secure: https://www.wired.com/
I would imagine most of the "hardening" is on the server level, and not the basic level WP security that most webmasters usually encounter.
Would be interesting to know more about how an article gets from written to published. Do the writers draft in WP and then have editors review it?
Looks like it's wide-open; that should tell you all you need to know.
The Grails app that is now Cake PHP is just a tool to aggregate content from other sources and then post it to wired.com site? And it was previously built and maintained by a single developer? Sounds like a basic tool.
I could be wrong though.
Still it seems they wouldn't have chosen Word Press, unless they really wanted some of the editorial and journalism-focused plugins and features. Some organizations swear by that stuff, and the writers and editors get used to those features. We might not interact with the features that the writers and editors love.
So, yeah, though Wordpress is a nightmare, it might still be the best choice for Wired.
If I was starting a blog with a community of writers, I might actually just use Google docs for collaborative editing, and then have some sort of publication tool that pushes from Google docs to a more streamlined custom back-end (probably written in Go since I've had a good experience with it so far).
But this is just a naive opinion of mine, based on having absolutely no experience with actual journalism and publishing. I imagine I would soon discover many disastrous aspects of my harebrained architecture.