My Trackbacks are Fixed... WordPress Migration To Come.

Make sure you install Steve Smith's Tiger WordPress Administration Design. I actually LOVE using WP's backend now.

I missed the "no HTML tags note" (it says "some HTML is allowed" above, might want to change that). Tiger is at http://www.orderedlist.com/articles/wordpress-administration-design-tiger/. Enjoy.

Yay. Good to know you are moving to WP. :)

I never once regretted moving from MT to WP. Movable Type was the right choice when I was getting started, but for the level of tinker-ease that I was increasingly requiring, WordPress was the perfect upgrade.

Don't forget to check out the WP WP Plugins :)

Oops, the link is http://dev.wp-plugins.org/wiki/PluginDirectory

I'm for whatever tool works best for you. For me, MT stopped working well a long time ago... right about the time that WP did start working well.

I'm not sure if this should be a factor in the decision, but download the source, extract it, and then run:

grep -r SELECT wordpress

As a programmer, I found it pretty scary that there appeared to be absolutely NO parameterised queries, every query was straight strings with variable interpolation. This makes the whole software feel like a giant security disaster waiting to happen. In deed there's already been one release to a fix a hole:

http://wordpress.org/development/2005/05/security-update/

I'd be really surprised if there weren't more really subtle ones in there. So if you install, I'd be prepared to keep careful track of security updates, assuming people actually discover them... (I was actually the one that reported the above bug, but that's only because we watch our apache logs carefully...)

Obviously we're not a very happy WP user, and am looking to move to something else.

(Oh, and the parameterisation vs variable interpoliation thing is not a PHP thing, go check the source for mediawiki at some stage and compare, that's much nicer!)

Stu: Wow! That's a real nice admin thing, how well does it support backend plugins (e.g. Hello Dolly)?

But, well, It's nice to know that you're moving to the One True Bloggerfier.

~P

Good choice! WP kicks some butt and has some really nice plug-ins. Spam Karma is one of the most useful that I have found so far.

Penguin -- it is only CSS. It's the same wp-admin so plugins work the same. The only thing different is the stylesheet.

RM -- While I'm sure there are vulnerabilities (what is a software package without a few), I fail to see the danger in SELECT wordpress unless there's critical context you are leaving out. I have not done the grep because, at this point at work, I have no access to my command line. But based on what you say, you sound like you know what you are talking about, but you haven't given anything that is a flaw - just a potential flaw. We need some context. Perhaps a link to a more detailed expose?

Aaron

Luckily for WordPress as a popular web-based open source project there is a lot of code review by people looking for prestige on security lists. I would say this started when we reached a critical mass about a year ago, and WordPress is a far better product because of it.

It's naive to claim any product has no security bugs so when evaluating security for a project I tend to look at their track record for the past year or so and how problems were responded to. For the problem RM links to the time between report and release was less than an hour. Mediawiki, which RM points out as an example of good code, has had at least 5 security releases since I started using it. I still think it's a good project because the developers are very on the ball and more importantly it provides the functionality I need. I know their codebase matures with every release. The only web projects I see claim zero security problems are brand new ones. :)

> NO parameterised queries

This is a feature of the DBMS and mediawiki does not make use of it either. Wrapping db access in some functions does not make it automatically safer, the variables still have to be properly "escaped" for their respective purpose. ;)

Having said that, I wouldn't go with Wordpress either. I had similar negative experiences with WPs security. And I even read that they don't always publicise security fixes as such.

I'm in the process of making a switch to WordPress... Just as soon as I figure out how to use it all (which I'm testing on my server) and on top of that... how to get an archive of everything I have on the web already.

Also, it'd be nice if/when it supports OpenID along with other sites... 99% of the people that read my blog are on LiveJournal, and I'd like them to be able to comment in my new space, and it still be associated with them and I'd like to do the same with my friends all over the 'net. :-D

I love Wordpress. The ability to add plugins or create your own has made wonderful things to my blog. Hopefully it'll do the same for yours :)

oh god - wordpress... and because its used so much , you'll end up fighting comment spam.

my tip - use a less well known blogging tool. the less well known the better.

the curious thing is that the less well known tools are less developed , and thus, i can actually understand the underlying code a bit more - its not abstracted to ridiculous levels , which means i can hack about a heck of lot more.

dont follow the crowd jeremy - try out something unknown, different and unusual. it'll be worth it.

Do not look at the source code of WordPress. It will scar you for life. I haven't seen code that messy since high school. I do use WordPress for a few things inside the firewall but it doesn't surprise me one bit that it has so many security problems.

Do you usually get this many anonymous comments?

Sometime. Usually when folks are looking for a way to bash someone or something.

Hey anonymous_coward (appropriate name),

I haven't had any problems with comment spam. I take appropriate preventive actions from the get go to ensure such optimal results. I may get one comment spam every, oh, two months? If that much?

To do otherwise is kinda like going and buying that brand new spiffy Linksys Wireless router, hooking it up to your 4Mbps Comcast connection, and surfing wildly...while all the rest of your community is too, because you never turned off SSID broadcast, never changed the SSID name, boradcast on the standard wireless channel, don't use any encryption, etc.

You can't complain if you don't take the time to change the default settings. I expect Jeremy will have no issue or qualms about changing the default settings.

Hi,

I have been using WordPress for quite sometime (from 2003) and I have to say overall I am happy. There are things which need to be improved and I fixed some of them.

Welcome to the group :)

Angsuman

"...I tend to look at their track record for the past year or so and how problems were responded to..."

I always find this a bit of a hard one to decide on. The tradeoff between responsiveness to problems and actual number of problems in the first place.

Long rambling discussion coming up...

I remember a few years ago that bind was having serious problems. Just about every 2-4 weeks there would be another remotely exploitable security hole found. They would be fixed pretty quickly, but you still get pretty fed up with keeping up with all the patching. So do you go for something like tinydns, which has had much less problems, but also has an author who basically will happily deny there's a problem even when someone has shown there is one:

http://marc.theaimsgroup.com/?t=111702705800005&r=5&w=2

(Ok, so it's a pretty rare edge case, but if you make a guarantee, it's a guarantee... http://cr.yp.to/qmail/guarantee.html)

Personally I find that a hard choice to make.

So in this case, when I found out that our blog had been compromised, I searched our apache logs to see what had happened, then checked the code to see how this got through. That's the moment I got the scare. As a programmer, you know that there are certain constructs that are dangerous. For instance, you would never see a C programmer use the gets() function anymore, because anyone who knows anything about secure programming knows that it allows unlimited length data input and thus easy to do buffer overflows. Similarly, I would expect most web programmers to know that you should always used parameterised DB queries. Not doing so leaves you much more vulnerable to subtle SQL injection bugs such as in this case.

In that respect, I guess it's a confidence thing. Because you suddenly see something that looks really dangerous and has been known to be dangerous for a while, and you've just seen an example of why it's dangerous, you wonder how much you trust the rest of the code in general.

Ok, so I'm not a PHP programmer, but searching around some more, I think this is actually partly a php issue, or really a problem with the design of the base php mysql library.

http://www.php.net/manual/en/function.mysql-query.php

Wow, the default query function doesn't let you pass parameters at all. In fact I can't see a way to use a parameterised query at all, you have to use the long named "mysql_real_escape_string()" on each parameter!

Now I know there's a couple of options such as:
1. "You should be checking your incoming data anyway, and either rejecting the query if the data is invalid, or casting to an appropriate type anyway", and that's true, but the problem is when you miss that. Something that was a bug, has suddenly become an SQL injection security issue (as happened with WP in this case).
2. You can use a different library that does the parameterising. Unfortunately the default library most people use (eg the mysql one) doesn't allow this. Most projects start small, so they start with the default library, and then end up growing bigger, and still end up using the same library. Since you didn't start from the start with parameterised queries, you tend to be stuck moving that way, and so you never fix up the original issue

Anyway, I feel at least that this is where the perl DBI module got it right.

http://search.cpan.org/~timb/DBI/DBI.pm

EVERY query can use bind values, and ALL the examples do use it. This means that it's just as easy to use bind values, and since all the examples use it, most people do use it. Of course, you can still get it wrong, and there's lots of other potential problems, but here's one that's easy to fix.

By the way, I've gone back and looked at the mediawiki source code, and have had a mixed change of heart. The overall actual abstraction into classes seems to be better in mediawiki, but there's still too much arbitrary SQL thrown around the place, though mostly in the admin pages so it's probably a bit more localised. Checking the release notes for security issues:

http://www.google.com/search?hl=en&lr=&c2coff=1&q=site%3Ahttp%3A%2F%2Fsourceforge.net%2Fproject%2Fshownotes.php+mediawiki++security&btnG=Search

I notice that there has only been one case of a server side problem (upload and execute a php file), while the others have been cross-site scripting attacks through JS injection on the client side, not server side issues. That itself is an interesting point about the web. You have two main classes of problems; server side and client side.

So how would I summarise all this
1. Security is hard
2. However there are some "best practices" techniques to avoid common problems (eg buffer overflows, SQL injection)
3. You should probably use a library/language that encourages best practices, though if that conflicts with fast development, then you've got to compromise as well
4. Even then, you're still probably going to have security bugs, so responsiveness to problems is important