Whenever I see 'WordPress' the first thing that springs to mind is Ripley's solution, "Nuke the entire site from orbit".
Pure coincidence I'm sure.
An estimated 86 per cent of WordPress websites harbour a dangerous cross-site scripting (XSS) hole in the popular comment system plugin, in what researcher Jouko Pynnonen calls the most serious flaw in five years. The bug could provide a pathway for attacking visitors' machines. The WP-Statistics plugin lets attackers inject …
You know, if you take the time to do wordpress right, it's a hell of a lot safer than rolling your own, unless "your own site" is so basic in functionality it doesn't need scripting or a DB.
Most businesses don't have the resources to perpetually pen test and patch their home-rolled CMSes. Every single red cent they can allocate to development goes into new features development.
So the three major free CMSes: Joomla, Drupal, and Wordpress have flaws. So does your code, even if your ego won't allow you to admit it. The difference is that the communities behind these free CMSes are far bigger than the core development teams...or their egos.
The net result is a lot of quality work into third party security options for these sites. These come in many forms. There are plug-ins of various types. There are filters for Apache, nginx, etc that will add a layer of sanity checking over anything coming and going from your sites and there are ALGs that are designed to stand in front of the three big CMSes and defend them.
This is the beauty of using such widely adopted software. Yes, you are a target because higher adoption makes it commercially more viable to attack. But the flip side is that there is a lot of money and community effort into defending what amounts to a known quantity.
Backups, disaster recovery, even the ability to spin up "known clean" copies from backups...it's all just plug-ins. There are even paid solutions I use which will scan my database and files looking for things that shouldn't be there, and ones that will actively filter things coming out of backups and being injected into a fresh restore.
It would take years - and hundreds of thousands, if not millions - of dollars to build all of that to defend a custom CMS. Especially any of the custom CMSes I've written.
And...how would I ever know if I'd been pwned? With the big three there are any number of things that can tell me when something's out of whack. But how can I be sure of that on my custom CMS? I mean, if I wrote a bug into my own software, isn't there a reasonable chance that a similar issue would work it's way into any of oversight code?
So how do I code oversight code for my CMS? Hire another dev? How much does that cost? How long to get them up to speed? And how could I afford that for my personal blog or small business? And what about feature enhancement? If I blow all my budget on hardening my custom CMS, I where do I get money to keep up with the Jonses?
Wordpress, Drupal and Joomla still need you to know what you're doing to defend them. You need a good ops guy. You need to press the button for major version updates, install and configure security, etc. But in terms of creating and maintaining over the long term a defensible website, they offer a lot of advantages over rolling your own.
At least, that is, unless and until your website is your business. (Facebook, Twitter, etc.) Then you need to iterate faster than you could with a major CMS. For the rest of us, I seriously doubt we'd do any better on our own.
So the three major free PHP CMSes: Joomla, Drupal, and Wordpress have flaws.
I'd take issue with describing either WordPress or Joomla really as content management systems, despite the fact that they are often used as such.
Security and secure development have never been high on the PHP agenda: ease of use and deployment have traditionally been far more important. Without a culture of security, you'll only get insecure code witness the heap of CVEs related to PHP and systems written in PHP. I'm not saying it's not possible to write good, safe code in PHP but it is harder than in most comparable languages. The recent exploit in Drupal highlighted this because it was down to parameters not being quoted properly. How that kind of code could be accepted by project leaders is beyond me.
The rest of your post is uses the strawman of homemade CMS to justify using the leading crapware. There are lots of CMSes and even ones that take security seriously and run their own pen-testing.
I've heard of both, but so far as I know they are fairly underadopted when compared to the "big three". While I accept that I could be wrong about their uptake, my understand wast that neither Plone nor Bricolage were "major". The last time I checked their adoption was more akin to "Linux on the desktop" versus the "Windows" of Drupal/Joomla/Wordpress.
Admittedly that was some time ago, so is I am incorrect in my information, I'm more than happy to be updated.
Also - and again, please correct me if I am wrong - Plone (and especially Bricolage) are designed for companies with development teams to sustain the installs. Unlike Drupal/Joomla/Wordpress which rely on a vibrant plugin ecosystem, Plone/Bricolage are far more of a "barebones" CMS that expect to form a skeleton of framework around which you will wrap your own site.
To me, that serves a different market than Drupal/Joomla/Wordpress. That's a market more where "the website is the product you are selling, or absolutely key to the product you are selling." Totally different from a personal blog, or a "you are here" for a business, or even a "here's our company/our corporate blog/a basic site to buy a few things/download whitepapers."
Plone/Bricolage, IIRC, simply require more commitment to ongoing development and maintenance than Drupal/Joomla/Wordpress. Plone/Bricolage require - at a minimum - a Developer and an Ops guy (or a hell of a DevOps guy. Drupal/Joomla/Wordpress only require an Ops guy...and he can be a consultant that sets up hundreds or thousands of the things for a living.
Also - and again, please correct me if I am wrong - Plone
You are wrong. Particularly Plone, with which I'm most familiar, targets non-techies and there are lots of installs of it by people with minimal technical skills. There are also lots of plugins for it.
I remember well when I recommended Plone to a teacher looking for something for his school (this was 2002 or so). A couple of years later he asked me his first technical question and a few years ago told me it had been adopted for the state educational intranet.
Nowadays, I'm more a fan of Substance D, not least because it has the best name! ;-)
Back to the keypoint: lots of pen-testing kits are open source and so little excuse for not including them in the release cycle.
Normally I would agree, but if you run big name CMS you are automatically exposed to all the exploits in it as and when they are discovered, and you will be probed for those along with every other site running that CMS.
If you have a site that is based on a home brewed CMS only used by you, it will most likely not bear the signatures of another commonly used CMS and the scanning bots will simply move on after a cursory glance. The only people who will bother to find obscure holes in your custom CMS are the people who are specifically after you, and if you have someone that determined to get you specifically, they will eventually succeed, but possibly still not as easily as by waiting with a finger on the trigger for another big name CMS exploit to be discovered.
Security through obscurity is only a valid approach when it is one layer amongst many. It is a part of good defense in depth. It is emphatically not acceptable as a primary means of security. In this case, I honestly believe that the benefits of the larger community outweigh the dubious benefits of obscurity. (Things like fuzzers exist. Your code isn't as safe as you think.)
Besides, you can do things like "change the administrative page of your CMS" via plugins with any of the majors. You can achieve security through obscurity as one layer amongst many with the majors. With a roll-your-own, you're basically betting on it and it alone to save your ASCII.
@ Trevor Pott and Ole Juul
I don't personally have a problem with WordPress as I don't use it. My problem with it is once removed, as it were. My entire experience of WordPress is that of people complaining to me that it doesn't work, or doesn't do what it's supposed to do, or can't be configured to do what they'd like it to do.
It may well be the best software ever written buy the most talented and conscientious programmers on the planet, but when you keep hearing about a toaster that burns the toast, and the person using it, the obvious conclusion is that something is wrong with it.
Maybe I only hear from dumb users, or maybe it's something like better documentation or user tutorials required. I don't know.
@ Trevor Pott:
Nice theory about the benefits of a mature ecosystem and plugins and all, but that's not the reality of WP. The core CMS is a bloated rat's nest full of bugs and dodgy practices (soft-fail, functions that second-guess their arguments, etc). The plugin/theme interface is "everything is global, you can do whatever you want, but please use our poorly documented monkey patching hooks". It doesn't matter how secure WP core is - any plugin can undermine it. Even the official WP repository is full of shoddy plugins. Few users possess the knowledge (or time) to choose wisely.
Most WP sites I've seen have so much custom code that they might as well be written from scratch. When you have to copy-and-modify half of the login/signup code to make the client happy, it makes you wonder if you're really gaining anything from a ready-made CMS.
If the #1 CMS did just the few things WP does well, built on a solid architectural foundation, then you'd have a point.
WP's handling of this vuln/update is another red flag. First, they downplayed the severity in their update notice, saying a "contributor or author" could "compromise" a site, versus the apparent reality of total ownage by random commenters. Second, the update broke a bunch of sites & plugins; people are screaming about it on WP forums, questioning the wisdom of auto-update.
"Static" sites just keep looking more and more attractive...
@ silent_count: Yes, there are lots of WordPress sites that makes one roll one's eyes, but we're talking about code here and as Trevor points out, what else are you going to use? WordPress in particular is very accessible to many people where more complicated solutions would not be, and roll your own definitely wouldn't.
What this makes me think about though is updates. I've run one particular very old versioned WP site for a number of years without issue or incident until a few months ago when the pressure to update finally got to me. Within days the spam was unbearable and the site got hacked. I'm not impressed. It seems like one has to divine which version to update. Every second, every third? If one updates every time it would seem like one is vulnerable half the time, whereas if one never updates one is either not vulnerable or vulnerable all the time. How does one win the update game?
Every CMS is different, I have always remove the wp theme/comments.php code anyhow for security reason and implemented something like "Disqus" instead for wp comments. But there are plenty of plugins to strip tags from comments and security plugins to handle XSS and comments for WordPress.
If you are a wordpress noob and need help, install the plugin ithemes security and tick all the boxes in the set-up.
Word Press could help themselves greatly by having a way to disable commenting. I run several sites, neither of which need comments enabled, but to do that effectively I'm forced to use a 3rd party plugin.
Just don't enable them. That works here on two sites here. No 3rd party plugin is needed.
...from the day I first setup my blog.
I've been running a WordPress blog from a local installation for five or six years, and disabled comments and trackbacks almost from the beginning, after spending no small amount of time scraping spam out of the comment and trackback sections.
This news only convinces me even more that I made the right decision.
Biting the hand that feeds IT © 1998–2019