[wp-hackers] wp_specialchars() vs attribute_escape() ( now esc_attr() ) and quote entity-encoding

[Aaron D. Campbell]

I recently put up a WordPress based site for Harvard Law, and they are 
REALLY strict about XSS (they have an IBM scanning tool that they use 
regularly to detect this stuff).  Heavy usage of attribute_escape helped 
a LOT.  I can't think of any reason not to enforce the additional level 
of security (for now at least...but I'll continue to think on it).  I 
actually think it's a great idea.

Mark Jaquith wrote:
> WordPress 2.8 is getting a shortening, consolidation, and
> "i18n-chaining" upgrade for its security escaping functions.
>
> Here are some old/new pairs:
>
> echo attribute_escape( __('Translated String') );
> esc_attr_e(' Translated String' );
>
> attribute_escape( __('Translated String' ) );
> esc_attr__( 'Translated String' );
>
> attribute_escape( $user_string );
> esc_attr( $user_string );
>
> js_escape( "dynamic $js" );
> esc_js( "dynamic $js" );
>
> The naming convention is esc_FORMAT[optional i18n suffix](). It's
> shorter, predictable, and it cuts down on parenthesis nesting! Next on
> my list was one-parameter wp_specialchars(), which will become
> esc_html(), esc_html_e() and esc_html__().
>
> It occurred to me that a lot of people do this:
>
> <input value="<?php echo wp_specialchars( $xss ); ?>" />
>
> Which is WRONG (and unfortunately common in plugins) and an XSS
> exploit opportunity. See, attribute_escape() (now esc_attr())
> additionally entity-encodes quotes, to prevent XSS attacks from
> "breaking out" of the attribute. That's the only real difference
> between attribute_escape( $xss ) and wp_specialchars( $xss ). While it
> is dangerous to use wp_specialchars( $xss ) instead of
> attribute_escape( $xss ), the opposite is not true. There is no harm,
> that I can think of, in entity-encoding quotes in an HTML context.
>
> Can you think of any? If not, this presents us with an opportunity to
> make esc_html() and esc_attr() functionally equivalent and to have
> wp_specialchars( $xss ) calls go through esc_html(), which would
> encode quotes, and thus anyone who used the above code would get a
> free security upgrade to their plugin/theme. Can you think of any
> reason this wouldn't work? C'mon, go ahead and rain on my parade.
>
> Notes:
>
> Backward compat with the old functions is maintained. As for my
> proposed handling of esc_html() and wp_specialchars(), calls to
> wp_specialchars() with default values for the rarely-used additional
> params would be honored, like before. It's only single-parameter calls
> to wp_specialchars() that would get the esc_html()/quote-encoding
> treatment.
>