[wp-trac] Re: [WordPress Trac] #3243: Usermeta functions assume data to be pre-escaped

[WordPress Trac]

#3243: Usermeta functions assume data to be pre-escaped
----------------------------+-----------------------------------------------
 Reporter:  markjaquith     |        Owner:  markjaquith
     Type:  task            |       Status:  assigned   
 Priority:  normal          |    Milestone:  2.2        
Component:  Administration  |      Version:  2.1        
 Severity:  normal          |   Resolution:             
 Keywords:                  |  
----------------------------+-----------------------------------------------
Changes (by markjaquith):

  * status:  new => assigned

Old description:

> User meta functions assume that data passed to them is already escaped (
> {{{$wpdb->escape() }}}
>
> Post meta functions assume data is not already escaped.
>
> I think we should move to a standardized way of doing this, and I think
> the standard should be to expect unescaped data.
>
>  1. It is safer.
>   #. Worst case scenario with assuming data to be unescaped is that it
> gets double slashed
>   #. Worst case scenario with assuming data to be '''escaped''' is SQL
> injection vulnerability
>  2. Post meta has been doing it this way, for a longer time, so less code
> would have to change
>  3. It would allow code consolidation, in terms of handling
> arrays/objects/strings, serialization, and escape.
>  4. Currently, things like First Name and Last Name are passed through
> filters pre-slashed, which means that filters have to work around this.
>
> Setting a milestone of 2.2
>
> We can do this in trunk right after 2.1 ships, so that plugin authors
> will have 4 months to adapt.

New description:

 User meta functions assume that data passed to them is already escaped (
 {{{$wpdb->escape() }}}

 Post meta functions assume data is not already escaped.

 I think we should move to a standardized way of doing this, and I think
 the standard should be to expect unescaped data.

  1. It is safer.
    * Worst case scenario with assuming data to be unescaped is that it
 gets double slashed
    * Worst case scenario with assuming data to be '''escaped''' is SQL
 injection vulnerability
  2. Post meta has been doing it this way, for a longer time, so less code
 would have to change
  3. It would allow code consolidation, in terms of handling
 arrays/objects/strings, serialization, and escape.
  4. Currently, things like First Name and Last Name are passed through
 filters pre-slashed, which means that filters have to work around this.

 Setting a milestone of 2.2

 We can do this in trunk right after 2.1 ships, so that plugin authors will
 have 4 months to adapt.

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