bugtraq - Re: [Squid 2004-Nuke-001] Inadequate Security Checking in PHPNuke v7.3 and earlier

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>] [day] [month] [year] [list]

Date: 5 Jun 2004 12:50:33 -0000
From: Remy Wetzels <r.wetzels@...llo.nl>
To: bugtraq@...urityfocus.com
Subject: Re: [Squid 2004-Nuke-001] Inadequate Security Checking in PHPNuke
    v7.3 and earlier


In-Reply-To: <20040601184035.31371.qmail@....securityfocus.com>


>The process consists of capturing the currently executing script's path and 
>filename with the global variable $_SERVER['PHP_SELF'].  Using PHP's built-in 
>function eregi(), this value is then compared against the script's name 
>which should be the sole access point.
>
>Example:
>if (!eregi("admin.php", $_SERVER['PHP_SELF'])) { die ("Access Denied"); }
>
>In this example, a file with the above snippet will continue executing if 
>it was accessed by another file containing the letters "admin.php" (without 
>quotes) otherwise the script aborts returning the words "Access Denied".  
>
>Using eregi() with the NOT logical operator as done by PhpNuke's developers 
>is a very poor way to control file access because anyone can easily 
>manipulate a URL and add the missing component thereby forcing the security 
>check to always evaluate to false and gain unfettered entry.

Using eregi is NOT the problem. The problem is the usage of $_SERVER['PHP_SELF'] which can't handle URL requests which have a slash ('/') as their first character in the query_string and thinks this is part of it's path. Using SCRIPT_NAME is much safer...