Would I be taking a big security risk by trusting the content of the $_SERVER variable array to get the name of php file using $_SERVER['PHP_SELF']?
-
1You need to give us more details. Which variable are you looking at, and in what context are you using it? – Brad Nov 22 '10 at 16:34
-
2@Aurel300, that would have been my guess, but I have been fooled before... – Brad Nov 22 '10 at 16:40
-
You got the wrong answer. check mine. – rook Nov 22 '10 at 18:37
4 Answers
Many but not all of the $_SERVER variables are attacker controlled. For instance $_SERVER['SCRIPT_NAME']
is safe where as $_SEVER['PHP_SELF']
is a vary dangerous variable and is often the source of xss:
<?php
echo $_SEVER['PHP_SELF'];
?>
PoC:
http://localhost/self.php/<script>alert(/xss/)</script>
It is easy to see this vulnerability in action by looking at phpinfo.
-
Rook, can you point me to some documentation about why $_SEVER['PHP_SELF'] is dangerous and why $_SERVER['SCRIPT_NAME'] is safe? I do not know a lot about the different values in $_SERVER and would like to understand more. – CLJ Nov 22 '10 at 18:44
-
1@Chris J, sure no problem I assume you ran my example of an xss vulnerability. But perhaps a better example is phpinfo: https://cgi.ccs.neu.edu/home/cgiadmin/examples/phpinfo.php/%3Cscript%3Ealert(/xss/)%3C/script%3E – rook Nov 22 '10 at 19:47
-
Wow, that is amazing! $_SERVER['SCRIPT_NAME'] is the name of the file, no more and $_SEVER['PHP_SELF'] can be coerced in taking "/" as a part of its filename. Good catch, and thank you! – CLJ Nov 22 '10 at 20:11
There is no special mechanism in effect to protect this variable. You can write to it as you can to any other variable. So you have to protect it against tampering like any other variable (disable register_globals, avoid variable variables, etc.). Then you can trust it.
As a workaround to be sure, you can define your own constants early in your program:
define('SCRIPT_FILENAME',$_SERVER['SCRIPT_FILENAME']);
and use predefined constants where available, e.g. __FILE__
.

- 32,613
- 18
- 106
- 168
From the php.net manual:
The entries in this array are created by the web server. There is no guarantee that every web server will provide any of these; servers may omit some, or provide others not listed here.
So, if you are aware of all users who have access to change server configuration, (and all scripts in your session that may modify the contents of the variable) you can be reasonably sure of the $_SERVER
variable's data.

- 18,827
- 9
- 60
- 98
-
1Note that this isn't always true. `$_SERVER['HTTP_HOST']` is changeable by the user. – ceejayoz Nov 22 '10 at 16:37
-
1Note, *reasonably* sure. The OP was concerned with `PHP_SELF`, not `HTTP_HOST`. :) – Stephen Nov 22 '10 at 16:39
Not at all, this can not actually be a risk at all as long as you don't use data from user. That is, use one of these:
echo __FILE__;
// is the same as
echo $_SERVER["SCRIPT_FILENAME"];
echo $_SERVER["SCRIPT_NAME"];
// SCRIPT_NAME contains just the path

- 7,068
- 1
- 21
- 34
-
-
I did not check but I'm pretty sure that $_SERVER['SCRIPT_FILENAME'] gives the path of the requestes script while `__FILE__` gives the path of the file it is used in, which is a completely different thing. – AndreKR Nov 22 '10 at 16:39
-
Sure. It is in the manual though. But anyway, it is mostly more important to get the name of the file that included, not the included file - opened files and more included files are still going to be relative to the "parent" file's path. – Aurel Bílý Nov 22 '10 at 17:06