46

It's a simple question with a strangely elusive answer.

get_magic_quotes_gpc() reports 0. I repeat, magic quotes are off. Magic quotes appear to have been disabled in php.ini (not at runtime).

Nevertheless, all POST data including single quotes (') is escaped when accessed in PHP. What could be causing this?


While preparing a test case, I discovered the general origin of the problem. We're bootstrapping WordPress as our application integrates with a WordPress multisite installation. When I disable the WordPress bootstrapping, the auto-escaping is disabled. Where may WordPress' auto-escape code be located?

Cœur
  • 37,241
  • 25
  • 195
  • 267
rinogo
  • 8,491
  • 12
  • 61
  • 102

6 Answers6

45

I think I found it. Problem (bug): http://core.trac.wordpress.org/ticket/18322

Solution: http://codex.wordpress.org/Function_Reference/stripslashes_deep

    $_GET       = array_map('stripslashes_deep', $_GET);
    $_POST      = array_map('stripslashes_deep', $_POST);
    $_COOKIE    = array_map('stripslashes_deep', $_COOKIE);
    $_SERVER    = array_map('stripslashes_deep', $_SERVER);
    $_REQUEST   = array_map('stripslashes_deep', $_REQUEST);

Note: As suggested by @Alexandar O'Mara, you might want to reconsider overwriting the superglobals like this. If it's appropriate for your situation, for example, you might just "strip locally" using an alternative like $post = array_map('stripslashes_deep', $_POST);

Also see @quickshiftin's excellent answer.

André Chalella
  • 13,788
  • 10
  • 54
  • 62
rinogo
  • 8,491
  • 12
  • 61
  • 102
  • 14
    thank you for sharing info about such a ridiculuos wp behavior – Your Common Sense Jan 21 '12 at 05:50
  • 3
    after 2 years, we still have this bug. Notice that you can not use this few times, so if you use it, other plugin use it, result will be unpredictable. – ViliusL Feb 20 '14 at 14:35
  • 4
    VilliusL, if you have issues with this interfering with other plugins, remember, that you're not obligated to overwrite the original superglobals (`$_POST`, `$_GET`, etc). You could always do something like: `$post_copy = array_map('stripslashes_deep', $_POST);` (Note that $post_copy would not be a superglobal, so you would use `global $post_copy;` or pass $post_copy as a parameter. – rinogo Feb 20 '14 at 18:59
  • 7
    **WARNING:** Using the code in this answer as-is is a potential security vulnerability. See this quote form the WordPress ticket. "Currently magic quotes *are* necessary because removing them could easily open us to unexpected security vulnerabilities. And even if we fix all those in core, there would likely be hundreds (conservative estimate) of plugins that would be suddenly vulnerable because they were assuming slashed data and it wasn't." – Alexander O'Mara Oct 09 '14 at 00:19
  • @AlexanderO'Mara: Thanks for your warning! One workaround to this would simply be to not overwrite the original superglobals. Instead, one could use separate, regular arrays like `$post`, `$get`, etc. (e.g. `$post = array_map('stripslashes_deep', $_POST);`) – rinogo Oct 09 '14 at 17:34
  • Also note @quickshiftin's excellent answer as a nice alternative. – rinogo Oct 09 '14 at 17:34
  • 2
    18322 was reopened on 2019-11-22 (that is nearly 8 years later). – Peter Mortensen Dec 01 '19 at 01:07
19

Expanding on @rinogo's answer with a deeper explanation, and offering another workaround.


In wp-settings.php there's an unconditional call to wp_magic_quotes

// Add magic quotes and set up $_REQUEST ( $_GET + $_POST )
wp_magic_quotes();

WordPress escapes quotes no matter what

function wp_magic_quotes() {
    // If already slashed, strip.
    // Escape with wpdb.
    // Force REQUEST to be GET + POST.
}

What's interesting though is this call is made after plugins have been loaded, before the theme is loaded. Sooo, at the top of your plugin

// A hack to cope with un-configurable call to wp_magic_quotes
// E.G. Make the original $_POST available through a global $_REAL_POST
$_REAL_GET     = $_GET;
$_REAL_POST    = $_POST;
$_REAL_COOKIE  = $_COOKIE;
$_REAL_REQUEST = $_REQUEST;

Then you can freely use $_REAL_POST et al. in place of $_POST (remembering it's a global, not a superglobal) where you need to. Also remember that while your plugin has loaded before the theme, if the theme calls down into one of the plugin functions which uses $_POST, it should read from $_REAL_POST to get the unescaped values.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
quickshiftin
  • 66,362
  • 10
  • 68
  • 89
  • Interesting solution! Do you have this specific solution working in a plugin already? – rinogo Dec 11 '13 at 16:06
  • @rinogo Yes, I wired it up last night, it's working like a charm! – quickshiftin Dec 11 '13 at 16:23
  • 1
    To completely remove the annoying escapes you can comment out wp_magic_quotes(); from the wp-settings.php and it will no longer apply the escapes to POST, GET, etc. – adamj Dec 15 '13 at 08:18
  • 2
    @adamj That's going to break Wordpress code that depends on them being escaped; not a good idea. – quickshiftin Dec 15 '13 at 16:09
  • 1
    @quickshiftin Haven't run into any problems at all since commenting it out. Though you make a good point. – adamj Dec 16 '13 at 00:48
  • 2
    Thanks for the `wp-settings` solution, was having a problem with wordpress and CI integrated together, where wordpress would modify all the post data even in CI. – Bankzilla Mar 05 '14 at 21:56
  • "What's interesting though is this call is made after plugins have been loaded, before the theme is loaded. " So in my plugin, I don't need to worry about it? the $_POST etc.. aren't escaped yet? But is it the case for all hooks that my plugin implements?? any reason why magic quotes are added at theme level? – yeahman Apr 12 '14 at 17:13
  • I'm not really sure why it's applied after the plugins and before the view, but that seems to be the case. The WP devs could probably shed some light on that, though I don't find them very clever in general. [Here's](https://core.trac.wordpress.org/ticket/24255#comment:5) another situation I thought they handled poorly for example. – quickshiftin Apr 13 '14 at 17:55
  • how to check magic quotes have been applied or not? is there a function? I assume if may be magic quoted in some cases and not magic quotes in other cases depending on the action my plugin is implementing? – yeahman Apr 15 '14 at 18:53
  • I have posted a new question so as it's easier to follow: http://stackoverflow.com/questions/23092216/get-un-escaped-post-not-magic-quoted-values-in-wordpress – yeahman Apr 15 '14 at 19:02
  • Nearly 6 years later there is still the unconditional call to wp_magic_quotes() in wp-settings.php (WordPress 5.2.4, 2019-10-14). – Peter Mortensen Dec 01 '19 at 01:16
  • @PeterMortensen WordPress - the living PHP Anti-pattern reference, lol. – quickshiftin Dec 01 '19 at 22:03
2

I just had to deal with this issue and found what I think is a pretty nice workaround. It ensures that the GPCs are never slashed. I just put this at the top of my plugin file (it would work at the top of a theme too, I think):

add_action( 'init', 'unslash_gpc' );
function unslash_gpc() {
    $_GET       = array_map('stripslashes_deep', $_GET);
    $_POST      = array_map('stripslashes_deep', $_POST);
    $_COOKIE    = array_map('stripslashes_deep', $_COOKIE);
    $_SERVER    = array_map('stripslashes_deep', $_SERVER);
    $_REQUEST   = array_map('stripslashes_deep', $_REQUEST);
}

And now everything is perfect!

Jordan
  • 3,998
  • 9
  • 45
  • 81
  • 1
    But just to be clear, this also permanently modifies the superglobals, right? – rinogo Nov 28 '15 at 21:09
  • 1
    (E.g. All other plugins/themes/the core will also be fed the un-magic-quoted values? It might be better to use plugin-scoped variables instead. Regardless, I like your solution!) – rinogo Nov 28 '15 at 21:11
1

The best answer provided here is to copy for own use like:

$post = array_map('stripslashes_deep', $_POST);

There's a theoretical problem with this however: since you're working with a duplicate, you can't persist any changes to the superglobals (hey, I'm not saying it's a good practice, alright?).

Solution: accessor methods

In an attempt to solve this mess in a definite manner and without any side effects, I made "accessor methods" which transparently apply stripslashes_deep() or addslashes_deep()* to get/set requests to the following superglobal arrays:

* I had to throw addslashes_deep() together from WordPress' stripslashes_deep().

  • $_GET
  • $_POST
  • $_COOKIE
  • $_SERVER
  • $_REQUEST

You can use them like:

echo _get('username');    // echo stripslashes_deep($_GET['username']);
_cookie('name', 'value'); // $_COOKIE['name'] = addslashes_deep('value');

Here's the code (I call it gpcsr.php):

<?php

// cat stripslashes_deep() | sed 's/stripslashes/addslashes/g'
function addslashes_deep( $value ) {
    if ( is_array($value) ) {
        $value = array_map('addslashes_deep', $value);
    } elseif ( is_object($value) ) {
        $vars = get_object_vars( $value );
        foreach ($vars as $key=>$data) {
            $value->{$key} = addslashes_deep( $data );
        }
    } elseif ( is_string( $value ) ) {
        $value = addslashes($value);
    }

    return $value;
}

function _generic_slashes_wrap(&$arr, $key, $value = null) {
    if (func_num_args() === 2) return stripslashes_deep($arr[$key]);
    else $arr[$key] = addslashes_deep($value);
}

function _get       ($key, $value = null) { if (func_num_args() === 1) return _generic_slashes_wrap($_GET,      $key); else _generic_slashes_wrap($_GET,        $key, $value); }
function _post      ($key, $value = null) { if (func_num_args() === 1) return _generic_slashes_wrap($_POST,     $key); else _generic_slashes_wrap($_POST,       $key, $value); }
function _cookie    ($key, $value = null) { if (func_num_args() === 1) return _generic_slashes_wrap($_COOKIE,   $key); else _generic_slashes_wrap($_COOKIE,     $key, $value); }
function _server    ($key, $value = null) { if (func_num_args() === 1) return _generic_slashes_wrap($_SERVER,   $key); else _generic_slashes_wrap($_SERVER,     $key, $value); }
function _request   ($key, $value = null) { if (func_num_args() === 1) return _generic_slashes_wrap($_REQUEST,  $key); else _generic_slashes_wrap($_REQUEST,    $key, $value); }

?>
André Chalella
  • 13,788
  • 10
  • 54
  • 62
1

WordPress provides a solution for this by using the WordPress function stripslashes_deep. So, the snippets mentioned in @rinogo's answer would become :

$_GET     = stripslashes_deep($_GET);
$_POST    = stripslashes_deep($_POST);
$_COOKIE  = stripslashes_deep($_COOKIE);
$_REQUEST = stripslashes_deep($_REQUEST);

Also a note, WordPress doesn't say anything about the $_SERVER global variable, so I would assume it's not affected.

WordPress adds slashes to $_POST/$_GET/$_REQUEST/$_COOKIE regardless of what get_magic_quotes_gpc() returns. So in the context of WordPress, stripslashes() or stipslashes_deep() should always be used when using those variables.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
George Dimitriadis
  • 1,681
  • 1
  • 18
  • 27
  • It's only in wordpress you are escaping the data first and then un-escaping it on the very next line. – Your Common Sense Apr 24 '17 at 12:47
  • @Your Common Sense Ironic right ? Wordpress always did stuff like this and after a few years you get a new version with option to disable the actual functionality, by defining a constant in wp-config or something ... – George Dimitriadis Apr 25 '17 at 15:12
-1

Or, just do like I did. Comment out all of the implementation in load.php's wp_magic_quotes() method.

I have no use for magic quotes. This was causing me many more headaches than it was worth. Personally, I prefer to maintain my own discipline of input sanitation. I just don't want to start forming bad programming habits.

But, I do understand WordPress' compulsion to include such a "feature". Perhaps the development community would be best served with a global option to disable it.

  • 1
    If this solution works for you, then great! Two potential problem areas to be aware of, though: 1) Modifying core is error-prone and even dangerous (security-wise), especially with regard to something like escaping. 2) Many plugins are designed to work nicely with wp_magic_quotes(). Modifying that implementation could alter their behavior. More discussion on retaining/killing wp_magic_quotes(): https://core.trac.wordpress.org/ticket/18322 – rinogo Jan 12 '15 at 17:35
  • See my comment to @adamj beneath my solution, this is not a good idea as you'll break Wordpress code that expects these values to be escaped. – quickshiftin Jul 08 '15 at 22:25