現(xiàn)在的web服務(wù)器和開發(fā)工具雖然不會再出現(xiàn)像asp的%81那樣明顯的漏洞了，但是由于開發(fā)人員的疏忽和各種語言特性組合造成的一些奇異的漏洞仍然會存在。今天偶然讀到的XSS Woes，就詳細(xì)講述了和$_SERVER[’PHP_SELF’]相關(guān)的一個危險(xiǎn)漏洞。

　　$_SERVER[’PHP_SELF’]在開發(fā)的時候常會用到，一般用來引用當(dāng)前網(wǎng)頁地址，并且它是系統(tǒng)自動生成的全局變量，也會有什么問題么？讓我們先看看下面的代碼吧：

????

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

　
　　這段代碼非常簡單，我們想用$_SERVER[’PHP_SELF’]來讓網(wǎng)頁提交時提交到它自己，假設(shè)代碼文件名為test.php，在執(zhí)行的時候就一定會得到我們期望的地址么？首先試試地址http://…/test.php，結(jié)果當(dāng)然是沒有問題的啦，別著急，你再訪問一下http://…/test.php/a=1，將會得到如下客戶端代碼：

?

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

?

?

　　顯然，這已經(jīng)超出了我們的期望，web服務(wù)器居然沒有產(chǎn)生諸如404之類的錯誤，頁面正常執(zhí)行了，并且在生成的html代碼中居然有用戶可以輸入的部分，恐怖的地方就在這里。別小看那個“a=1”，如果把它換成一段js代碼，就顯得更危險(xiǎn)了，比如這么調(diào)用：

?

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

?

　　是不是看到了js的alert函數(shù)執(zhí)行的效果？檢查一下生成的html源代碼找找原因吧。

　　通過這種嵌入js代碼的方式，攻擊者能夠獲得512～4k的代碼空間，甚至還可以連接外部網(wǎng)站的js代碼或者通過image調(diào)用來偽裝js代碼的方式，那樣 js代碼的長度就不受限制了，然后通過js，他們可以輕松的獲取用戶的cookie，或者更改當(dāng)前頁面的任何內(nèi)容，比如更改表單提交的目的地，更改顯示的內(nèi)容（比如給一個<a>鏈接地址增加一個οnclick=…的屬性，這樣用戶點(diǎn)擊的時候就會執(zhí)行攻擊者指定的代碼，甚至連接到并非此鏈接地址本身的網(wǎng)站），甚至作出一個ajax效果來也不一定，總之，不要忽視js的威力。

　　那么，再來看看這個漏洞產(chǎn)生的原理，首先test.php/….這種調(diào)用是web服務(wù)器允許的，很多cms系統(tǒng)，比如我以前用過的plog，好像也是采用這種方式，在服務(wù)器不支持rewrite的情況下實(shí)現(xiàn)諸如http: //…/index.php/archive/999這樣的固定網(wǎng)址的（我以前還以為是對404錯誤頁下的手），所以帶“/”的地址無法從web服務(wù)器上禁止。然后再看看php中對$_SERVER[’PHP_SELF’]的識別，他就是一個包含當(dāng)前網(wǎng)址值的全局變量，天知道用戶會輸入什么樣的網(wǎng)站，在上面的例子中是惡意的，可是在wikipedia這樣的網(wǎng)站上，卻又是可以正常使用這種方式的地址的。所以，最終的結(jié)論要落在開發(fā)人員身上了，沒有很好的處理與用戶交互的數(shù)據(jù)。

　　從安全角度來講，在開發(fā)應(yīng)用尤其是web應(yīng)用的時候，所有用戶提交的數(shù)據(jù)都是不安全的，這是基本原則，所以我們才不厭其煩的又是客戶端驗(yàn)證又是服務(wù)端驗(yàn)證。從上面說的這個安全漏洞來講，不安全的內(nèi)容中又要增加“網(wǎng)址”一條了。要解決$_SERVER [’PHP_SELF’]的安全隱患，主要有以下2種方式：

　　1、htmlentities

　　用htmlentities($_SERVER [’PHP_SELF’])來替

?

簡單的$_SERVER[’PHP_SELF’]，這樣即使網(wǎng)址中包含惡意代碼，也會被“轉(zhuǎn)換”為用于顯示的html代碼，而不是被直接嵌入html代碼中執(zhí)行，簡單一點(diǎn)說，就是“<”會變成“&lt;”，變成無害的了。

　　2、REQUEST_URI

　　用$_SERVER[’REQUEST_URI’]來替代$_SERVER[’PHP_SELF’]，在phpinfo()中可以看到這兩個變量的區(qū)別：

?

_SERVER[”REQUEST_URI”]?/fwolf/temp/test.php/%22%3E%3Cscript%3Ealert(’xss’)%3C/script%3E%3Cfoo

_SERVER[”PHP_SELF”]?/fwolf/temp/test.php/”><script>alert(’xss’)</script><foo

?

?

　　$_SERVER [’REQUEST_URI’]會原封不動的反映網(wǎng)址本身，網(wǎng)址中如果有%3C，那么你得到的也將會是%3C，而$_SERVER [’PHP_SELF’]會對網(wǎng)址進(jìn)行一次urldecode操作，網(wǎng)址中的%3C將會變成字符“<”，所以就產(chǎn)生了漏洞。需要注意的是，在很多情況下，瀏覽器會對用戶輸入要提交給web服務(wù)器的內(nèi)容進(jìn)行encode，然后服務(wù)器端程序會自動進(jìn)行decode，得到相應(yīng)的原指，在我們進(jìn)行post或者get操作的時候都是這樣。

　　另外還有兩點(diǎn)需要指出，第一是<form action”">這種寫法雖然沒有直接用到$_SERVER[’PHP_SELF’]，但實(shí)際效果卻是一樣的，只是發(fā)生的時間錯后到了用戶提交之后的下一個頁面，所以，form的action還是不要留空的好。第二點(diǎn)，除了PHP_SELF之外，其他的$_SERVER變量也許也會有類似的漏洞，比如SCRIPT_URI, SCRIPT_URL, QUERY_STRING, PATH_INFO, PATH_TRANSLATED等等，在使用他們之前一定要先作htmlentities之類的轉(zhuǎn)換。

　　最后，提供一個地址，里面有很多XSS的例子，可以作為反面教材或者測試工具：

　　XSS (Cross Site Scripting) Cheat Sheet

　　http://ha.ckers.org/xss.html

?

轉(zhuǎn)載于:https://www.cnblogs.com/xiaochaohuashengmi/archive/2010/05/08/1730494.html

總結(jié)

以上是生活随笔為你收集整理的针对$_SERVER[’PHP_SELF’]的跨站脚本攻击（XSS）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。