full-disclosure - PHP Information Functions May Allow Cross-Site Scripting

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]

Message-ID: <001401c272c6$54df3300$e62d1c41@kc.rr.com>
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. :-(