安全基礎(chǔ)理論入門知識(shí)參考上一篇《WEB應(yīng)用安全測(cè)試指南藍(lán)隊(duì)安全測(cè)試1》

一、文件 I/O 類

1.1、任意文件上傳

漏洞描述：

• 一般情況下文件上傳漏洞是指用戶上傳了一個(gè)可執(zhí)行的腳本文件，并通過此腳本文件獲得了執(zhí)行服務(wù)器端命令的能力。文件上傳本身是 web 中最為常見的一種功能需求，關(guān)鍵是文件上傳之后服務(wù)器端的處理、解釋文件的過程是否安全。一般的情況有：
  1. 上傳文件WEB腳本語言，服務(wù)器的WEB容器解釋并執(zhí)行了用戶上傳的腳
     本，導(dǎo)致代碼執(zhí)行。
  2. 上傳文件FLASH策略文件crossdomain.xml，以此來控制Flash在該域下的行為。
  3. 上傳文件是病毒、木馬文件，攻擊者用以誘騙用戶或管理員下載執(zhí)行。
  4. 上傳文件是釣魚圖片或包含了腳本的圖片，某些瀏覽器會(huì)作為腳本執(zhí)
     行，可用于實(shí)施釣魚或欺詐。

檢查條件：

• 測(cè)試目標(biāo)具有文件上傳功能。

檢測(cè)方法：

• 上傳方式根據(jù)不同的 web 語言，檢測(cè)方法也各式各樣，以下列舉基于 JS
  驗(yàn)證的上傳的幾種常見的文件上傳繞過方法：

  1. 直接刪除代碼中onsubmit事件中關(guān)于文件上傳時(shí)驗(yàn)證上傳文件的相關(guān)代碼即可。如圖：
     

  2. 直接更改文件上傳 JS 代碼中允許上傳的文件擴(kuò)展名你想要上傳的文件擴(kuò)展名，如圖所示：
     

  3. 使用本地提交表單即可，如圖所示：
     

  4. 使用 burpsuite 或者是 fiddle 等代理工具提交，本地文件先更改為 jpg，上傳時(shí)攔截，再把文件擴(kuò)展名更改為 asp 即可，如圖所示：
     

  5. 當(dāng)然也有不是基于JS驗(yàn)證的上傳，例如一些中間件IIS，Nginx,，PHP,FCK編輯器等等的解析漏洞，其上傳繞過方式也是多種多樣。通過對(duì)上傳頁面進(jìn)行檢查，常見的文件上傳檢查針對(duì)文件類型進(jìn)行，可以使用手動(dòng)修改POST包然后添加%00字節(jié)用于截?cái)嗄承┖瘮?shù)對(duì)文件名的判斷。除了修改文件名來繞過類型檢查外，還可以修改文件頭來偽造文件頭，欺騙文件上傳檢查，如圖，修改文件頭中的類型來進(jìn)行繞過：
     

  以上為幾種常見的上傳，更多的還需自行研究，進(jìn)行上傳繞過。以下為總體的測(cè)試流程：

  1、登陸網(wǎng)站，并打開文件上傳頁面。

  2、點(diǎn)擊“瀏覽”按鈕，并選擇本地的一個(gè)JSP文件（比如hacker.jsp），確認(rèn)上傳。

  3、如果客戶端腳本限制了上傳文件的類型（比如允許gif文件），則把hacker.jsp更名為hacker.gif；配置HTTP Proxy（burp）進(jìn)行http請(qǐng)求攔截；重新點(diǎn)擊“瀏覽”按鈕，并選擇hacker.gift，確認(rèn)上傳。

  4、在WebScarab攔截的HTTP請(qǐng)求數(shù)據(jù)中，將hacker.gif修改為hacker.jsp，再發(fā)送請(qǐng)求數(shù)據(jù)。

  登陸后臺(tái)服務(wù)器，用命令find / -name hacker.jsp查看hacker.jsp文件存放的路徑。如果可以直接以Web方式訪問，則構(gòu)造訪問的URL，并通過瀏覽器訪問hacker.jsp，如果可以正常訪問，則已經(jīng)取WebShell，測(cè)試結(jié)束。如果hacker.jsp無法通過web方式訪問，例如hacker.jsp存放在/home/tmp/目錄下，而/home/tomcat/webapps目錄對(duì)應(yīng)http://www.example.com/，則進(jìn)行下一步

  5、重復(fù)1～3，在burp攔截的HTTP請(qǐng)求數(shù)據(jù)中，將hacker.gif修改為../tomcat/webapps/hacker.jsp，再發(fā)送請(qǐng)求數(shù)據(jù)。

  6、在瀏覽器地址欄輸入http://www.example.com/hacker.jsp，訪問該后門程序，取得WebShell，結(jié)束檢測(cè)。

漏洞等級(jí)：

【*高危*】：成功上傳惡意文件，并且解析 webshell。

修復(fù)方案：

1. 最有效的，將文件上傳目錄直接設(shè)置為不可執(zhí)行，對(duì)于Linux而言，撤銷其目錄的'x'權(quán)限；實(shí)際中很多大型網(wǎng)站的上傳應(yīng)用都會(huì)放置在獨(dú)立的存儲(chǔ)上作為靜態(tài)文件處理，一是方便使用緩存加速降低能耗，二是杜絕了腳本執(zhí)行的可能性；
2. 文件類型檢查：建議使用白名單方式，結(jié)合MIME Type、后綴檢查等方式（即只允許允許的文件類型進(jìn)行上傳）；此外對(duì)于圖片的處理可以使用壓縮函數(shù)或resize函數(shù)，處理圖片的同時(shí)破壞其包含的HTML代碼；
3. 使用隨機(jī)數(shù)改寫文件名和文件路徑，使得用戶不能輕易訪問自己上傳的文件；
4. 單獨(dú)設(shè)置文件服務(wù)器的域名。

1.2、任意文件下載

漏洞描述：

• 任意文件下載漏洞不同于網(wǎng)站目錄瀏覽，此漏洞不僅僅可遍歷系統(tǒng)下 web中的文件，而且可以瀏覽或者下載到系統(tǒng)中的文件，攻擊人員通過任意文件下載漏洞可以獲取系統(tǒng)文件及服務(wù)器的配置文件等等。一般來說，他們利用服務(wù)器 API、文件標(biāo)準(zhǔn)權(quán)限進(jìn)行攻擊。嚴(yán)格來說，任意文件下載漏洞并不是一種 web漏洞，而是網(wǎng)站設(shè)計(jì)人員的設(shè)計(jì)“漏洞”。

檢測(cè)條件：

• 測(cè)試目標(biāo)具有文件下載功能。

檢測(cè)方法：

1. 通過web漏洞掃描工具對(duì)網(wǎng)站實(shí)施掃描可能發(fā)現(xiàn)目錄遍歷或者任意文件下載漏洞，發(fā)送一系列”../”字符來遍歷高層目錄，并且嘗試找到系統(tǒng)的配置文件或者系統(tǒng)中存在的敏感文件。
2. 也可通過判斷網(wǎng)站語言，并根據(jù)其url中部分提供的參數(shù)，進(jìn)行構(gòu)造相關(guān)的路徑信息，如收集到網(wǎng)站中間件版本為apache，則想辦法構(gòu)造../../../WEB-INF/web.xml等，然后查看其是否可被下載出來。隨后可構(gòu)造下載系統(tǒng)文件。

漏洞等級(jí)：

【*高危*】:下載系統(tǒng)的任意文件，對(duì)系統(tǒng)進(jìn)行進(jìn)一步的入侵。

修復(fù)方案：

1. 凈化數(shù)據(jù)：對(duì)用戶傳過來的文件名參數(shù)進(jìn)行硬編碼或統(tǒng)一編碼，對(duì)文件類型進(jìn)行白名單控制，對(duì)包含惡意字符或者空字符的參數(shù)進(jìn)行拒絕。
2. web應(yīng)用程序可以使用chroot環(huán)境包含被訪問的web目錄，或者使用絕對(duì)路徑+參數(shù)來訪問文件目錄，時(shí)使其即使越權(quán)也在訪問目錄之內(nèi)。www目錄就是一個(gè)chroot應(yīng)用. 由chroot創(chuàng)造出的那個(gè)根目錄，叫做“chroot監(jiān)獄”（所謂"監(jiān)獄"就是指通過chroot機(jī)制來更改某個(gè)進(jìn)程所能看到的根目錄，即將某進(jìn)程限制在指定目錄中，保證該進(jìn)程只能對(duì)該目錄及其子目錄的文件有所動(dòng)作，從而保證整個(gè)服務(wù)器的安全，詳細(xì)具體chroot的用法，可參考：http://blog.csdn.net/frozen_fish/article/details/2244870
3. 任意文件下載漏洞也有可能是web所采用的中間件的版本低而導(dǎo)致問題的產(chǎn)生，例如ibm的websphere的任意文件下載漏洞，需更新其中間件的版本可修復(fù)。
4. 要下載的文件地址保存至數(shù)據(jù)庫(kù)中。
5. 文件路徑保存至數(shù)據(jù)庫(kù)，讓用戶提交文件對(duì)應(yīng)ID下載文件。
6. 用戶下載文件之前需要進(jìn)行權(quán)限判斷。
7. 文件放在web無法直接訪問的目錄下。
8. 不允許提供目錄遍歷服務(wù)。
9. 公開文件可放置在web應(yīng)用程序下載目錄中通過鏈接進(jìn)行下載。

1.3、文件包含

漏洞描述：

• 文件包含是指程序代碼在處理包含文件的時(shí)候沒有嚴(yán)格控制。導(dǎo)致用戶可以構(gòu)造參數(shù)包含遠(yuǎn)程代碼在服務(wù)器上執(zhí)行，并得到網(wǎng)站配置或者敏感文件，進(jìn)而獲取到服務(wù)器權(quán)限，造成網(wǎng)站被惡意刪除，用戶和交易數(shù)據(jù)被篡改等一系列惡性后果。主要包括本地文件包含和遠(yuǎn)程文件包含兩種形式，由于開發(fā)人員編寫源碼，開放著將可重復(fù)使用的代碼插入到單個(gè)的文件中，并在需要的時(shí)候?qū)⑺鼈儼谔厥獾墓δ艽a文件中，然后包含文件中的代碼會(huì)被解釋執(zhí)行。由于并沒有針對(duì)代碼中存在文件包含的函數(shù)入口做過濾，導(dǎo)致客戶端可以提交惡意構(gòu)造語句提交，并交由服務(wù)器端解釋執(zhí)行。文件包含攻擊中 WEB 服務(wù)器源碼里可能存在 inlcude()此類文件包含操作函數(shù)，可以通過客戶端構(gòu)造提交文件路徑，是該漏洞攻擊成功的最主要原因。

檢測(cè)條件：

1. 測(cè)試目標(biāo)采用 include 等文件包含函數(shù)通過動(dòng)態(tài)變量的方式引入需要包含的文件。
2. 用戶能夠動(dòng)態(tài)控制該變量。

檢測(cè)方法：

1. 常見的文件包含漏洞，出現(xiàn)在以 PHP 語言開發(fā)的網(wǎng)站中，例如以下代碼采用了指定用戶的名稱，并將該名稱包含在要呈現(xiàn)的 PHP 頁面中，如下：

<?php
include($_GET['name']);
?>

2. 通過提供給 name 一個(gè)惡意數(shù)值，導(dǎo)致程序包含來自外部站點(diǎn)的文件，從而可以完全控制動(dòng)態(tài)包含指令。比如提交：http://test.com/test.php?name=../../../etc/passwd
3. 如果我們?yōu)閯?dòng)態(tài)包含指令指定一個(gè)有效文件，那么該文件的內(nèi)容會(huì)被傳遞給 PHP 解析器,可直接在遠(yuǎn)程服務(wù)器上執(zhí)行任意 PHP 文件。如果我們能夠指定一條路徑來指向被自己控制的遠(yuǎn)程站點(diǎn)，那么動(dòng)態(tài) include 指令就會(huì)執(zhí)行提供的任意惡意代碼，也就是所謂的“遠(yuǎn)程文件包含”。
4. 構(gòu)造類型復(fù)雜，還需自行研究，進(jìn)行文件包含的利用。

漏洞等級(jí)：
【*高?！?/code>：讀取系統(tǒng)的敏感信息或者包含惡意文件控制服務(wù)器。

修復(fù)方案：

1. PHP：配置 php.ini 關(guān)閉遠(yuǎn)程文件包含功能(allow_url_include = Off)
2. 嚴(yán)格檢查變量是否已經(jīng)初始化。
3. 建議假定所有輸入都是可疑的，嘗試對(duì)所有輸入提交可能可能包含的文件地址，包括服務(wù)器本地文件及遠(yuǎn)程文件，進(jìn)行嚴(yán)格的檢查，參數(shù)中不允許出現(xiàn)../之類的目錄跳轉(zhuǎn)符。
4. 嚴(yán)格檢查 include 類的文件包含函數(shù)中的參數(shù)是否外界可控。
5. 不要僅僅在客戶端做數(shù)據(jù)的驗(yàn)證與過濾，關(guān)鍵的過濾步驟在服務(wù)端進(jìn)行。
6. 在發(fā)布應(yīng)用程序之前測(cè)試所有已知的威脅。

二、接口安全類

2.1、短信炸彈

漏洞描述：

• 短信轟炸攻擊時(shí)常見的一種攻擊，攻擊者通過網(wǎng)站頁面中所提供的發(fā)送短信驗(yàn)證碼的功能處，通過對(duì)其發(fā)送數(shù)據(jù)包的獲取后，進(jìn)行重放，如果服務(wù)器短信平臺(tái)未做校驗(yàn)的情況時(shí)，系統(tǒng)會(huì)一直發(fā)送短信，這樣就造成了短信轟炸的漏洞。

檢測(cè)條件：

• 測(cè)試目標(biāo)具有短信發(fā)送的功能。

檢測(cè)方法：

1. 手工找到有關(guān)網(wǎng)站注冊(cè)頁面，認(rèn)證頁面，是否具有短信發(fā)送頁面，如果有，則進(jìn)行下一步。
2. 通過利用 burp suite 或者其它抓包截?cái)喙ぞ?/code>，抓取發(fā)送驗(yàn)證碼的數(shù)據(jù)包，并且進(jìn)行重放攻擊，查看手機(jī)是否在短時(shí)間內(nèi)連續(xù)收到 10 條以上短信，如果收到大量短信，則說明存在該漏洞。

風(fēng)險(xiǎn)等級(jí)：

【*中?！?/code>：對(duì)任意手機(jī)號(hào)碼進(jìn)行轟炸。
【低?！?/code>：僅對(duì)當(dāng)前用戶手機(jī)號(hào)碼進(jìn)行轟炸

修復(fù)方案：

1. 合理配置后臺(tái)短信服務(wù)器的功能，對(duì)于同一手機(jī)號(hào)碼，發(fā)送次數(shù)不超過 3-5次，并且可對(duì)發(fā)送的時(shí)間間隔做限制。
2. 頁面前臺(tái)代碼編寫時(shí)，加入禁止針對(duì)同一手機(jī)號(hào)進(jìn)行的次數(shù)大于 N 次的發(fā)送，或者在頁面中加入驗(yàn)證碼功能，并且做時(shí)間間隔發(fā)送限制。

2.2、郵件炸彈

漏洞描述：

• 應(yīng)用系統(tǒng)未限制郵件的發(fā)送次數(shù)和頻率，造成短時(shí)間內(nèi)大量郵件發(fā)送至接收者郵箱，造成大量垃圾郵件。

檢測(cè)條件：

• 測(cè)試目標(biāo)具有郵件發(fā)送的功能。

檢測(cè)方法：

1. 手工找到有關(guān)網(wǎng)站注冊(cè)頁面，認(rèn)證頁面，是否具有郵件發(fā)送頁面，如果有，則進(jìn)行下一步。
2. 通過利用 burp suite 或者其它抓包截?cái)喙ぞ?/code>，抓取發(fā)送郵件的數(shù)據(jù)包，并且進(jìn)行重放攻擊，查看郵箱是否在短時(shí)間內(nèi)連續(xù)收到 10 條以上郵件，如果收到大量郵件，則說明存在該漏洞。

風(fēng)險(xiǎn)等級(jí)：

【*中?！?/code>：對(duì)任意郵箱進(jìn)行轟炸。
【低危】：僅對(duì)當(dāng)前用戶郵箱進(jìn)行轟炸。

修復(fù)方案：

1. 合理配置后臺(tái)郵件服務(wù)器的功能，對(duì)于同一郵箱，發(fā)送次數(shù)不超過 3-5 次，并且可對(duì)發(fā)送的時(shí)間間隔做限制。
2. 頁面前臺(tái)代碼編寫時(shí)，加入禁止針對(duì)同一郵箱賬號(hào)進(jìn)行的次數(shù)大于 N 次的發(fā)送，或者在頁面中加入驗(yàn)證碼功能，并且做時(shí)間間隔發(fā)送限制。

2.3、短信內(nèi)容可控

漏洞描述：

• 應(yīng)用系統(tǒng)未限制短信的發(fā)送內(nèi)容，造成短信內(nèi)容客戶端可控。

檢測(cè)條件：

• 測(cè)試目標(biāo)具有短信內(nèi)容編輯的功能或短信內(nèi)容由客戶端發(fā)出。

檢測(cè)方法：

• 在客戶端編輯短信內(nèi)容，看是否過濾特殊字符或內(nèi)容。

風(fēng)險(xiǎn)等級(jí)：
【*高危*】：短信內(nèi)容可控，可對(duì)任意手機(jī)號(hào)碼發(fā)送。
【*中?！?/code>：短信內(nèi)容可控，僅對(duì)當(dāng)前用戶手機(jī)號(hào)碼發(fā)送。

修復(fù)方案：

1. 建議在不影響業(yè)務(wù)的前提下，禁止客戶端編輯短信內(nèi)容。

2.4、郵件內(nèi)容可控

漏洞描述：

• 應(yīng)用系統(tǒng)未限制郵件的發(fā)送內(nèi)容，造成郵件內(nèi)容客戶端可控。
  檢測(cè)條件：
• 測(cè)試目標(biāo)具有郵件內(nèi)容編輯的功能或郵件內(nèi)容由客戶端發(fā)出。

檢測(cè)方法：

• 在客戶端編輯郵件內(nèi)容，看是否過濾特殊字符或內(nèi)容。

風(fēng)險(xiǎn)等級(jí)：
【*高危*】：郵件內(nèi)容可控，可對(duì)任意郵箱發(fā)送。
【*中危】：郵件內(nèi)容可控，僅對(duì)當(dāng)前用戶郵箱發(fā)送。

修復(fù)方案：

1. 建議在不影響業(yè)務(wù)的前提下，禁止客戶端編輯郵件內(nèi)容。

三、邏輯流程類

3.1、越權(quán)

漏洞描述：

• 越權(quán)訪問：這類漏洞是指應(yīng)用在檢查授權(quán)（Authorization）時(shí)存在紕漏，使得攻擊者在獲得低權(quán)限用戶帳后后，可以利用一些方式繞過權(quán)限檢查，訪問或者操作到原本無權(quán)訪問的高權(quán)限功能。在實(shí)際的代碼安全審查中，這類漏洞往往很難通過工具進(jìn)行自動(dòng)化檢測(cè)，因此在實(shí)際應(yīng)用中危害很大。其與未授權(quán)訪問有一定差別。

檢測(cè)條件：

1. 測(cè)試目標(biāo)存在不同級(jí)別的權(quán)限（角色）
2. 可通過用戶名登錄網(wǎng)站內(nèi)進(jìn)行功能的操作。
3. 測(cè)試目標(biāo)正常運(yùn)行。

檢測(cè)方法：

1. 以超管 admin（高權(quán)限用戶） 身份登錄系統(tǒng)
2. 找 到 一 個(gè) 只 有 超 管 （ 高 權(quán) 限 ） 才 有 的 功 能 的 鏈 接 ， 比如:“http://localhost/mywebappname/userManage/userList.do” , 顯示出所有的 user，并復(fù)制此鏈接。
3. 以普通用戶登陸進(jìn)系統(tǒng),在地址欄輸入: userManage/userList.do，如果可以查看到其所有的 user，則就造成了，普通用戶的越權(quán)訪問。
   • 檢測(cè)說明：權(quán)限管理測(cè)試更多的是進(jìn)行人工分析，自動(dòng)化工具無法了解頁面的具體應(yīng)用場(chǎng)景以及邏輯判斷過程。因此這里的測(cè)試需要首先測(cè)試人員理解測(cè)試業(yè)務(wù)系統(tǒng)的邏輯處理流程，并在此基礎(chǔ)上進(jìn)行如下測(cè)試。這里有幾個(gè)測(cè)試的參考依據(jù)：
     • 頁面是否進(jìn)行權(quán)限判斷；
     • 頁面提交的資源標(biāo)志是否與已登陸的用戶身份進(jìn)行匹配比對(duì)；
     • 用戶登陸后，服務(wù)器端不應(yīng)再以客戶端提交的用戶身份信息為依據(jù)，而應(yīng)以會(huì)話中保存的已登陸的用戶身份信息為準(zhǔn)；
     • 必須在服務(wù)器端對(duì)每個(gè)請(qǐng)求 URL 進(jìn)行鑒權(quán)，而不能僅僅通過客戶端的菜單屏蔽或者按鈕 Disable 來限制。

風(fēng)險(xiǎn)等級(jí)：

【*高危*】：任意水平或垂直越權(quán)

修復(fù)方案：

• 對(duì)用戶操作進(jìn)行權(quán)限校驗(yàn)，防止通過修改參數(shù)進(jìn)入未授權(quán)頁面及進(jìn)行非法操作，建議在服務(wù)端對(duì)請(qǐng)求的數(shù)據(jù)和當(dāng)前用戶身份做校驗(yàn)檢查。

3.2、未授權(quán)訪問

漏洞描述：

• 未授權(quán)訪問漏洞:是在攻擊者沒有獲取到登錄權(quán)限或未授權(quán)的情況下，或者不需要輸入密碼，即可通過直接輸入網(wǎng)站控制臺(tái)主頁面地址，或者不允許查看的鏈接便可進(jìn)行訪問，同時(shí)進(jìn)行操作。

檢測(cè)條件：

1. 測(cè)試目標(biāo)具有登錄頁面，或者具有不允許訪問的目錄或功能。
2. 不用登錄，可通過鏈接直接訪問用戶頁面功能。

檢測(cè)方法：

1. 通過對(duì)登錄后的頁面進(jìn)行抓包，將抓取到的功能鏈接，在其他瀏覽器進(jìn)行打開。
2. 也可以通過 web 掃描工具進(jìn)行掃描，爬蟲得到相關(guān)地址鏈接，進(jìn)行直接訪問，如果未進(jìn)行跳轉(zhuǎn)到登錄頁面，則可判斷為存在未授權(quán)訪問漏洞。

風(fēng)險(xiǎn)等級(jí)：

【*高危*】：認(rèn)證模式可繞過，不登錄即可通過 URL 或其他方式訪問登陸后頁面。

修復(fù)方案：

• 在系統(tǒng)中，加入用戶身份認(rèn)證機(jī)制或者 tonken 驗(yàn)證，防止可被直接通過連接就可訪問到用戶的功能進(jìn)行操作，簡(jiǎn)而言之，一定對(duì)系統(tǒng)重要功能點(diǎn)增加權(quán)限控制，對(duì)用戶操作進(jìn)行合法性驗(yàn)證。

3.3、CSRF 漏洞

漏洞描述：

• 跨站請(qǐng)求偽造攻擊：Cross-Site Request Forgery（CSRF），攻擊者在用戶瀏覽網(wǎng)頁時(shí)，利用頁面元素（例如 img 的 src），強(qiáng)迫受害者的瀏覽器向 Web 應(yīng)用服務(wù)器發(fā)送一個(gè)改變用戶信息的 HTTP 請(qǐng)求。CSRF 攻擊可以從站外和站內(nèi)發(fā)起。從站內(nèi)發(fā)起 CSRF 攻擊，需要利用網(wǎng)站本身的業(yè)務(wù)，比如“自定義頭像”功能，惡意用戶指定自己的頭像 URL 是一個(gè)修改用戶信息的鏈接，當(dāng)其他已登錄用戶瀏覽惡意用戶頭像時(shí)，會(huì)自動(dòng)向這個(gè)鏈接發(fā)送修改信息請(qǐng)求。從站外發(fā)送請(qǐng)求，則需要惡意用戶在自己的服務(wù)器上，放一個(gè)自動(dòng)提交修改個(gè)人信息的 htm 頁面，并把頁面地址發(fā)給受害者用戶，受害者用戶打開時(shí)，會(huì)發(fā)起一個(gè)請(qǐng)求。威脅描述：攻擊者使用 CSRF 攻擊能夠強(qiáng)迫用戶向服務(wù)器發(fā)送請(qǐng)求，導(dǎo)致用戶信息被迫修改，甚至可引發(fā)蠕蟲攻擊。如果惡意用戶能夠知道網(wǎng)站管理后臺(tái)某項(xiàng)功能的 URL，就可以直接攻擊管理員，強(qiáng)迫管理員執(zhí)行惡意用戶定義的操作。

檢測(cè)條件：

1. 測(cè)試目標(biāo)正常運(yùn)行。
2. 存在數(shù)據(jù)提交的所有功能點(diǎn)。

檢測(cè)方法：

1. 檢查網(wǎng)站是否有使用 token 或 referer 參數(shù)，若有上述參數(shù)，刪除參數(shù)值查看返回是否有報(bào)錯(cuò)。
2. 修改 referer 值，保留原 host 關(guān)鍵詞，嘗試?yán)@過 referer 檢測(cè)。
3. 偽造 referer。
   以下來舉例說明其中一種檢測(cè)以及攻擊方案：
   1）使用 BurpSuite 對(duì)關(guān)鍵操作進(jìn)行抓包，右鍵選擇“Engagement tools >Generate CSRF PoC”進(jìn)行 CSRF 攻擊腳本的構(gòu)造。
   
   2）生成腳本后選擇“Test in browser”進(jìn)行 CSRF 驗(yàn)證。
   

風(fēng)險(xiǎn)等級(jí)：

【*高危*】：核心系統(tǒng)關(guān)鍵操作（賬戶操作，審批確認(rèn)…）。
【*中?！?/code>：普通系統(tǒng)關(guān)鍵操作（賬戶操作，審批確認(rèn)…）。

修復(fù)方案：

1. 通過 referer 判斷頁面來源進(jìn)行 CSRF 防護(hù)，該方式無法防止站內(nèi) CSRF攻擊及 referer 字段偽造。
2. 重要功能點(diǎn)使用動(dòng)態(tài)驗(yàn)證碼進(jìn)行 CSRF 防護(hù)。
3. 通過 token 方式進(jìn)行 CSRF 防護(hù)。
4. 為每個(gè) session 創(chuàng)建唯一的隨機(jī)字符串，并在受理請(qǐng)求時(shí)驗(yàn)證。

四、數(shù)據(jù)驗(yàn)證類

4.1、SQL 注入

漏洞描述：

• SQL 注入：就是通過把 SQL 命令插入到 Web 表單提交或輸入域名或頁面請(qǐng)求的查詢字符串，最終達(dá)到欺騙服務(wù)器執(zhí)行惡意的 SQL 命令。具體來說，它是利用現(xiàn)有應(yīng)用程序，將（惡意）SQL 命令注入到后臺(tái)數(shù)據(jù)庫(kù)引擎執(zhí)行的能力，它可以通過在 Web 表單中輸入（惡意）SQL 語句得到一個(gè)存在安全漏洞的網(wǎng)站上的數(shù)據(jù)庫(kù)，而不是按照設(shè)計(jì)者意圖去執(zhí)行 SQL 語句。 造成 SQL 注入漏洞原因有兩個(gè)：一個(gè)是沒有對(duì)輸入的數(shù)據(jù)進(jìn)行過濾（過濾輸入），還有一個(gè)是沒有對(duì)發(fā)送到數(shù)據(jù)庫(kù)的數(shù)據(jù)進(jìn)行轉(zhuǎn)義（轉(zhuǎn)義輸出）。

檢測(cè)條件：

• 測(cè)試目標(biāo)具有交互功能模塊，涉及到參數(shù)查詢、提交等。

檢測(cè)方法：

1. 通過web漏洞掃描工具進(jìn)行對(duì)網(wǎng)站爬蟲后得到的所有鏈接進(jìn)行檢測(cè)，或者手工判斷是否存在注入點(diǎn)，一旦確認(rèn)存在漏洞，可利用自動(dòng)化工具sqlmap去嘗試注入。
   幾種常見的判斷方法：

   • 數(shù)字型
     http://host/test.php?id=100 and 1=1 返回成功
     http://host/test.php?id=100 and 1=2 返回失敗

   • 字符型
     http://host/test.php?name=rainman ’ and ‘1’=‘1 返回成功
     http://host/test.php?name=rainman ’ and ‘1’=‘2 返回失敗

   • 搜索型
     搜索型注入：簡(jiǎn)單的判斷搜索型注入漏洞是否存在的辦法是：
     1）先搜索（’），如果出錯(cuò)，說明90%存在這個(gè)漏洞。
     2）然后搜索（%），如果正常返回，說明95%有洞了。
     3）然后再搜索一個(gè)關(guān)鍵字，比如（2006）吧，正常返回所有2006相關(guān)的信息。
     4）再搜索（2006%'and 1=1 and '%'='）和（2006%'and 1=2 and '%'='）。

   • 繞過驗(yàn)證（常見的為管理登陸）也稱萬能密碼

     1. 用戶名輸入： ‘ or 1=1 or ‘ 密碼：任意
     2. Admin’ - -（或‘ or 1=1 or ‘ - -）(admin or 1=1 --) (MS SQL)(直接輸入用戶名，不進(jìn)行密碼驗(yàn)證)
     3. 用戶名輸入：admin 密碼輸入：’ or ‘1’=’1 也可以
     4. 用戶名輸入：admin' or 'a'='a 密碼輸入：任意
     5. 用戶名輸入：‘ or 1=1 - -
     6. 用戶名輸入：admin‘ or 1=1 - - 密碼輸入：任意
     7. 用戶名輸入：1'or'1'='1'or'1'='1 密碼輸入：任意
     8. 不同的SQL服務(wù)器連結(jié)字符串的語法不同，比如MS SQL Server使用符號(hào)+來連結(jié)字符串，而Oracle使用符號(hào)||來連結(jié)：
        http://host/test.jsp?ProdName=Book’ 返回錯(cuò)誤
        http://host/test.jsp?ProdName=B’+’ook 返回正常
        http://host/test.jsp?ProdName=B’||’ook 返回正常說明有 SQL 注入

   • 排序型：orderby參數(shù)或者被排序的參數(shù)
     orderby=desc,1/1 返回正常
     orderby=desc,1/0 返回錯(cuò)誤

2. 如果應(yīng)用程序已經(jīng)過濾了’和+等特殊字符，我們?nèi)匀豢梢栽谳斎霑r(shí)過把字符轉(zhuǎn)換成URL編碼（即字符ASCII碼的16進(jìn)制）來繞過檢查。

風(fēng)險(xiǎn)等級(jí)：

【*高危*】：存在 SQL 注入，無論能否爆出數(shù)據(jù)。

修復(fù)方案：

1. SQL改用預(yù)編譯查詢語句。
2. 過濾用戶輸入的參數(shù)中的特殊符號(hào)，如’”<>~！@#￥%&()_-=+等、過濾常見的sql函數(shù)，如select、from、where、substr、ascii、if、case、when等。
3. Web應(yīng)用中用于連接數(shù)據(jù)庫(kù)的用戶與數(shù)據(jù)庫(kù)的系統(tǒng)管理員用戶的權(quán)限有嚴(yán)格的區(qū)分（如不能執(zhí)行drop等），并設(shè)置Web應(yīng)用中用于連接數(shù)據(jù)庫(kù)的用戶不允許操作其他數(shù)據(jù)庫(kù)。
4. 設(shè)置Web應(yīng)用中用于連接數(shù)據(jù)庫(kù)的用戶對(duì)Web目錄不允許有寫權(quán)限。

4.2、XSS

漏洞描述：

• 跨站腳本攻擊的英文全稱是 Cross Site Script，為了和樣式表區(qū)分，縮寫為 XSS。發(fā)生的原因是網(wǎng)站將用戶輸入的內(nèi)容輸出到頁面上，在這個(gè)過程中可能有惡意代碼被瀏覽器執(zhí)行?？缯灸_本攻擊,它指的是惡意攻擊者往 Web 頁面里插入惡意 html 代碼，當(dāng)用戶瀏覽該頁之時(shí)，嵌入其中 Web 里面的 html 代碼會(huì)被執(zhí)行，從而達(dá)到惡意用戶的特殊目的。已知的跨站腳本攻擊漏洞有三種：1）存儲(chǔ)式；2）反射式；3）基于 DOM。
  1. 存儲(chǔ)型跨站腳本攻擊涉及的功能點(diǎn)：用戶輸入的文本信息保存到數(shù)據(jù)庫(kù)中，并能夠在頁面展示的功能點(diǎn)，例如用戶留言、發(fā)送站內(nèi)消息、個(gè)人信息修改等功能點(diǎn)。
  2. 反射型跨站腳本攻擊涉及的功能點(diǎn)：URL 參數(shù)需要在頁面顯示的功能點(diǎn)都可能存在反射型跨站腳本攻擊，例如站內(nèi)搜索、查詢功能點(diǎn)。
  3. 基于 DOM 跨站腳本攻擊涉及的功能點(diǎn)：涉及 DOM 對(duì)象的頁面程序，包括
     （不限這些）：
     document.URL
     document.URLUnencoded
     document.location
     document.referrer
     window.location

檢測(cè)條件：

• 測(cè)試目標(biāo)存在參數(shù)輸入，或者以 POST 方式提交參數(shù)，顯示為表單方式，假設(shè)為 name=value。
• 在某種情況下，用戶輸入被重新顯示在網(wǎng)頁上，包括名字、帳號(hào)、檢索結(jié)果等等（說明目標(biāo)網(wǎng)站服務(wù)器并沒有對(duì)用戶提交數(shù)據(jù)檢測(cè)）

檢測(cè)方法：

1. GET 方式跨站腳本：
   1）在 輸 入 的 參 數(shù) 后 逐 條 添 加 以 下 語 句 ， 以 第 一 條 為 例 ， 輸 入
   http://www.exmaple.com/page.xxx?name=<script>alert(123456)</script> 只要其中一條彈出顯示 123456 的告警框，就說明存在跨站漏洞，記錄漏洞，停止測(cè)試。

   2）如果沒有彈出顯示 123456 的告警框，則在返回的頁面上單擊鼠標(biāo)右鍵，選擇“查看源文件”。

   3）查 找 網(wǎng) 頁 源 文 件 中 是 否 包 含 完 整 的 字 符 串<script>alert(123456)</script>，則不管有沒有彈出顯示 123456 的告警框，都表明存在跨站腳本漏洞。

   4）由于有些 HTML 元素（比如<textarea>或”）會(huì)影響腳本的執(zhí)行，所以不一定能夠正確彈出 123456 告警框，需要根據(jù)返回網(wǎng)頁源文件的內(nèi)容，構(gòu)造 value的值，比如：
   

2. Post 方式跨站腳本：
   1） 在POST 表單中逐條輸入以下語句，只要其中一條彈出顯示 123456 的對(duì)話框，就說明存在跨站漏洞，記錄漏洞，停止測(cè)試。
   2）<script>alert(123456)</script>
   3）[img]javascript:alert(123456);[/img]
   4）如果沒有彈出顯示 123456 的告警框，則在返回的頁面上單擊鼠標(biāo)右鍵，選擇“查看源文件”
   5）查 找 網(wǎng) 頁 源 文 件 中 是 否 包 含 完 整 的 字 符 串<script>alert(123456)</script>，則不管有沒有彈出顯示 123456 的告警框，都表明存在跨站腳本漏洞。
   6）由于有些 HTML 元素（比如或”）會(huì)影響腳本的執(zhí)行，所以不一定能夠正確彈出 123456 告警框，需要根據(jù)返回網(wǎng)頁源文件的內(nèi)容，構(gòu)造 value的值，比如
   

風(fēng)險(xiǎn)等級(jí)：

【*高危*】：應(yīng)用中存在存儲(chǔ)型跨站。
【*中?！?/code>：應(yīng)用中存在反射型跨站。

修復(fù)方案：

• 驗(yàn)證所有輸入數(shù)據(jù)，有效檢測(cè)攻擊；對(duì)所有輸出數(shù)據(jù)進(jìn)行適當(dāng)?shù)木幋a，以防止任何已成功注入的腳本在瀏覽器端運(yùn)行。

  1.輸入驗(yàn)證：某個(gè)數(shù)據(jù)被接受為可被顯示或存儲(chǔ)之前，使用標(biāo)準(zhǔn)輸入驗(yàn)證機(jī)制，驗(yàn)證所有輸入數(shù)據(jù)的長(zhǎng)度、類型、語法以及業(yè)務(wù)規(guī)則。

  2.輸出編碼：數(shù)據(jù)輸出前，確保用戶提交的數(shù)據(jù)已被正確進(jìn)行 entity 編碼，建議對(duì)所有字符進(jìn)行編碼而不僅局限于某個(gè)子集。

明確指定輸出的編碼方式：不要允許攻擊者為你的用戶選擇編碼方式(如 ISO8859-1 或 UTF 8)。

4.3、URL 重定向

漏洞描述：

• 服務(wù)端未對(duì)傳入的跳轉(zhuǎn) url 變量進(jìn)行檢查和控制，可能導(dǎo)致可惡意構(gòu)造任意一個(gè)惡意地址，誘導(dǎo)用戶跳轉(zhuǎn)到惡意網(wǎng)站。由于是從可信的站點(diǎn)跳轉(zhuǎn)出去的，用戶會(huì)比較信任，所以跳轉(zhuǎn)漏洞一般用于釣魚攻擊，通過轉(zhuǎn)到惡意網(wǎng)站欺騙用戶輸入用戶名和密碼盜取用戶信息，或欺騙用戶進(jìn)行金錢交易；也可能引發(fā)的 XSS 漏洞（主要是跳轉(zhuǎn)常常使用 302 跳轉(zhuǎn)，即設(shè)置 HTTP 響應(yīng)頭，Locatioin: url，如果 url 包含了 CRLF，則可能隔斷了 http 響應(yīng)頭，使得后面部分落到了 http body，從而導(dǎo)致 xss 漏洞）。另外在 struts2 中存在重定向的漏洞，是因?yàn)?struts2 由于縮寫的導(dǎo)航和重定向前綴“action:”、 “redirect:”、 “redirectAction:”等參數(shù)前綴的內(nèi)容沒有被正確過濾導(dǎo)致的開放式重定向漏洞。

檢測(cè)條件：

• 測(cè)試目標(biāo)具有 URL 跳轉(zhuǎn)鏈接的地方。

檢測(cè)方法：

1. 首先找到網(wǎng)站相關(guān) url 中存在跳轉(zhuǎn)鏈接的參數(shù)（如登陸頁面）。
2. 在檢測(cè)的同時(shí)，可以修改參數(shù)中的合法 URL 為非法 URL，然后查看是否能正常跳轉(zhuǎn)或者通過抓包工具獲取其 HTTP 響應(yīng)頭中 Host:的值是否包含了構(gòu)造的 URL。
3. 如果是 struts2 重定向漏洞，則可通過 web 掃描工具掃描發(fā)現(xiàn)，或者手工 驗(yàn) 證 ， 直 接 在 URL 后 添 加 ?redirect:+ 指 定 釣 魚 鏈 接 ， 例 如 ：10.1.82.53:9098/admin/login.action?redirect:http://diaoyu.com 進(jìn)行驗(yàn)證。

風(fēng)險(xiǎn)等級(jí)：

【*中?！?/code>：URL 跳轉(zhuǎn)參數(shù)可控，且未對(duì)參數(shù)做白名單限制導(dǎo)致任意地址跳轉(zhuǎn)可被利用釣魚。

修復(fù)方案：

• 對(duì)傳入的 URL 做有效性的認(rèn)證，保證該 URL 來自于信任域。限制的方式可參考以下兩種：
  1. 限制 Referer（Referer 是 HTTP header 中的字段，當(dāng)瀏覽器向 web 服務(wù)器發(fā)送請(qǐng)求時(shí)，一般會(huì)帶上 Referer，告訴服務(wù)器是從哪個(gè)頁面鏈接過來的），通過限制 Referer 保證將要跳轉(zhuǎn) URL 的有效性，避免攻擊者生成自己的惡意跳轉(zhuǎn)鏈接；
  2. 加入有效性驗(yàn)證 Token，保證所有生成的鏈接都來自于可信域，通過在生成的鏈接里加入用戶不可控的 Token 對(duì)生成的鏈接進(jìn)行校驗(yàn)。

下一期預(yù)告更新：《WEB應(yīng)用安全測(cè)試指南–藍(lán)隊(duì)安全測(cè)試3》主要包含：組件安全類+Jboss 組件漏洞等。

（創(chuàng)作不易，支持打賞，感謝支持）