[wp-hackers] Wordpress database encryption.

[Dion Hulse (dd32)]

On 27 November 2011 17:29, Mike Schinkel <mikeschinkel at newclarity.net> wrote:
> On Nov 27, 2011, at 1:09 AM, Dion Hulse (dd32) wrote:
>> SQL Injection can be used for anything; Adding users, Deleting users,
>> Droping tables, and in many cases, Has also been used to alter the
>> SELECT query to display different data than expected, For example, if
>> you could SQL inject the primary WP_Query SQL, you could make the
>> posts list display usernames/emails/hashed passwords instead of posts.
>
> Okay, I get the adding of users, that makes sense. I can also see how they could get hashed passwords from an authors list.
>
> But I still don't see how you could use SQL injection to get hashed passwords from the posts list unless it was an extremely complex SQL query combine with a really wide open hole, or if if the plugin already added a join to the users table.  To get hashed passwords the injection would have to modify the field list, and the table list, no? The field list is easy for a poorly coded plugin, but I don't see how it's likely to annotate a join to the table list via SQL injection?  If it is possible, please inform me how so I can make sure to never allow it in my plugins.

Basically, always sanitize any data doing into a SQL statement.
For example, if you had a plugin which filtered the WHERE statement,
like so: (Yes, I realise this is wrong on so many levels, and won't
work as-is due to escaping)

add_filter('sql_where_hook_name', function($sql) {  return $sql .  '
AND post_date > ' . $_GET['some_field']; } );
something such as ?some_field=1 AND 0=1 UNION SELECT user_name as
post_title, user_pass as post_content FROM wp_users; --

would trigger a altered SQL which combines the the posts table with
records from the users table, Including a comment character (--) or a
null-byte character at the end causes the rest original query to be
ignored.

The simplest way to avoid it happening?
- Always use prepared statements.
- don't do direct SQL calls to start with..
- Triple check if the function/filter you're using expects sanitized
data or unsanitized data to be passed/returned (simplest way to check
is that \ and ' works as expected, although that's not a definite
secure way to check) - I mention functions, because although WordPress
devs do the best we can, we're human too, and not imune to making a
mistake.. If a function expects sanitized data, and you pass raw data
from a user in, who knows what will happen (luckely, this shouldn't be
a problem now, as there are only a few places where prepared
statements aren't used)
- Attack your own code, if you're accepting data from a user, or from
a URL, look at it and see if you can craft some data that will break
your plugin, or bypass your checks. For example, if you're only
accepting an number, why not cast it to an int?  if it's a specific
command, check that string exists in an array: if (
isset($_GET['my_command'] && !in_array($_GET['my_command'],
array('command1', 'command2') ) { die('Uh, what are you doing?'); }


This tutorial (even if you just look at the examples) shows how you
can exploit injections with ease:
http://www.unixwiz.net/techtips/sql-injection.html

I hope you find something of use here Mike, but my best advice is
really "Never trust a human, or a Computer for that matter, Whitelist
what they're allowed to do, Don't just block all 'DROP' in input data
(as I see some sites do)"