There are so many good reasons to turn off display_error during production use, one of which is to not have a broken page due to errors appearing all over the place which even the laziest PHP developer who only cares about "stuff working" would appreciate.

That it also leaks important internal information is another side-effect which generally isn't as appreciated though.

Also the article is showing this code:

    // Undefined function
    error_reporting(E_ALL);
    echo $_GET['funct']();

    eval($_GET['data']);

    echo "the root password for this machine is: pAsswoRd";

Or someone can send you a URL that points to your dev server and contains a payload. Or someone can send a URL to the developer across the street who uses shared hosting where display_errors is enabled by default.

I'm not arguing that this is a feasible attack to pull off against most applications: it most certainly is not. I'm arguing that it shouldn't be possible to pull it off at all, even in the small percentage of applications that might be affected. There is no good reason PHP should be displaying this information unsanitized.

---

You're 100% correct about the example you're pointing out. If you're allowing arbitrary functions called from the user, you're in much bigger trouble. ;-)

I originally noticed and reported the issue with the first example, which triggers a simple, common undefined index notice:

    <?php
    error_reporting(E_ALL);
    $array = array();
    echo $array[$_GET['index']];

That is theoretically possible, though what they would be able to do is to deal damage to my development install (if I don't to CSRF protection on POST operations) or they could potentially hijack my current session on my development system, which, too I don't deem too critical.

> who uses shared hosting where display_errors is enabled by default

   init_set('display_errors', 0);

> There is no good reason PHP should be displaying this information unsanitized.

I agree, especially because they already do some escaping of their own errors (and consequently don't escape while running in the CLI SAPI)

http://www.google.com/codesearch#search/&q=%5C$_GET%5C%5...

For those of you working with WordPress, this is the code you need in wp-config.php to log errors but not show them in web pages:

    define('WP_DEBUG', true);
    define('WP_DEBUG_DISPLAY', false);
    define('WP_DEBUG_LOG', true);

From the PHP docs [1]:

    This is a feature to support your development and should never be used on production systems (e.g. systems connected to the internet).

So could PHP perhaps HTML encode error messages? Would this break any error message use cases? For example are there times when error messages appear when they wouldn't be interpreted as HTML encoded? CLI? Browsers loading different text mime types?

[1] http://www.php.net/manual/en/errorfunc.configuration.php#ini...

This is something PHP already gets right with warnings, fatal errors, etc. The issue is only with notices as far as I've seen (I haven't delved into the PHP source to see what the difference is).

A demonstration file:

    [cmd]$ cat 147b9119e818c92f7f74bad71cc12255.php
    <?php
    echo file_get_contents('<s>test</s>');

    [cmd]$ php -f 147b9119e818c92f7f74bad71cc12255.php

    Warning: file_get_contents(<s>test</s>): failed to open stream: No such file or directory in /home/nbsandbox/sandboxing.me/poc/147b9119e818c92f7f74bad71cc12255.php on line 2

http://sandboxing.me/poc/147b9119e818c92f7f74bad71cc12255.ph...

    <br />
    <b>Warning</b>:  file_get_contents(&lt;s&gt;test&lt;/s&gt;) [<a href='function.file-get-contents'>function.file-get-contents</a>]: failed to open stream: No such file or directory in <b>/home/nbsandbox/sandboxing.me/poc/147b9119e818c92f7f74bad71cc12255.php</b> on line <b>2</b><br />

I wrote up a response which contains more acceptable conclusions/fixes to the issues you present.

http://randomdrake.com/2011/08/18/no-php-errors-and-notices-...