Re: Maksymilian Arciemowicz

[frantisek holop <minusf () obiit org>]

hmm, on Tue, May 16, 2006 at 08:37:11PM -0000, cxib () securityreason com said that

[snip]

> The solution is to analyze all input variables and all checkings (for
> example: is_string). Error displaying could be disabled, but I would
> rather suggest correcting the code.

you present the solution yourself: display_errors

from php.ini:
; - display_errors = Off           [Security]
;     With this directive set to off, errors that occur during the execution of
;     scripts will no longer be displayed as a part of the script output, and thus,
;     will no longer be exposed to remote users.  With some errors, the error message
;     content may expose information about your script, web server, or database
;     server that may be exploitable for hacking.  Production sites should have this
;     directive set to off.


admins don't have the time (and/or the expertise) to go and hunt for
things like this.  auditing code like this for admins is a waste of
time.  not for the authors of course.  on production machines
display_errors should be simply turned off.  if i were the php people
i would make it even the default (if it is not already).

there must be like thousands of cases like this out there, not enforcing
the types to 100%.  and i don't even think it's practical in every case.
if the variable type misuse does not produce any usable error message or
info, the attacker will simply get bored and go away.  or perhaps tries
a filling-the-log-partition DoS in frustration :)

-f
-- 
the smallest handcuff in the world is a wedding ring.