針對$_SERVER[’PHP_SELF’]的跨站腳本***

文章來源:http://www.zhuaxia.com/item/233389902

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

$_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>鏈接地址增加一個 本身的網站),甚至作出一個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代碼中執行,簡單一點說,就是“<”會變成“<”,變成無害的了。

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/”><script>alert(’xss’)</script><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

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

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章