[wp-trac] Re: [WordPress Trac] #4545: Slashing consistency

[WordPress Trac]

#4545: Slashing consistency
-------------------------+--------------------------------------------------
 Reporter:  markjaquith  |        Owner:  anonymous   
     Type:  task         |       Status:  new         
 Priority:  normal       |    Milestone:  2.4 (future)
Component:  Security     |      Version:  2.3         
 Severity:  normal       |   Resolution:              
 Keywords:               |  
-------------------------+--------------------------------------------------
Comment (by markjaquith):

 > This is a great idea to help prevent injections. I always thought that
 $wpdb->query should do the add/remove of slashes.

 It can't.  SQL Injection attacks are legitimate SQL queries (or else they
 wouldn't work).  How do you tell a SQL Injection attack from a normal SQL
 query when both are legitimate queries?

 I'm just proposing that the escaping we do be as close to the query as
 possible, so that failure to escape is more readily identifiable.

 > We can also make a prepared statement-like/printf-like method of wpdb,
 which can handle escaping internally and get rid of the few lines, before
 every query, spent in escaping.

 This crossed my mind too.

 Something like:

 {{{
 $result = $wpdb->get_results(
         $wpdb->prepare("SELECT something FROM $wpdb->tablename WHERE foo =
 '%s' LIMIT %d", $unslashed_value, $unslashed_uninted_limit)
 );
 }}}

 We couldn't force people to use it, but it could really clean up our core
 code and help with SQL Injection squashing.

 Heck, we could implement that now, for 2.3, for functions that already
 expect unslashed data (which I think is the majority, thankfully).

 New ticket for that topic: #4553

-- 
Ticket URL: <http://trac.wordpress.org/ticket/4545#comment:4>
WordPress Trac <http://trac.wordpress.org/>
WordPress blogging software