Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:57202
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain googlemail.com designates 209.85.215.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAKxcST9NhATxVLrOVP9h2Qy9GfuuzreeVMBtH0EqdZf7jPhytg@mail.gmail.com>
References: <CABBJUpc7T2QZm8QiitQ0wZ5RsY=3Jwy_UERSvLT9unNYtJ1mZA@mail.gmail.com>
	<CABBJUpcVkYwU4zN0dG2b+jYkppnY9HR8wm7FV0tnmGt6ky5wQg@mail.gmail.com>
	<CABBJUpeN4iJ6mVUKEEz8qxY25zxTmwg8EigpsmxnZGz5xshMhw@mail.gmail.com>
	<4F048A03.4070408@sugarcrm.com>
	<CAH-PCH69gV88qnQ7OHhGHSt70oD7f9Z_HCFD7dfW6SmBR6z2tQ@mail.gmail.com>
	<4F04A172.7080509@sugarcrm.com>
	<CAH-PCH5BUsrXKLtk6JWCOA8d5+2DxSke3UAnbBraJyGP-YnQnA@mail.gmail.com>
	<4F04AA8E.6020701@sugarcrm.com>
	<CAH-PCH6YH3ZxH5XzEm6+gsikaHjyL-pdHyAs=OnFhWqHk0CctQ@mail.gmail.com>
	<4F04AD6D.80608@php.net>
	<CAF+90c-6XrWJnL4vOQjjPm=N=fWrMy31wHOeXGccv+KRq5DrVw@mail.gmail.com>
	<4F04B071.8080102@php.net>
	<CAKxcST9NhATxVLrOVP9h2Qy9GfuuzreeVMBtH0EqdZf7jPhytg@mail.gmail.com>
Date: Wed, 4 Jan 2012 21:17:57 +0100
Message-ID: <CAF+90c_dOoLUoZAN_2uwtjowrjZSjmu2DAHkstFSFH5Po8JhyQ@mail.gmail.com>
To: Paul Dragoonis <dragoonis@gmail.com>
Cc: Rasmus Lerdorf <rasmus@php.net>, Ferenc Kovacs <tyra3l@gmail.com>, 
	Stas Malyshev <smalyshev@sugarcrm.com>, Laruence <laruence@php.net>, 
	PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] Re: another fix for max_input_vars.
From: nikita.ppv@googlemail.com (Nikita Popov)

On Wed, Jan 4, 2012 at 9:07 PM, Paul Dragoonis <dragoonis@gmail.com> wrote:
> Inline.
>
> On Wed, Jan 4, 2012 at 8:02 PM, Rasmus Lerdorf <rasmus@php.net> wrote:
>> On 01/04/2012 11:54 AM, Nikita Popov wrote:
>>> On Wed, Jan 4, 2012 at 8:50 PM, Rasmus Lerdorf <rasmus@php.net> wrote:
>>>> Since it is one of these remotely-triggered errors that you can't
>>>> program around, it should probably be suppressed when display_errors is
>>>> on. There is another precedence for this, but I am drawing a blank on
>>>> where else we did this right now.
>>>>
>>>> -Rasmus
>>> You mean like with htmlspecialchars() before PHP 5.4? Please don't.
>>> It's really non-obvious to start hiding errors as soon as you enable
>>> error display.
>>
>> But there is a very valid security concern here. People can usually run
>> safely with display_errors enabled if their code is well-written. They
>> can check for potential errors and avoid them. This one can't be checked
>> for and you could easily write a scanner that scoured the Net for sites
>> with display_errors enabled by sending a relatively short POST request
>> to each one and checking for this error. And there is absolutely nothing
>> people could do about this short of turning off display_errors which we
>> know from experience a lot of people just don't do no matter how much we
>> suggest it.
>
> I agree with Rasmus here. A lot of people keep display_errors on, even
> when they shouldn't.
> It log_errors is on, it should go to the error_log, but with
> display_errors it should never be sent back to the browser.

I simply fear that we are facing the same problem with this as we did
with htmlspecialchars(). Sure, the behavior was meant nice in the
first place, but in reality it basically made debugging hard for the
good guys (you know, with display_errors=Off on production and =On on
development), because they wouldn't see the error while developing.

I can imagine the same with this: If you develop some application
using lots and lots of POST variables (1000+) [for whatever reason]
and you notice that some of those vars just don't submit you'll have a
really hard time debugging this. With the warning the issue on the
other hand would be obvious.

I really don't like the idea to punish normal developers with hard
debugging only to make life easier for terrible server admins. I
understand that as this is a security issue things are a bit more
complicated, but I still don't really think this is a good idea.

By the way, an attacker could also find out the limit by measuring
page load times with various POST data sizes quite easily (I would
think so at least), so I wouldn't say it's "otherwise unobtainable".

Nikita