[wp-hackers] Making WP more secure the evolutionary way

[DD32]

2009/1/22 Florian Thiel <flo.thiel+wphackers at googlemail.com>:
>> Also, It seems to be that you're suggesting in your patch that using
>> raw SQL (even though its prepared) is a bad idea?  Or am i reading it
>> wrong? :)
>
> Yes, that's my point, I'm probably not making that clear enough. The
> whole idea is centralising access to the database. When you have 5
> places in the system where the db is accessed, it's really easy to fix
> things once you notice there is a security vulnerability. You're
> fixing it in one place and all callers profit from that. Experience
> shows that if you have critical things like db access all over the
> place you will forget updating one or two places when applying a
> security fix. When you look at the last XSS incidents with WP, there's
> the exact pattern. The problem was fixed by applying another magic
> escaping method to the vulnerable spot. This probably leaves other
> places vulnerable because escaping is not done in a consistent way
> everywhere it's used. Obviously, you still need to find all the places
> where db access (or client output) happens. But you only have to do
> that one time.

Thats the thing, I dont see how this is different from current. All
queries which use user-data go through the wpdb::prepare() function,
which sanitizes the data for the query.. wpdb->prepare("SELECT a, b, c
FROM table WHERE a = %s", ' '\ UNION...'); would result in the -exact-
variable passed in being quoted -correctly-, Of course, since
wpdb::query() uses addslashes() instead of mysql_real_escape_string()
There may be chars which make it through that.. But thats beside the
point, Do you see where my confusion lies?