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.