• Back in around 2001 or so I learned to disable gpc_magic_quotes because it was the wrong solution to the problem.

    It does not fix the problem of sql injection, and it causes other problems.

    While doing my wordpress coding, sending a json encoded string via post wasn’t working. When I looked at why, what was being sent had escapes added to it. It wasn’t an actual json string = it had been broken.

    Thinking that maybe Fedora made a bonehead move and re-enabled gpc_magic_quotes by default in Fedora 20 build of php, I looked at my php.ini file – no mention of it.

    So then I thought maybe jQuery was doing it with its $.ajax handling.

    Nope.

    Finally I tracked it down. WordPress itself.

    WordPress itself implements gpc_magic_quotes whether we want it or not, even though it is known to be a very bad practice. It doesn’t really protect against SQL injection, and it causes problems – like using the json_decode() function in php amongst other things.

    For the love of all things sane, please stop doing that. You should not mangle the $_POST data that is sent to WordPress.

    It is fundamentally wrong.

Viewing 4 replies - 1 through 4 (of 4 total)
  • Thread Starter AliceWonderFull

    (@alicewonderfull)

    btw, since at this point in time most web applications are AJAX I suspect you will find that a large amount of the $_POST data being sent to WordPress is in json strings and thus, will have to have the escapes removed from it before it is ever fed to a database (if it is ever fed to a database).

    So any small amount of protection you think you are giving by escaping all $_POST content is effectively neutured just by the nature of modern webapp development which includes sending data to servers in JSON strings.

    Just get rid of it, prepared statements are the right way to protect against SQL injection and make escapes completely un-necessary.

    Moderator Ipstenu (Mika Epstein)

    (@ipstenu)

    ?????? Advisor and Activist

    https://core.trac.www.ads-software.com/ticket/18322

    So it’s a messy and long problem, but it’s not ‘normal’ magic quotes, it’s WordPress magic quotes. It’s not quite the same thing.

    Thread Starter AliceWonderFull

    (@alicewonderfull)

    A solution I’m using for my plugin, none of my AJAX is done through the WordPress way. It is faster on execution and a lot easier to completely bypass the WordPress stuff for AJAX. And it is easier to debug.

    So what I’m doing

    <?php
    $PPOST = $_POST;
    // Now load WordPress settings and stuff
    require('../../../wp-load.php');

    That gives me a pristing copy of $_POST that has not been mangled in any way by wordpress.

    -=-

    Some people who bypass the WordPress AJAX API say you can get even more speed by using SHORTINIT but I found that breaks some of my stuff, so I don’t use that.

    Moderator Ipstenu (Mika Epstein)

    (@ipstenu)

    ?????? Advisor and Activist

    We reject all plugins from www.ads-software.com that call wp-load directly these days (so there may be some stragglers out there, but we try to educate them as we can).

    Here’s the boilerplate why:

    Including wp-config.php, wp-blog-header.php, wp-load.php, or pretty much any other WordPress core file that you have to call directly via an include is not a good idea and we cannot approve a plugin that does so unless it has a very good reason to load the file(s). It is prone to failure since not all WordPress installs have the exact same file structure.

    Usually plugins will include wp-config.php or wp-load.php in order to gain access to core WordPress functions, but there are much better ways to do this. It’s best if you tie your processing functions (the ones that need but don’t have access to core functions) into an action hook, such as “init” or “admin_init”.

    Please consult the Plugins API reference for more information: https://codex.www.ads-software.com/Plugin_API

    If you’re trying to use AJAX, please read this: https://codex.www.ads-software.com/AJAX_in_Plugins

    For other possibilities, or to better understand why we disallow this, read this: https://ottopress.com/2010/dont-include-wp-load-please/

    If you’re trying to use it because you need to access WordPress functions outside of WordPress, we’d actually much rather you didn’t do that at all. Your plugin should be inside WordPress, only accessible to people who are logged in and authorized, if it needs that kind of access. Your plugin’s pages should be called via the dashboard like all the other settings panels, and in that way, they’ll always have access to WordPress functions.

Viewing 4 replies - 1 through 4 (of 4 total)
  • The topic ‘gpc_magic_quotes’ is closed to new replies.