[wp-trac] Re: [WordPress Trac] #5455: Charset SQL Injection Vulnerability

[WordPress Trac]

#5455: Charset SQL Injection Vulnerability
-----------------------+----------------------------------------------------
 Reporter:  pishmishy  |        Owner:  pishmishy
     Type:  defect     |       Status:  assigned 
 Priority:  normal     |    Milestone:  2.6      
Component:  Security   |      Version:  2.5      
 Severity:  normal     |   Resolution:           
 Keywords:  has-patch  |  
-----------------------+----------------------------------------------------
Changes (by filosofo):

  * keywords:  => has-patch

Comment:

 Replying to [comment:7 ryan]:
 > We tried mysql_real_escape_string() some time ago and it caused lots of
 problems.  That was before mysql_set_charset() came along, however. I
 think if mysql_set_charset() is available and DB_CHARSET is set, we can
 safely use mysql_real_escape_string().
 >
 > Let's try something like this. In wpdb::!__construct(), call
 mysql_set_charset(), if it exists, instead of SET NAMES.  Flag the fact
 that we've called mysql_set_charset().  Check this flag in wpdb::escape()
 and call mysql_real_escape_string() if the charset was set with
 mysql_set_charset().  If the charset was set with SET NAMES or not set at
 all, use addslashes().

 Now that PHP is at 4.3 or newer we can use mysql_real_escape_string.  I've
 attached a patch that employs it when the charset is utf8 and that sets
 the charset using mysql_set_charset for those that have it, following your
 suggestion.

 Can we get this in?  It would help address complaints like
 [http://blogsecurity.net/wordpress/wordpress-insecure-by-design/ this
 one].

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