lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
From: mattmurphy at kc.rr.com (Matthew Murphy)
Subject: PHP Information Functions May Allow Cross-Site Scripting

>> The Irony:
>>
>> The comment lines directly above the expose_php directive in the default
>> config file specifically say that it is "no security threat", but having
it
>> enabled opens you to an XSS?  Food for thought...
>
>Sorry but this is simply not true. You are only vulnerable if you provide
>a script that calls phpinfo(); AND(!) have expose_php on.
>I already said at different places that you cannot blame insecure
programming
>onto the language. There is absolutely NO reason to have a phpinfo() script
>on a production server, because it reveals too much information.

I wasn't blaming people's insecure code on the language, simply having a
little fun with the fact that an option that is "no security threat"
*contributes to* (note I did not use *create* in that sentence) the
existance of a security threat.  There is really no disagreement on the
stupidity of allowing phpinfo() details to be available to anonymous users,
however, some servers, and some web applications do it, and many web servers
ship with similar things (Apache's printenv.pl, for example), which have had
other issues similar to this one.  While it is careless, it is unfortunately
very common.  Sorry for my lack of clarity in the previous post. :-(


Powered by blists - more mailing lists