Web安全測試指南--認證

認證：

5.1.1、敏感數據傳輸：

編號	Web_Authen_01_01
用例名稱	敏感數據傳輸保密性測試
用例描述	測試敏感數據是否經過加密通道進行傳輸以防止信息泄漏。
嚴重級別	高
前置條件	一、  已明肯定義出敏感數據範圍（好比口令、短信驗證碼和身份證號等）。 二、  目標web應用可訪問，業務正常運行。 三、  已安裝http攔截代理（burp、fiddler或webscarab都可）。
執行步驟	一、  開啓burp，設置對http請求進行攔截，並在瀏覽器中配置代理。 二、  訪問web頁面並提交敏感數據（好比帳戶登陸和修改密碼等）。 三、  在burp攔截到的http請求中，檢查敏感數據是否使用https協議傳輸。
預期結果	敏感數據是否使用https協議傳輸
測試結果
備註	常見的敏感數據有用戶口令、用戶我的信息和session ID等等，但也有一些是和業務強相關的，須要結合業務進行斷定。

 

編號	Web_Auth_01_02
用例名稱	敏感數據HTTP傳輸方法測試
用例描述	測試敏感數據是否經過POST方法進行提交以防止信息泄漏。
嚴重級別	中
前置條件	一、  已明肯定義出敏感數據範圍（好比口令、短信驗證碼和身份證號等）。 二、  目標web應用可訪問，業務正常運行。 三、  已安裝http攔截代理（burp、fiddler或webscarab都可）。
執行步驟	一、  開啓burp，設置對http請求進行攔截，並在瀏覽器中配置代理。 二、  訪問web頁面並提交敏感數據（好比登陸和修改密碼等）。 三、  在burp攔截到的http請求中，檢查敏感數據是否使用POST進行提交。
預期結果	敏感數據使用POST方法進行提交。
測試結果
備註	使用GET提交請求數據可能會被記錄在web server日誌或緩存在瀏覽器。

 

5.1.2、鎖定策略：

編號	Web_ Authen_02
用例名稱	帳戶鎖定策略測試
用例描述	鎖定策略用來緩解口令等敏感數據被惡意攻擊者嘗試暴力破解。
嚴重級別	高
前置條件	一、  存在登陸頁面。 二、  目標web應用可訪問，業務正常運行。 三、  不存在圖形驗證碼等其它防暴力破解措施。
執行步驟	一、  打開登陸頁面。 二、  使用正確的帳戶名和錯誤的口令嘗試登陸N次。 三、  使用正確的帳戶和口令登陸。 四、  若是系統返回相似「帳戶被鎖定」這樣的提示則繼續往下測試，不然測試結束。 五、  等待M-1分鐘後，從新使用正確的帳戶和口令登陸。 六、  若是系統返回相似「帳戶被鎖定」這樣的提示則繼續往下測試，不然測試結束。 七、  等待M-1分鐘後，從新使用正確的帳戶和口令登陸。 八、  檢查返回結果。
預期結果	一、  執行步驟4和6中，系統返回相似「帳戶被鎖定」這樣的提示。 二、  執行步驟8中，成功登陸帳戶，帳戶被解鎖。
測試結果
備註	一、  N通常建議取值小於等於10，而M通常建議取值大於等於10。 二、  鎖定策略不只僅是針對帳戶口令的，而是針對全部可經過暴力破解得到的敏感數據，好比：短信驗證碼、找回密碼的問答等。 三、  鎖定策略不只僅針對於web接口，一樣適用於其它協議的接口，好比：FTP、SNMP等。

 

5.1.3、認證繞過：

編號	Web_ Authen_03
用例名稱	認證繞過測試
用例描述	測試訪問受限數據時是否須要認證以及是否能夠繞過認證。
嚴重級別	高
前置條件	一、  已明肯定義出受限數據範圍（好比：web頁面和靜態配置文件等）。 二、  目標web應用可訪問，業務正常運行。 三、  擁有登陸訪問web服務器後臺的權限。
執行步驟	一、  登陸web服務器後臺，進入web應用根目錄（好比www或ROOT）。 二、  根據web目錄結構和受限訪問文件的路徑構建 HTTP URL。好比：路徑爲/ROOT/admin/changePwd.php的文件構建出來的HTTP URL可能爲：http://www.example.com/admin/changePwd.php。 三、  打開瀏覽器，並在瀏覽器中訪問由步驟2構建的URL，觀察返回結果。
預期結果	服務器返回要求登陸認證或拒絕訪問。
測試結果
備註	本測試用例偏向於灰盒測試，即擁有登陸後臺的權限，實際也能夠用工具進行掃描，但效果沒那麼明顯，具體參考《常見安全工具使用指南》。

5.1.4、複雜度策略：

編號	Web_ Authen_04
用例名稱	口令複雜度策略測試
用例描述	測試目標系統是否存在足夠安全的口令複雜度策略。
嚴重級別	高
前置條件	一、  已知明確的口令複雜度策略。 二、  目標web應用可訪問，業務正常運行。 三、  存在能夠設置口令的功能（註冊用戶、找回和修改密碼等）。 四、  擁有常見的弱口令列表（非必須）。
執行步驟	一、  登陸業務系統並打開能夠設置口令的頁面。 二、  輸入任意小於6位長度的字符串（好比abc12）並提交。 三、  輸入長度大於等於6位，分別由數字、大寫普通字符[A-Z]、小寫普通字符[a-z]和特殊字符單獨組成的字符串並提交（好比 123456,abcdef和!@#$%^等）。 四、  分別觀察步驟2和步驟3的結果。
預期結果	一、  步驟2出現相似「口令太短」的提示信息。 二、  步驟3出現相似「不能全爲數字/字母」等提示信息。
測試結果
備註	一、  口令複雜度不只僅適用於口令自己，對於可用來鑑別對象身份的任意憑證都須要設置適合的複雜度，好比：短信驗證碼和設備驗證碼等。 二、  本用例的口令複雜度策略適用於大多數狀況，但其和業務對安全需求的強度有很大的關係，對於安全性高的業務（好比管理系統），可能要求設置更加複雜的口令複雜度，所以，應和業務結合進行測試。 三、  建議口令複雜度策略可配置，可參考的強口令複雜度策略選項以下： l  口令必須包含數字、大寫普通字符[A-Z]、小寫普通字符[a-z]和特殊字符中的3項。 l  口令存在一個明確的有效期限，建議3個月。 l  最近使用過的N個口令不能在新口令中使用，建議N取值8。 l  口令中不能出現連續N個字符（好比：aaa123），建議N取值3。 l  口令不存在於常見弱口令列表中（比：abc123、qwerty等）。 l  口令不可以和用戶名以及用戶名的反向字符串相同。 l  使用默認口令登陸的用戶要求強制或提示修改口令。

5.1.5、問答策略：

編號	Web_ Authen_05
用例名稱	修改口令功能安全性測試
用例描述	測試修改口令功能是否存在缺陷。
嚴重級別	高
前置條件	一、  業務系統存在使用問答策略的功能（好比：註冊或找回密碼）。 二、  目標web應用可訪問，業務正常運行。
執行步驟	一、  登陸業務系統，進入使用問答策略的功能（好比：找回密碼）。 二、  檢查業務系統預先設定的給用戶選擇的問題是否存在如下問題： 2.1、問題的答案和家庭成員或者朋友有關。好比某個家庭成員的名字或者用戶本人的生日等。 2.2、問題的答案容易猜解或經過搜索引擎得到，好比：「我喜歡的顏色/球隊」和「個人第一所學校」等。 三、  檢查問答系統是否實施鎖定策略以防止暴力破解答案（參考用例：「鎖定策略」）。 四、  檢查業務系統是否容許自定義問題和答案，若是是，確認是否認義任意簡單的問題和答案。好比：「1加1等於幾？」
預期結果	一、  業務系統預設問題不存在步驟2所述的問題。 二、  問答系統知足「鎖定策略」要求。 三、  問答系統不能任意自定義問題和答案。
測試結果
備註	本測試用例帶有必定的主觀性，當難以對於系統預設問題進行有效判斷時，能夠嘗試多我的一塊兒判斷得出結論。

5.1.6、短信驗證碼：

編號	Web_ Authen_06
用例名稱	短信驗證碼安全性測試
用例描述	測試短信驗證碼的安全性設計是否存在缺陷。
嚴重級別	高
前置條件	一、  業務系統存在使用短信驗證碼的功能模塊。 二、  目標web應用可訪問，業務正常運行。 三、  已安裝http攔截代理（burp、fiddler或webscarab都可）。
執行步驟	一、  開啓burp，設置對http請求進行攔截，並在瀏覽器中配置代理。 二、  登陸業務系統，進入使用短信驗證碼的功能模塊（好比：找回密碼），並提交獲取短信驗證碼的請求。 三、  將攔截到的http請求轉入burp repeater，並在burp repeater中反覆提交該請求，檢查業務系統是否實施鎖定策略來防止惡意濫發短信（參考用例：「鎖定策略」）。 四、  嘗試屢次提交獲取短信驗證碼，檢查短信驗證碼是否存在複雜度策略（參考備註1）。 五、  在獲取到短信驗證碼後，等待30分鐘，而後提交使用該短信驗證碼，檢查是否返回相似「短信驗證碼過時」的信息。 六、  使用burp將提交使用短信驗證碼的請求攔截並轉入burp repeater，在burp repeater中反覆重放該請求，檢查服務器是否會返回「短信驗證碼失效」的信息或者相關錯誤碼。 七、  檢查短信網關接口是否對外開放，若是是，檢查直接在瀏覽器上輸入短信網關地址是否能夠向任意號碼發短信。好比，網關地址可能以下： http://www.example.com/sms/smsNetgateServlet?phone=xxx&content=xxx
預期結果	一、  步驟3中，業務系統返回相似「使用過於頻繁」的信息。 二、  步驟4中，短信驗證碼知足備註1的複雜度。 三、  步驟5中，服務器返回相似「短信驗證碼過時」的信息。 四、  步驟6中，服務器返回「短信驗證碼失效」的信息或者相關錯誤碼。 五、  步驟7中，服務器網關地址不對外開放，若是開放，只有登陸用戶才能夠訪問。
測試結果
備註	1、出於用戶體驗考慮，短信驗證碼的複雜度策略通常是： l  1、4-6位長度。 l  2、由純數字或者由數字加普通字符組成。 2、短信網關接口可經過研發接口人獲取。

 

5.1.7、修改密碼：

編號	Web_ Authen_07
用例名稱	修改密碼功能安全性測試
用例描述	測試修改密碼功能是否存在安全缺陷。
嚴重級別	高
前置條件	一、  業務系統存在修改密碼功能。 二、  目標web應用可訪問，業務正常運行。 三、  已安裝http攔截代理（burp、fiddler或webscarab都可）。
執行步驟	一、  開啓burp，設置對http請求進行攔截，並在瀏覽器中配置代理。 二、  登陸web應用，並進入到修改密碼功能頁面。 三、  檢查是否須要舊密碼才能修改新密碼。 四、  輸入舊密碼和新密碼並提交。 五、  在burp攔截到的http請求中，檢查舊密碼和新密碼是否在同一個請求中傳輸。 六、  檢查密碼是否經過加密進行傳輸（參考用例：「敏感數據傳輸」）。 七、  檢查是否存在密碼複雜度策略（參考用例：「口令複雜度策略」）。 八、  反覆提交錯誤的舊密碼，檢查是否對舊密碼提交實施鎖定策略（參考用例：「鎖定策略」）。 九、  檢查修改密碼的功能頁面是否須要認證纔可以訪問（參考用例：「認證繞過」）。
預期結果	新舊密碼在一個http請求中提交，而且知足「敏感數據傳輸」、「口令複雜度策略」、「鎖定策略」和「認證繞過」的要求。
測試結果
備註

5.1.8、找回密碼：

編號	Web_ Authen_08
用例名稱	找回密碼測試
用例描述	測試找回密碼功能是否存在安全缺陷。
嚴重級別	高
前置條件	一、  業務系統存在找回密碼功能。 二、  目標web應用可訪問，業務正常運行。 三、  已安裝http攔截代理（burp、fiddler或webscarab都可）。
執行步驟	一、  開啓burp，設置對http請求進行攔截，並在瀏覽器中配置代理。 二、  登陸web應用，並進入到找回密碼頁面。 三、  若是系統要求對用戶預設的問題給出答案，則檢查是否知足問答系統的安全要求（參考用例：「問答策略」）。 四、  若是系統使用短信驗證碼進行驗證，則檢查是否知足短信驗證碼的安全要求（參考用例：「短信驗證碼」）。 五、  若是在完成步驟3或者步驟4後，檢查系統是否會將原始密碼（即用戶忘記的密碼）返回給用戶。 六、  若是系統發一個重置密碼的連接到用戶註冊的郵箱，檢查該連接是否具備可預測性。好比： http://www.example.com/resetPwd.jsp?token=xxxx，token的值是可預測的，多是對用戶名進行MD5的哈希值等等。 七、  若是系統發送一個臨時密碼給用戶，讓用戶使用該臨時密碼進行登陸，檢查該臨時密碼具備足夠的複雜度（參考用例：複雜度策略）。 八、  檢查用戶使用臨時密碼登陸後系統是否強制要求用戶修改密碼。 九、  若是在完成步驟3或者步驟4後，系統要求用戶在當前頁面內設置新密碼，檢查新密碼和短信驗證碼或者問題的答案是否在同一個HTTP請求內進行提交。
預期結果	服務器返回要求登陸認證或拒絕訪問。
測試結果	一、  步驟3中，系統知足「問答策略」的安全要求。 二、  步驟4中，系統知足「短信驗證碼」的安全要求。 三、  步驟5中，系統不會將原始密碼返回給用戶。 四、  步驟6中，重置密碼的連接是不可預測的。 五、  步驟7中，臨時密碼知足「複雜度策略」的要求。 六、  步驟8中，系統強制要求用戶修改臨時密碼。 七、  步驟9中，新密碼和短信驗證碼或者問題的答案在同一個HTTP請求內進行提交。
備註	步驟6中，重置密碼連接的可預測性測試使用黑盒的方式效果並非特別好，最好是跟研發人員一塊兒確認生成session id的算法（好比：UUID）。

5.1.9、圖形驗證碼：

編號	Web_ Authen_09_01
用例名稱	圖形驗證碼設計測試
用例描述	測試圖形驗證碼設計是否存在安全缺陷。
嚴重級別	高
前置條件	一、  目標業務系統存在圖形驗證碼模塊，而且能將其激活，好比：連續輸錯屢次密碼，頻繁進行某個操做等等。 二、  目標web應用可訪問，業務正常運行。
執行步驟	一、  使用瀏覽器打開目標系統的web登陸頁面，並激活圖形驗證碼。 二、  觀察圖形驗證碼字符長度。 三、  檢查圖形驗證碼的圖片背景是否爲單一顏色（好比：純白色、藍色等）。 四、  連續20次刷新並記錄圖形驗證碼，觀察圖形驗證碼的生成規律。 五、  在存在圖形驗證碼的頁面上點擊右鍵，選擇「查看源文件」，在源文件中搜索當前顯示的圖像驗證碼，並觀察結果。 六、  在圖形驗證碼圖片上點擊右鍵，選擇「屬性」，複製圖形驗證碼的地址，從新在瀏覽器上屢次刷新訪問該地址，觀察結果。
預期結果	一、  步驟2中，圖形驗證碼長度應大於等於4。 二、  步驟3中，圖形驗證碼的圖片背景有干擾元素（好比：花點、條紋）。 三、  步驟4中，不存在明顯可預測規律，好比：1A1B、1A2B和2A2B等。 四、  步驟5中，在源文件中查找不到當前顯示的圖形驗證碼。 五、  步驟6中，在輸入參數不變的狀況下，生成的圖形驗證碼隨機變化。
測試結果
備註	本用例基於IE瀏覽器攥寫，步驟5、6在其它瀏覽器上有相對應的選項。

 

編號	Web_ Authen_09_02
用例名稱	圖形驗證碼邏輯測試
用例描述	測試圖形驗證碼使用邏輯是否存在安全缺陷。
嚴重級別	高
前置條件	一、  目標業務系統存在圖形驗證碼模塊，而且能將其激活，好比：連續輸錯屢次密碼，頻繁進行某個操做等等。 二、  目標web應用可訪問，業務正常運行。 三、  已安裝http攔截代理（burp、fiddler或webscarab都可）。
執行步驟	一、  開啓burp，設置對http請求進行攔截，並在瀏覽器中配置代理。 二、  使用瀏覽器打開目標系統的web登陸頁面，並激活圖形驗證碼。 三、  輸入正確的用戶名、密碼和正確的圖形驗證碼並提交。 四、  在burp攔截到的http請求中觀察用戶名、密碼和圖形驗證碼是否在同一個http請求內提交，好比： POST /login.jsp HTTP/1.1  #登陸接口 Host: www.example.com [other HTTP headers] userName=admin&password=RightPwd& captcha=B8TP 五、  將burp攔截到的http請求轉入burp repeater。 六、  在burp repeater中將http請求中的用戶名或密碼以及圖形驗證碼修改爲錯誤的值，並從新提交，觀察返回結果，好比： POST /login.jsp HTTP/1.1  #登陸接口 Host: www.example.com [other HTTP headers] userName=admin&password=WrongPwd& captcha=1234 七、  在burp repeater中將http請求中設置使用正確的用戶名和圖形驗證碼以及錯誤的密碼並提交，好比： POST /login.jsp HTTP/1.1  #登陸接口 Host: www.example.com [other HTTP headers] userName=admin&password=WrongPwd& captcha= B8TP 八、  從新將密碼修改爲正確的值（本例爲RightPwd）並再次提交，觀察目標系統的返回結果。
預期結果	一、  步驟4中，用戶名、密碼和圖形驗證碼是在同一個http請求內提交。 二、  步驟6中，目標系統返回相似「圖型驗證碼錯誤」的提示信息或者相對應的錯誤代碼，若是返回了相似「用戶名或密碼錯誤」的信息則表示後臺在處理邏輯上存在漏洞。 三、  目標系統返回相似「驗證碼錯誤/失效」的信息或者錯誤碼。
測試結果
備註

提示：若是IE顯示不正常，請使用chrome瀏覽器