[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