WordPress and some questions about Blogland Security

I just read Mario’s post on Digizen discussing IT Damager’s post about the constant security updates at WordPress. Now I know I am a fanboy and all, but the long list of security-related updates that IT Damager references in his post is certainly a concern (and even a fanboy needs to throw a curve ball once in a while). Ironically, Patrick brought up the security fix to me the other day and I kind of shrugged it off, while taking a snipe at Drupal, oh- how sharper than a serpents tooth is a fanboy’s ingratitude! Sorry Patrick!

We are on the verge of a pretty awesome multi-user environment that promises to open up some really interesting possibilities for faculty, students and administration alike. Nonetheless, when I read a post that notes “that every single update to WordPress over the last 2 years has been security related” -I have to pause for a moment and wonder if the WordPress community doesn’t need to start working together a bit more closely to understand this serious recurring issue. I guess its time for me to get off the carousel of denial and look a bit more closely at some of these issues.

At Northern Voice last February, Chris Lott noted that the WordPress code was a bit ugly (my quote, not his), and Lloyd Budd was both eager and quick to suggest otherwise. But when the tale of the tape comes out with a less than impressive record of security exploits, I think one might begin to wonder if Chris has a point. Now that won’t stop me from pushing on with my favorite web-based publishing platform, as well as continuing to experiment with all its excessive goodness. However, that post did give me a bit of pause in regards to thinking about running an “enterprise” application like WordPress when the security issues often require administrator privileges. Within a WPMu environment every blog comes with an admin user that can potentially hi-jack the entire site using these WordPress exploits.

So, to echo the Damager, “I am not sure what it will take to get the WordPress team to write secure code, but I think the community should do nothing short of demand it.”

This entry was posted in WordPress, wordpress multi-user and tagged , , , . Bookmark the permalink.

6 Responses to WordPress and some questions about Blogland Security

  1. Even with a fully patched web app, we’re all running the admin side without SSL and HTTPS, so anyone with a packet sniffer could grab usernames, passwords, and/or cookies and have their way with the blogs anyway…

  2. jimgroom says:

    Thanks for putting me at ease D’Arcy. Next time bring a machete and finish the job why don’t you…

  3. I’ll be the Vietnamese villager, and you can be the water buffalo. Apocalypse Now, Redux.

    It’s probably not completely insecure – I mean, every blog on the planet (save maybe a handful) runs that way…

  4. jimgroom says:

    You’re a sick puppy, Norman -and I love it!

  5. Drupal also has the advantage of having a meaner, leaner codebase. WordPress has many more lines of code, meaning there may be more opportunities for bugs and/or security holes.

    http://buytaert.net/cms-code-base-comparison

    Drupal core has less than half the code of WordPress…

  6. Hello, Jim,

    WP and security have a long and stormy relationship — it would make for a great B movie —

    I can just imagine the following line of dialogue: “His script came from without, and entered my private place.”

    From Oct, 04 — http://developers.slashdot.org/article.pl?sid=04/10/01/2050216

    Fast forward ahead 2.5 years:
    http://it.slashdot.org/it/07/03/03/0427211.shtml

    And from May, 07:
    http://it.slashdot.org/article.pl?sid=07/05/24/167223

    All kidding aside, ouch.

    I don’t know if the WP community has any equivalent of this (http://drupal.org/writing-secure-code) in their developer docs, but it would be good to see some standards like this integrated into their code review process, both for core and contrib code.

    Cheers,

    Bill

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.