Stripslashed to death? – End the Madness!

Another highly biased post with much #WTF potential as it’s typed on twitter: In WordPress there is some pretty stinky code. I always make a joke about the plain wrong slogan “Code is poetry” [sic!] where if that would be, WordPress code is the scribbling you find on loo’s doors in bars while having a shit. WordPress is Artwork and not Software? Me is the prince of Wales, ja ja.

Do not say you can not run a business on WordPress!

Sir Spam-A-Lot

I put the finger on the strip-slash-madness long ago in (#5791). It’s one thing to do stuff plain wrong, but another to not correct mistakes made. And that is pretty much what is happening here. It’s all so outch since two years for that one. I must stop to rant right away or I’ll go on till midnight. Let’s stick a bit more on topic:

In #10360 / [11760] $_REQUEST as the last resort to contain userinput that is to be expected from a PHP coders point of view had fallen. Since then it seemed that the Roman Empire has conquered the whole plains of all plugins. All plugins? No, there is some little piece of code in the North that still doing resistance. You are curious how to obtain the user input? How to truly obtain it?

PHP build-in alternatives to $_POST and $_GET

PHP Streams can do that. At least somehow:

php://input allows you to read raw POST data. It is a less memory intensive alternative to $HTTP_RAW_POST_DATA and does not need any special php.ini directives. php://input is not available with enctype="multipart/form-data".

Here’s a simple function to give you an uncorrupted version of $_POST:

<?php
// Function to fix up PHP's messing up POST input containing dots, etc.
function getRealPOST() {
    $pairs = explode("&", file_get_contents("php://input"));
    $vars = array();
    foreach ($pairs as $pair) {
        $nv = explode("=", $pair);
        $name = urldecode($nv[0]);
        $value = urldecode($nv[1]);
        $vars[$name] = $value;
    }
    return $vars;
}

/*
The full list of field-name characters that PHP converts to _ (underscore) is the following (not just dot):
chr(32) ( ) (space)
chr(46) (.) (dot)
chr(91) ([) (open square bracket)
chr(128) - chr(159) (various)
*/
?>

Not my idea, taken from over here.

And for get requests? There is some variable which could:

$_SERVER['REQUEST_URI'] and $_SERVER['REQUEST_URL']

URI provides the entire request path (/directory/file.ext?query=string)
URL provides the request path, without the query string (/directory/file.ext)

Source

Ultimately Cookies are lost – please proof me wrong on that one in comments.

Original Request

Another Idea I had this week is to save the original request to somehow create a “sandbox” to let WP run in. The only problem is on how to protect it to get overwritten again. So all this is something you need to configure on your own server. The easiest thing to do this is to change the wordpress “frontend controller” (more correctly: entry point) index.php to your own and then route the request back into it. Keep in mind that there are other entry-points as well, xmlrpc and ajax for example.

Rant: Off

Rant off: There is more “escape” madness in the wordpress codebase. This is mainly due to the fact, that there is no real concept how to deal with input and data by convention. W/o any guidance, everything needs to be escaped everywhere and all over and over again on best guess to not leave your blog open to attacks. With such a misconception it is obviously very hard to gain true data and execution security. It took WordPress multiple years to come close to a somehow that what “secure” it is today. This is only in terms of already discovered exploits, not strictness in data handling and execution as written. And I do not speak for WordPress 3.0 which will be some step backwards in this sense. But there is always process: #12416. Take care.

I started this post because I ran over the PHP:// stream note in the PHP docs while doing some other coding. Don’t get me wrong, those you love you criticize. We’re in here to make things better. Finally 😀