$_SERVER['PHP_SELF']在开发的时候常会用到，一般用来引用当前网页地址，并且它是系统自动生成的全局变量，也会有什么问题么？让我们先看看下面的代码吧：

<form action=”<?php echo $_SERVER['PHP_SELF']; ?>”>
 <input type=”submit” name=”submit” value=”submit” />
</form>

这段代码非常简单，我们想用$_SERVER['PHP_SELF']来让网页提交时提交到它自己，假设代码文件名为test.php，在执行的时候就一定会得到我们期望的地址么？首先试试地址http://…/test.php，结果当然是没有问题的啦，别着急，你再访问一下http://…/test.php/a=1，将会得到如下客户端代码：

<form action=”/fwolf/temp/test.php/a=1″>
 <input type=”submit” name=”submit” value=”submit” />
</form>

显然，这已经超出了我们的期望，web服务器居然没有产生诸如404之类的错误，页面正常执行了，并且在生成的html代码中居然有用户可以输入的部分，恐怖的地方就在这里。别小看那个“a=1”，如果把它换成一段js代码，就显得更危险了，比如这么调用：

http://…/test.php/%22%3E%3Cscript%3Ealert(‘xss’)%3C/script%3E%3Cfoo

是不是看到了js的alert函数执行的效果？检查一下生成的html源代码找找原因吧。

通过这种嵌入js代码的方式，攻击者能夠获得512～4k的代码空间，甚至还可以连接外部网站的js代码或者通过image调用来伪装js代码的方式，那样js代码的长度就不受限制了，然后通过js，他们可以轻松的获取用户的cookie，或者更改当前页面的任何内容，比如更改表单提交的目的地，更改显示的内容（比如给一个<a>链接地址增加一个onclick=…的属性，这样用户点击的时候就会执行攻击者指定的代码，甚至连接到并非此链接地址本身的网站），甚至作出一个ajax效果来也不一定，总之，不要忽视js的威力。

那么，再来看看这个漏洞产生的原理，首先test.php/….这种调用是web服务器允许的，很多cms系统，比如我以前用过的plog，好像也是采用这种方式，在服务器不支持rewrite的情况下实现诸如http://…/index.php/archive/999这样的固定网址的（我以前还以为是对404错误页下的手），所以带“/”的地址无法从web服务器上禁止。然后再看看php中对$_SERVER['PHP_SELF']的识别，他就是一个包含当前网址值的全局变量，天知道用户会输入什么样的网站，在上面的例子中是恶意的，可是在wikipedia这样的网站上，却又是可以正常使用这种方式的地址的。所以，最终的结论要落在开发人员身上了，没有很好的处理与用户交互的数据。

从安全角度来讲，在开发应用尤其是web应用的时候，所有用户提交的数据都是不安全的，这是基本原则，所以我们才不厌其烦的又是客户端验证又是服务端验证。从上面说的这个安全漏洞来讲，不安全的内容中又要增加“网址”一条了。要解决$_SERVER['PHP_SELF']的安全隐患，主要有以下2种方式：

1、htmlentities 用htmlentities($_SERVER['PHP_SELF'])来替代简单的$_SERVER['PHP_SELF']，这样即使网址中包含恶意代码，也会被“转换”为用于显示的html代码，而不是被直接嵌入html代码中执行，简单一点说，就是“<”会变成“&lt;”，变成无害的了。

2、REQUEST_URI 用$_SERVER['REQUEST_URI']来替代$_SERVER['PHP_SELF']，在phpinfo()中可以看到这两个变量的区别：

_SERVER["REQUEST_URI"] /fwolf/temp/test.php/%22%3E%3Cscript%3Ealert(‘xss’)%3C/script%3E%3Cfoo
_SERVER["PHP_SELF"] /fwolf/temp/test.php/”&gt;&lt;script&gt;alert(‘xss’)&lt;/script&gt;&lt;foo

$_SERVER['REQUEST_URI']会原封不动的反映网址本身，网址中如果有%3C，那么你得到的也将会是%3C，而$_SERVER['PHP_SELF']会对网址进行一次urldecode操作，网址中的%3C将会变成字符“<”，所以就产生了漏洞。需要注意的是，在很多情况下，浏览器会对用户输入要提交给web服务器的内容进行encode，然后服务器端程序会自动进行decode，得到相应的原指，在我们进行post或者get操作的时候都是这样。

另外还有两点需要指出，第一是<form action=”">这种写法虽然没有直接用到$_SERVER['PHP_SELF']，但实际效果却是一样的，只是发生的时间错后到了用户提交之后的下一个页面，所以，form的action还是不要留空的好。第二点，除了PHP_SELF之外，其他的$_SERVER变量也许也会有类似的漏洞，比如SCRIPT_URI, SCRIPT_URL, QUERY_STRING, PATH_INFO, PATH_TRANSLATED等等，在使用他们之前一定要先作htmlentities之类的转换。

最后，提供一个地址，里面有很多XSS的例子，可以作为反面教材或者测试工具： XSS (Cross Site Scripting) Cheat Sheet

Update @ 2007-07-31

SCRIPT_URI在cgi方式下或者在某些虚拟主机上无法使用：

Notice: Undefined index: SCRIPT_URI in ……

所以就只能用REQUEST_URI了：

((isset($_SERVER["HTTPS"]) && ‘on’ == $_SERVER["HTTPS"]) ? ‘https://’ : ‘http://’) . $_SERVER["HTTP_HOST"] . $_SERVER['REQUEST_URI'];

无相关文章，以下随机显示

• 2009年02月27号 -- 面向站长和网站管理员的Web缓存加速指南
• 2009年06月15号 -- 16个简单实用的.htaccess小贴示
• 2009年01月22号 -- apache最大连接数性能测试
• 2008年12月29号 -- 使用apachebench进行post压力测试
• 2009年02月27号 -- header Content-Type类型
• 2009年02月10号 -- Apache高级配置中文详解
• 2009年02月7号 -- Linux下查看apache连接数
• 2009年02月22号 -- 在Windows上手动配置Apache下面的虚拟主机站点
• 2009年02月10号 -- Apache 中内存管理的三种境界
• 2009年01月6号 -- php+mysql+apache编码深度解析