As someone who has just spent the last two weeks attempting to secure and standardize a WordPress install, my sincerest condolences to Wired's system administrators.
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.”
EDIT:
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.
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.
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.
`/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.
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.
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.
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)
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.
> 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.
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:
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?
> 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.
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.
In a world where end-user nav is an afterthought and 'flat' is being slapped onto every site/app/ui despite readability or contrast issues, I'd say Wired's fugly as hell theme is par for the course. Perhaps even...an improvement.
"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. "
http://www.wired.com/2015/03/our-new-site/
I'm in literal shock over the fonts. I've never seen something so high-profile so badly designed, typographically.
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.
Yeah, the typography on this is pretty bad (way too many fonts), but the thing that really strikes me is how generic the site looks. The old design was very identifiable as "Wired", this new design looks like any other news aggregator.
I actually like the fonts and clean-ish appearance, but just like so many others, they broke page-down with their big, fat, floating top div. There's apparently a way to fix it with JavaScript -- nytimes.com eventually got it right -- but I wish people would stop adding these things.
I love how much faster the new site feels. Seems like before I'd load it up and some content would take 30+ seconds to load but everything I touch on the page all but leaps out to respond to my click. It's pretty wonderful and a welcome change.
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.
Having only recently begun to poke around at the Wordpress Multi-Site database layout thanks to having to take over responsibility for an 8000+ blog morass of an install, I can say that the hacky way in which Wordpress achieved multi-site capability would actually make this transition relatively simple. Other than ensuring user IDs in the database were in sync, the core blog tables themselves just need to be imported with slightly tweaked names, since each sub-blog in multi-site WP has its own independent set of tables.
If you were to look at all those times that PHP is cursed either for its speed or programming or something else, I am surprised these big websites are still investing in something so buggy.
Throw enough caching at a speed problem, and the speed problem effectively goes away. This is why the terms "Varnish" and "fcgi_cache" are so well associated with WordPress installs.
You are absolutely correct - caching solves the apparent speed problem to the end user, not the underlying cause of the speed problem. That said, solving the apparent speed problem for the end user is frequently enough.
As a PHP developer who has worked on several Wordpress installs as a freelancer, I can assure you companies don't invest in Wordpress because they're interested in security or speed, but so they can pay as little for the development and maintenance as possible.
WordPress is also very popular among content folks, on account of its well, content management features. Not to mention the strength of the editor, and easy extensibility. You could tap away in your terminal for a year making the new and best node.js or Go editor and by the time you were done you wouldn't be close, and WP would have moved the goalposts again. And let's say you were successful and had created a great content management system. Then you'd have to train your editors and your social media folks and they'd STILL hate it and quit and you'd have to train a new batch of editors, except, oh, you just got the opportunity to work for a company that doesn't make you spend a year re-implementing a blog from scratch and jumped on it, and now nobody knows how to get the website to let them embed a Vine? Man we should have just gone with Wordpress.
Well, I personally don't want a "special" UX in my editor. In any case just about every WP point upgrade has brought editor enhancements, so if you haven't used it recently you won't have a good basis of comparison. (e.g. 8.1 with distraction free mode – not for me personally but I've seen writers oooh over it.)
Whoa, did they use the same developers? The sites look very alike. The top navigation, squared layout, lots of white space, etc. Maybe this is the current design fad. Can't say I'm in love with it. I think all the spacing and heavy use of white space tries to mimick a print-like look, but on a screen just looks inefficient and bloaty.
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.
* 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.
To be fair to Wired, I have a good idea what a magazine subscription should cost. :) I just think they haven't considered that hiding the price and agreement on a payment form signals an unintended negative impression.
Wired.com also upped their ads from 3 to 5 on their homepage. Also page design is to make squares exactly match high value ad sizes. Almost as desperate as Pandora's two ads in a row that started happening the past few months
One of the main reason I am using Drupal and not WordPress is that the WordPress community seem to prefer more paid "premium" stuff over FOSS ones. Take Drupal Commerce for example, you have access to all of the plugins but you only need to pay for support. For wordpress, it's a completely different story, either pay for a full version of woocommerce with all the bells and whistles, or stick with using the half-baked "basic" version, lacking crucial features. While I understand the need for monetization, for startups and new companies this model is very pricey compared to the Drupal one.
I'm currently administering a Drupal site and plan to migrate to WordPress. One of the big reasons is that, every time I look for a solution to a Drupal problem that someone else has solved via a module, the best I get is something that only works on version 6 and hasn't been updated for two years. Whenever I check for similar solutions on WordPress, I almost always find something up-to-date that solves my problems. I'll gladly pay $50 for some premium plugin so I don't have to write my own. I've got plenty of other things to do in the day.
Perhaps biased since I work for WooThemes but I disagree. First of all WooCommerce is free. What you need on your site is not needed on all sites. There is no "basic" version of WooCommerce. There is only one version and what you need on top of that is up to you. Extensions can be purchased from our marketplace or several others, but that's optional. There are free ones on WordPress.org that provide what you're looking for that are free but you will need to pay for support. WooCommerce itself works the same way. You also have the option to develop what you need on your site.
Good points; however, this is not only important for startups and new companies, but for the community itself.
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.
I would agree. I work in a large organization that shoves all websites into drupal, and provides our non-technical clients with solutions they don't like using.
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.
As someone who has just gone through this process, it consists of a number of steps:
- 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.
I have no inside information, but there's a lot of things you could do by simply avoiding the built-in commenting system, and exposing the admin tools only to an internal network. You can pretty aggressively prune down the Wordpress install footprint/attack surface on your public-facing servers if you are willing to do some minor patching. Not to mention, a reverse-proxy layer in front of Wordpress can let you filter out the most obvious attacks and block lots of potential ones without touching the code itself.
You might add in there testing your plugins as well. Pretty much all of the WP security warnings are due to vulnerable plugins people are using without testing and leaving themselves exposed.
I wonder if they are building their own "longform feature article builder" or if they'll be using something like the Aesop Story Engine Wordpress plugin.
Was about to post the same thing. It contrasts with everything else on the website in every way. I'm actually really curious what the rationale could possibly be.
It is weird since the two main fonts seem to be fighting with each other. The main wired font has always been blocky/techno/sci-fi, and this new headline font is trying to look like a newspaper font from the 1920s.
On this page at the bottom there is a bug in the rendering of the boxes with other articles, the word 'newsletter' partially overlaps the box next to it (firefox).
I don't mean to be snarky, but is there something terribly interesting going on here? The only bit that seemed somewhat interesting was the "AI page curation" tool, but they hardly touched on that other than to mention that it was a Grails application, which was then ported to CakePHP, which was then ported to be a WP plugin.
I agree. This all seems fairly basic, and from clicking through the site for 15 secs I was able to find a lot of bugs. For example, when reading the linked blog post, the social media bar scrolls and then re-anchors to its spot on the page on chrome 40.0. Reading through the other comments it sounds like there are many bugs throughout.
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 never realized there would be so much junk to haul through when trying to upgrade websites to these modern interfaces. It makes me wonder if this problem of really bad code is widespread in the industry or just among amateur web developers.
Rome wasn't built in a day. Any product that's been around for 10+ years accumulates a lot of "junk." The thing is, it wasn't always junk. Eight years ago it was the best thing, it just hasn't been updated since then (aside from patches and bug fixes, as mentioned in the article).
I wish they had a section where you can see all the articles in chronological order (newer to older). they made a latest news section but it doesn't look ordered.
They don't have a lot of data to serve, though, I imagine. You can store a lot of magazine and blog articles in 64GB of server memory. I don't think they have the kind of scaling problems that more social and peer-to-peer applications have.
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.
... because you think WordPress doesn't scale horizontally? That's... look, you should probably ask your doctor about WordPress.com. Or any reasonably large WordPress site.
Scaling web servers is easy but there are limits on what a single database instance can support that Wordpress won't address and having multiple sites on multiple database instances is a simple, desirable solution.
WordPress works great sharded and/or replicated across databases, servers, even datacenters. This is what WordPress.com, WordPress.org, and pretty much any major WordPress site uses: https://wordpress.org/plugins/hyperdb/.
Content sites scale horizontally at the caching layer--via a CDN, typically. The CMS exists to feed the cache, and should see very little traffic at the application.
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.”
EDIT:
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.
Good luck!