[wp-trac] [WordPress Trac] #12416: *_option(), *_transient() and *_meta() functions should all expect unslashed data. (was: *_option() should all expect unslashed data.)

WordPress Trac wp-trac at lists.automattic.com
Sat Feb 27 22:05:47 UTC 2010


#12416: *_option(), *_transient() and *_meta() functions should all expect
unslashed data.
-------------------------------+--------------------------------------------
 Reporter:  Denis-de-Bernardy  |       Owner:  ryan
     Type:  defect (bug)       |      Status:  new 
 Priority:  normal             |   Milestone:  3.0 
Component:  Security           |     Version:  3.0 
 Severity:  blocker            |    Keywords:      
-------------------------------+--------------------------------------------
Description changed by Denis-de-Bernardy:

Old description:

> Following up on:
>
> http://core.trac.wordpress.org/ticket/9015#comment:136
>
> It's totally irresponsible to expect plugin authors to escape whatever
> they send into get_option(). As things stand:
>
>  - get_option(), delete_option(), get_site_option() both assume it's
> slashed
>  - add_option(), update_option(), add_site_option() seem to assume it's
> unslashed, as does __get_option()
>  - *_transient() seem to expect unslashed input.
>  - delete_site_option() is very special: it expects slashed input if
> you're not on using multisite, but unslashed if you are
>  - update_site_option() is equallty special: it needs slashed input if
> the option is not loaded already, and unslashed input if it is
>
> the list goes on, and on... these inconsistencies, which come on top of
> the *_meta() functions, are totally nuts and insecure.
>
> especially considering calls in WP such as:
>
>  - get_option("{$size}_crop");
>
> or functions such as:
>
> {{{
> function form_option( $option ) {
>         echo esc_attr( get_option( $option ) );
> }
>
> function get_settings_errors( $setting = '', $sanitize = FALSE ) {
>         global $wp_settings_errors;
>         //... isn't it ironic that using sanitize here makes it LESS
> secure?
>         if ( $sanitize )
>                 sanitize_option( $setting, get_option($setting));
>         // ...
> }}}

New description:

 Following up on:

 http://core.trac.wordpress.org/ticket/9015#comment:136

 It's totally irresponsible to expect plugin authors to escape whatever
 they send into get_option(). As things stand:

  - get_option(), delete_option(), get_site_option() assume it's slashed
  - add_option(), update_option(), add_site_option() seem to assume it's
 unslashed, as does __get_option()
  - *_transient() seem to expect unslashed input.
  - delete_site_option() is very special: it expects slashed input if
 you're not on using multisite, but unslashed if you are
  - update_site_option() is equallty special: it needs slashed input if the
 option is not loaded already, and unslashed input if it is

 the list goes on, and on... these inconsistencies, which come on top of
 the *_meta() functions, which expect slashed data.

 it's totally nuts, insecure, and irresponsible. especially considering
 calls in WP such as:

  - get_option("{$size}_crop");

 or functions such as:

 {{{
 function form_option( $option ) {
         echo esc_attr( get_option( $option ) );
 }

 function get_settings_errors( $setting = '', $sanitize = FALSE ) {
         global $wp_settings_errors;
         //... isn't it ironic that using sanitize here makes it LESS
 secure?
         if ( $sanitize )
                 sanitize_option( $setting, get_option($setting));
         // ...
 }}}

 we're asking for trouble here...

--

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


More information about the wp-trac mailing list