码迷,mamicode.com
首页 > Web开发 > 详细

PHP的$_SERVER['PHP_SELF']造成的XSS漏洞攻击及其解决方案

时间:2016-07-14 13:28:59      阅读:134      评论:0      收藏:0      [点我收藏+]

标签:

$_SERVER[‘PHP_SELF‘]简介

$_SERVER[‘PHP_SELF‘] 表示当前 PHP文件相对于网站根目录的位置地址,与 document root 相关。

假设我们有如下网址,$_SERVER[‘PHP_SELF‘]得到的结果分别为:

http://www.php-note.com/php/    :   /php/test.php
http://www.php-note.com/php/test.php    :    /php/test.php
http://www.php-note.com/php/test.php?test=foo    :    /php/test.php
http://www.php-note.com/php/test.php/test/foo    :    /php/test.php/test/foo

 因此,可以使用 $_SERVER[‘PHP_SELF‘] 很方便的获取当前页面的地址:

$url = "http://". $_SERVER[‘HTTP_HOST‘] . $_SERVER[‘PHP_SELF‘];

上面是简单获取 http 协议的当前页面 URL ,只是要注意该地址是不包含 URL 中请求的参数(?及后面的字串)的。如果希望得到包含请求参数的完整 URL 地址,请使用 $_SERVER[‘REQUEST_URI‘] 。

 

PHP $_SERVER[‘PHP_SELF‘] 安全性

由于利用 $_SERVER[‘PHP_SELF‘] 可以很方便的获取当前页面地址,因此一些程序员在提交表单数据到当前页面进行处理时,往往喜欢使用如下这种方式:

<form method="post" action="<?php echo $_SERVER[‘PHP_SELF‘]; ?>">

假设该页面地址为:

http://www.php-note.com/php/test.php 

访问该页面,得到的表单 html 代码如下:

<form method="post" action="/php/test.php">

这段代码是正确的,但是当访问地址变成:

http://www.php-note.com/php/test.php/test/foo /a=1

页面正常执行了,表单 html 代码变成:

<form method="post" action="/php/test.php/test/foo/a=1"> 

显然,这已经超出了我们的期望,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,或者更改当前页面的任何内容,比如更改表单提交的目的地,更改显示的内容(比如给一个链接地址增加一个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/”> 

 

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

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

 

 

延伸阅读:

$_SERVER["SCRIPT_NAME"]、$_SERVER["PHP_SELF"]、$_SERVER["QUERY_STRING"]、$_SERVER["REQUEST_URI"]

 

PHP的$_SERVER['PHP_SELF']造成的XSS漏洞攻击及其解决方案

标签:

原文地址:http://www.cnblogs.com/52php/p/5670068.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!