[wp-hackers] Wordpress database encryption.

[Stas Sușcov]

On Lu 28 nov 2011 01:42:59 +0200, Mike Schinkel wrote:
> On Nov 27, 2011, at 2:05 AM, Dion Hulse (dd32) wrote:
>> 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; --
>
> OK, thanks. It's the UNION statement I drew a blank on (embarrassed, I've only been working professionally with SQL since 1994...) I get it now.
>
>> The simplest way to avoid it happening?
>> - Always use prepared statements.
>
> Fortunately I've already been doing this, just didn't always know why it mattered in some cases. Now I think I do.
>
>> - don't do direct SQL calls to start with..
>
> Heh. Sometimes you can't help it.  But, that's what $wpdb->prepare() is for, right?
>
>> 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)
>
> That's helpful too.
>
>> 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?'); }
>
> Ditto there.
>
>> 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
>
> Exactly what I was asking for. Thanks!
>
>> 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)"
>
> It was very helpful, thank you.  AFAICT, I've been following all necessary best practices, I just have not understood all the main use cases that were being protected against. Now I do. Cool.
>

Imho, you are doing it wrong.
Ages have learned you to not trust human, but in modern times (21st 
century) this led to TDD/TBD and definitely not to solutions like this.
Beside complicating things, your solution will also have impact on 
performance not mentioning portability of the stored data.
Anyway, as it was already said, everyone is free to act the way he 
decides, but your impact could have been greater if you provided a set 
of tests/specs that will cover wpdb class.

Good luck.