On Wed, Jan 4, 2012 at 9:07 PM, Paul Dragoonis <dragoo...@gmail.com> wrote: > Inline. > > On Wed, Jan 4, 2012 at 8:02 PM, Rasmus Lerdorf <ras...@php.net> wrote: >> On 01/04/2012 11:54 AM, Nikita Popov wrote: >>> On Wed, Jan 4, 2012 at 8:50 PM, Rasmus Lerdorf <ras...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
