[wp-hackers] wp_magic_quotes makes me sad panda

[Michael D Adams]

WordPress has always normalized $_GET, $_POST, $_COOKIE, and $_SERVER
to be slashed:
WP 2.7: http://core.trac.wordpress.org/browser/tags/2.7/wp-settings.php#L492
WP 1.3: http://core.trac.wordpress.org/browser/trunk/wp-settings.php?rev=1964#L104
(Before then, the normalization was done in admin.php and wp-comments-post.php)

In 2.9, $_REQUEST joined that group (and was forced to emulate
request_order=GP).

I agree with you in theory: it's ugly.

In practice, it's way too late to change.

Mike
--mdawaffe

On Mon, Sep 27, 2010 at 3:49 AM, Gavin Lambert <wphack at mirality.co.nz> wrote:
> I've just upgraded my blog from WP 2.7 to 3.0.1 (yes, I know, I'm slow).
>  After doing so, one of my (currently private) plugins broke, due to
> mysterious extra backslashes in $_POST.
>
> This was very peculiar, since like any good PHP developer I had written code
> to call stripslashes if get_magic_quotes_gpc() was on, and I happened to
> know that on my site it was off anyway.
>
> Eventually, I traced this back to the mysterious addition of
> wp_magic_quotes, apparently added in 3.0.0.  What the heck?
>
> Now, I've searched the archives (a bit, since it doesn't have a "real"
> search option), and apparently the reason for adding this was for backwards
> compatibility with lazy plugin authors who don't know how to write PHP code.
>  Or to disable magic_quotes_gpc on their servers.  So it's being forced on
> anyway.
>
> I have several problems with this:
>
> 1. For the unlucky souls who actually do have magic_quotes_gpc enabled, the
> slashes are being added by PHP, stripped by WP, re-added, and then finally
> will almost certainly be stripped again by the plugin prior to use.  This
> seems like a colossal waste of time.
>
> 2. Lazy plugin authors who don't know how to write PHP code shouldn't be
> coddled, they should be educated.  If they write code that makes them
> vulnerable to injection attacks in private plugins, then they deserve to
> have their blog destroyed.  If they do it in public plugins, then hopefully
> someone will eventually notice that the code is broken and tell them how to
> fix it.  Or people will stop using that plugin after it breaks their site.
>  [Note, however, that even then only the class of plugins that directly
> execute SQL based on GPC parameters could possibly be vulnerable.  I really
> don't think that this is a big group.]
>
> 3. WP provides no apparent way to detect whether this transformation has
> been done (like "normal" PHP does with get_magic_quotes_gpc).  This means
> that it'll be even harder in future to get rid of this wart, because plugin
> authors won't be able to make their stripslashes calls properly conditional.
>  (In other words, this has introduced a new future compatibility problem.)
>
> 4. Quite a bit (possibly even the majority) of GPC data doesn't end up
> hitting the database anyway, so applying magic quotes to it is pointless.
>
> 5. Magic quotes are deprecated (and disabled by default) in PHP 5 and will
> be disappearing entirely in PHP 6.  In other words, even the developers of
> PHP have recognised that they're a silly idea.
>
> At the very least, #3 ought to be fixed, to at least entertain the
> possibility of future sanity.  Ideally, though, wp_magic_quotes should be
> removed entirely.
>
> [And I apologise if my tone seems overly confrontational or insulting.  But
> this *really*, *really* annoys me, probably at least partly because all the
> chasing around to find the extra slashes is still fresh.]
>
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>