Sie sind auf Seite 1von 1

Path Disclosure and PHP

In the past few days I've been testing a number of my own applications and scrip
ts as well as various bits and pieces of applications written by others that I u
se, using an automated scanning tool I have written. One particular issue I came
across, common to all applications is the inevitable "path disclosure vulnerabi
lity". The premise behind this so called vulnerability is that remote attackers
by specifying certain value can make the script report it's own location on disk
. Theoretically this combined with another vulnerability could be used to do *so
mething* or rather then potentially could be bad. As you can probably tell, I do
n't see this as a something to be terribly concerned about in most cases.
To demonstrate consider the following, most PHP function that take strings as pa
rameters, like our favorite validation functions such as htmlspecialchars(), add
slashes(), and so on will raise warnings when values they are passed are arrays
rather then strings. This means that to get the path of the script, you simply n
eed to pass the arguments as arrays rather then expected strings and then simply
read the warning message generated by PHP to see the error.
// script.php?name[]=foo instead of expected script.php?name=foo
$name = htmlspecialchars($_GET['name']);
// will emit:
// Warning: htmlspecialchars() expects parameter 1 to be string,
// array given in /path/to/script.php on line 2
To solve this problem there are just two solutions:
1) Disable displaying of errors to screen and instead log them to a file, so if
the Warning or Notice regarding array being used as a string is emitted, it won'
t be shown to the user using the site. This can be done within the script throug
ini_set(display_errors, 0);
ini_set(log_errors, 1);
ini_set(error_log, /path/to/php/errors);
2) Meticulously go through the code forcing PHP to cast the data to the desired
type, via (int), (float) or (string) casts, this too will eliminate the Notice o
r Warning message.