當想要在伺服器的開source指令碼代碼中發掘跨站指令碼漏洞時,使用靜態分析方法可以使我們的分析過程變得更加簡單並且自動化,另外,網上也可以找到許多相關的工具。
我近期發現了一種通過尋找共性pattern在PHPsource碼中發掘跨站指令碼漏洞的簡單方法。該方法是使用一個名為 XSSaminer 的工具,該工具根據grep建立,並使用bash語言編寫。
工具介紹
它首先會檢查指令碼參數:
if [ -z $1 ]then echo -e "Usage:\n$0FILE\n$0 -r FOLDER" exitelse f=$1fi
程式碼分析:如果第一行的參數$1為空白,就顯示使用$0作為指令碼名的用例並終止程式;否則,就將該參數分配給主函數中使用的f變數。
sources=(GET POST REQUEST "SERVER\['PHP""SERVER\['PATH_" "SERVER\['REQUEST_U")sinks=(echo die printprintfprint_rvar_dump)
接下來是帶有不完整字串的source和sink,之所以不完整,是因為它們只用於匹配。sink使用source,如果可以相互匹配(在沒有任何過濾的情況下),我們就需要考慮是否有使用者輸入注入到已經產生的HTML代碼中。
如果sink中使用了GET、POST或REQUEST全域變數,那麼這很明顯就是注入問題。但是SERVER有一些特殊的地方,假設輸入以下網址(帶有破壞HTML 屬性的注入):
http://domain/page.php/">
儘管上面只提到了三個SERVERsource,但是我們卻可以在上述代碼中找到四個SERVER,如下:
$_SERVER[‘PHP_SELF’] – returns the current URL decodedhttp://domain/page.php/">$_SERVER[‘PATH_TRANSLATED’] – returns file path on the system/var/www/html/page.php/">$_SERVER[‘PATH_INFO’] – returns info between page name and querystring (?)/">$_SERVER[‘REQUEST_URI’] – returns the current URLhttp://domain/page.php/">
最後一個,REQUEST_URI,沒有將URL特殊字元解碼成雙引號(“)或小於符號(<),但是由於瀏覽器使用這些已編碼的字元建立請求,因此,這是一個隱患。但是它只應用在儲存型XSS中,用於攔截和編輯瀏覽器請求(或使用其他HTTP用戶端),或者在載入sink前在PHP代碼的其他位置進行解碼。
xssam(){ fori in ${sources[@]} do a=$(grep-in "\$_${i}" $f | grep -o "\$.*=" | sed "s/[]\?=//g" | sort -u) forj in ${sinks[@]} do grep--color -in "${j}.*\$_${i}" $f fork in $a do grep--color -in "${j}.*$k" $f done done done}
Xssam 函數用於結合source和sink,通過前兩個“for”迴圈找到直接的隱患位置,“a”變數用於擷取接收不安全的全域值(source)的變數名稱。藉助第三個“for”迴圈實現一級的指令碼變數追蹤。
if [ $f != "-r" ]then xssamelse for i in $(find $2 -type f -name "*.php") do echo "File: $i" f=$i xssam donefi
在主代碼中,這段指令碼用於選擇是單個檔案調用xssam函數還是進入遞迴模式。該過程通過使用命令列中提供的帶有-r選項(代替檔案名稱)的檔案夾($2)來滿足另一個“for”迴圈中相同的函數調用。
用例:
./xssaminerFILE (單個檔案)./xssaminer-r FOLDER (遞迴模式, 檔案夾中所有的.php檔案)
XSSaminer 的主要目標是比較容易實現的XSS,而且經常會出現誤判,但是它的LoC/result率是十分高的。
測試執行個體
如下為該工具對WordPress主題 Rational Lite 的測試結果:
它在 2 個不同的檔案中找到了 3 個 XSS 漏洞,但是第二個為誤判,第一個得到確認:
通過在整個模組檔案中追蹤存在漏洞的代碼,發現當使用dismiss_id GET參數回調未認證的ajax操作時會彈出警告,一個0day漏洞出現了。