WordPress Insecure by Design?
We have seen alot of critical vulnerabilities being discovered in WordPress core and its plugins of late, who’s to blame? This article will take a brief look into WordPress design and its core security functions.
One of the major problems I see with WordPress is that it provides little (if any) protection against input validation attacks. So where does the problem lie?
One of the main problem lies in the way WordPress sanitises user input. It passes SQL queries to $wpdb->escape. This function (in most cases) is all that stands between an attacker completely compromising the blog. So what does this function really do?
$wpdb->escape is really just addslashes. Here in lies one of the big problems.
PHP’s addslashes() function only supports UTF-8 and was originally designed to escape single quotes in SQL strings, to allow for names such as O’brien. It really isn’t the function you want to rely on for hardcore PHP security. Hence why Stefen Esser was able to bypass WordPress security and exploit a UTF-7 SQL Injection exploit some time ago. Another example of this, was Abel Cheung’s Charset SQL Injection vulnerability, published last month (which in theory should still be exploitable).
If WordPress is going to get serious about security, we need to come up with hardcore secure functions, that the WordPress core, and its plugin developers can use. These functions should take the security considerations out of the plugin developers hands and secured from within the WordPress core!
There is alot that needs to be done. For starters, I’d suggest providing a proper set of SQL safe functions (i.e. $wpdb->escape_int and $wpdb->escape_str.
This is one area, where I think blogging platforms like Drupal do a far better job!
Note: This article was based on WordPress <=2.3.2 code.
Random Posts
If you enjoyed this post, please leave a comment or subscribe to the feed and get future articles delivered to your feed reader.
Comments
Drupal is far more along then WordPress when it comes to security.
They use mysql_real_escape_string(), and have clearly defined coding standards and security policies to name a few.
Interestingly, they also force UTF-8 (hardcoded) for SQL connections. Don’t know how dynamic this is though?
I tend to think that people who really care about their security (in the “hardcore” term of it), won’t use PHP in the first place.
What is your suggestion for current WP users? Do you think WP security is likely to be improved any time soon? Presumably, it wouldn’t be too difficult to release a plugin/patch to modify the SQL string checking routines?
Cheers,
Steve.
[...] Kierznowski at BlogSecurity suggests that WordPress is “insecure by design.” What he means is that in general WordPress does not sanitize MySQL queries. He recommends that [...]
[...] WordPress Security: Blog Security asks if “WordPress is Insecure by Design?” and then answers the question about the critical vulnerabilities that keep popping up lately in the [...]
@Steve, I think WP is moving in the right direction and alot of promises have been made to improve WP 2.4 and 2.5 (future releases) with regards to security.
You may want to check out our ModSecurity: defense in depth article (http://blogsecurity.net/wordpress/modsecurity-and-wordpress-defense-in-depth/)
@Leonid, no comment :)
Has anyone done a full security audit of WordPress?? Like number of vulnerabilities by release? What the vulnerabilities were (db, app, file, etc…)? I’m researching for a project but have to belive that someone has done this already.
[...] BlogSecurity » Blog Archive » WordPress Insecure by Design? biztonsagos-e a wp? (tags: php security wordpress wp) [...]
thanks for the information about wordpress vulnerabilities, would .htaccess help against this or not.
[...] seems to be the latter, and BlogSecurity.net addressed the general issue of WordPress security recently: We have seen alot of critical vulnerabilities being discovered in WordPress core and its [...]
Given the old versions of PHP and MySQL we support and the peculiar DB setups we encounter, we’ve had troubles with simply using mysql_real_escape_string(). The Drupal method of enforcing UTF-8 is appealing, but we’re stuck with what we have for now. If anyone has insight on how to get mysql_real_escape_string() and friends to behave across all of the environments WP supports, please share on this bug report.
I dug through the WP source code briefly a couple of days ago and I was also left puzzled as to why they weren’t using mysql_real_escape string. In my experience that’s standard practice.
On the other hand, that shouldn’t be too hard for them to fix.
I also have to agree with Leonid’s point on PHP ;)
@Ryan Boren
I dont wanna be rude but I really find the excuse to be funny.
Drop the very old version support of mySQL and PHP, raise the minumum required versions if it is needed.
I dont understand how this can be an excuse of bad/in-efficient/in-secure etc. design.
mysql_escape_string()? Is that it? I figured an objective blog like this could spend a little more time going deeper than that.
And I would argue, having done multiple projects with both platforms, that Drupal is not more secure. It has more published exploits than WP, and some of its most popular modules don’t conform to either their published coding standards or security practices. Some of them don’t even use the published API and are littered with plain SQL through out the source.
Also its interesting that you say this, yet are using WP to publish this very blog.
We’ll take your ‘objective blog’ as a compliment, thanks.
If you want something more detailed, attend my OWASP presentation in London, planned in April :)
[...] this a technical impossibility? Are there good reasons (security reasons, maybe?) For anyone who has been blogging for the Observer, are you okay with the current [...]
As a relatively unsophisticated WordPress user, I find this worrisome. Hopefully, it is something they will prioritize for the next version, rather than tinkering with the look of admin pages again.
Is this the kind of thing where a good fix could be ‘dropped in,’ or would it require a great deal of coding and testing?
Milan, WordPress has come a far way since Jan/08 (when this post was released). They still have a fair way to go but they have implemented some great security features in recent version.
I like to think BlogSecurity had something to do with this.
So….
How *does* Drupal do it?
Ciao!