一、 Web安全測試的定義

一般而言，Web的安全就是要讓軟件在面對惡意輸入或敵意的情況下，依然能夠充分滿足使用需求。而針對Web的安全性測試是驗證Web應用的安全服務和識別潛在安全性缺陷的過程。

安全測試通常要求測試人員制定詳細的測試策略，并模擬成攻擊者，對軟件系統不同的模塊進行惡意的攻擊或滲透，查看系統是否能正常工作，還原軟件中存在的安全漏洞。安全測試人員一般會使用手動工具或自動工具，根據漏洞原理來模擬和激發Web應用。

?

二、 Web安全測試流程

通常情況下，Web安全測試開展于性能測試前。對于大多數Web項目，測試開始前需要首先要充分解析和分析應用。然后針對各個模塊制定相應的安全測試策略。接著進入手工安全測試階段，驗證基于安全測試的各種漏洞是否存在，包括驗證機制、會話管理、訪問控制、SQL注入、XSS、邏輯缺陷等多方面的漏洞驗證。驗證后整理所有測試過程中發現的安全問題，以報告的形式提交給研發。最后待驗證結束后進行回歸測試，直至所有安全問題全部解決。

?

三、 攻擊驗證機制

驗證機制是Web應用中最常見的，也是最重要的一種安全機制。通常而言， Web應用必須驗證用戶所提交的用戶名和密碼是否正確。正確則允許登錄，錯誤則禁止進入。驗證機制常常被看做是防御Web惡意攻擊的核心機制。如果攻擊者可以輕松突破驗證機制，那么系統的所有功能、數據、私密信息都會被攻擊者控制。驗證機制是其他所有安全機制的前提，如果驗證機制都無法阻止攻擊，那么其他安全機制也大多無法實施。

驗證機制常見的漏洞有以下幾種。

1．密碼保密性不強（弱口令）

一些Web應用程序沒有或很少對用戶密碼強度進行控制。常見的弱口令有：

???非常短或空白密碼。

???常用字典詞匯為密碼（password、123456）。

???密碼與用戶名完全相同。

???長時間使用默認密碼。

2.?暴力攻擊登錄

登錄功能往往是完全公開的，這樣的機制可能會誘使攻擊者利用枚舉來猜測用戶名和密碼，從而獲得訪問應用程序的權利。如果應用程序允許攻擊者用不同的密碼暴力嘗試，直到他找到正確的密碼，這個程序就非常容易遭受攻擊。

應對暴力破解，很多Web應用采取了不同的安全措施：

A．驗證碼

驗證碼是最常見且有效的應對方式，但需要注意以下幾個問題。

???驗證碼是否真實有效。

???驗證碼的復雜度。

???為應對盛行的“打碼”接口。

由于這些問題，驗證碼這種方式也許不能完全避免暴力破解，但實際情況是即使這種方式無法完全生效，也可以使多數隨意的攻擊者停止攻擊行動，轉而攻擊較容易的應用程序。

B. cookie檢測

例如，一些應用程序會設置一個cookie，如failedlogin=O；登錄嘗試失敗，遞增該值，達到某個上限，檢測到這個值并拒絕再次處理登錄。這種客戶端防御方式只可以防止使用瀏覽器手動攻擊。

C.?會話檢測

與cookie檢測類似，將失敗計數器保存在會話中，雖然在客戶端沒有標明該漏洞存在的跡象，但是只要攻擊者獲得一個新的會話，就可以繼續實施暴力攻擊。

D．失敗鎖定賬戶

有些應用程序會采取登錄嘗試達到一定次數后鎖定目標賬戶的方式。但是有可能通過分析其響應，在鎖定賬戶的狀態下仍可以進行密碼猜測攻擊。

3?雙因子認證

它是指結合密碼以及實物（信用卡、SMS手機、令牌或指紋等生物標志）兩種條件對用戶進行認證的方法。其核心是綜合個人密碼和通常為手機來達到雙重認證效果。很多電商、銀行都采用了該認證方式。它最大的缺點就是構建雙因子認證的成本較高，服務器壓力也較大。

4.?詳細的失敗信息

經典的登錄表單會要求用戶輸入兩組信息：用戶名和密碼。如果登錄嘗試失敗，則可以得出結論，至少有一組信息出錯。

但是如果應用程序通知用戶是哪一組信息無效，就可以利用該信息來降低登錄機制的防御效能。

這種漏洞有可能以更隱蔽的方式出現。例如，用戶名無效和密碼錯誤的錯誤消息表面看起來完全相同，但它們之間仍有可能存在著細微的差別，可以通過攔截其response來觀察是否有細微的差別。

5.?密碼修改功能

成熟的系統除了用戶登錄，往往還會提供密碼修改功能，但是在編碼過程中， 往往忘記了這個功能中也會存在一些安全隱患。

密碼修改功能中常見的安全漏洞有：

1）密碼修改功能是否擁有隱藏的后臺接口，如不通過登錄直接可以訪問該功能；

2）是否可以使用不符合標準的密碼，如弱密碼等；

3）密碼修改的請求提交時，是否用戶名也隨之提交？如果提交，是否可以通過修改用戶名來達到修改非當前登錄用戶密碼的目的？

6．忘記密碼功能

網站大多提供“忘記密碼”功能，但是其中往往會存在一些典型的安全問題，其核心問題就是忘記密碼的流程跳過了身份驗證。

如不考慮通過客服找回密碼，通常網站設計有三種方式來認證用戶。

1）用戶設定的安全問題。

2）用戶注冊時留下的安全郵箱。

3）給預留手機號發送驗證碼短信。

基于以上3點，會有以下幾種可能。

1?）需要確認應用程序中是否有隱含的忘記密碼功能或不通過用戶名查詢即可訪問的情況。

2）如果恢復機制使用質詢方式，則確定用戶能否枚舉用戶名來得到質詢信息，與猜測密碼相比，響應質詢更容易。

3）如果在忘記密碼的請求響應中生成一封包含恢復URL的電子郵件，獲取大量此類URL并試圖分析和預測其發送URL的模式，是否可以得到其他未知用戶的恢復URL。

4）無論是使用郵件，還是發送手機驗證碼，查看是否可以攔截請求以修改目標郵箱或手機號，從而達到繞過的目的。

7.?用戶偽裝功能

應用程序有時可能會允許特權用戶偽裝成其他用戶，例如某電商網站擁有類似OOB(on order behalf）的功能，超級管理員可以偽裝成任意用戶來幫助其執行某些操作。

偽裝功能可能存在以下設計漏洞。

1）如上述提到的OOB類功能，網站可能通過嚴格的權限控制（只有超級管理員才可訪問的功能模塊）或是隱藏的鏈接（只有超級管理員才知道）的方式執行，例如在網站中有一個特殊的URL可以鏈接到一個不需要核對用戶身份的頁面執行部分操作。這時攻擊者可以嘗試使用枚舉URL或者使用爬蟲，從而攔截到該功能，劫持所有用戶。

2）有些偽裝功能以后門密碼形式執行，也就是說，對于一個普通用戶， 除去該用戶設置的密碼外，還擁有一個“萬能密碼”。這種設計可能招致暴力破解， 攻擊者一次攻擊獲得兩個“觸點”，從而便可揭示出后臺密碼。

8.?多階段登錄

在日常網絡應用中，經常發現一些多階段登錄的功能，如在輸入用戶名、 密碼后，可能會要求你驗證一個私密問題，通過方可登錄。這樣的設計毫無疑問會增加驗證機制的安全性，但這樣的過程也可能產生更多的執行缺陷。

下面以兩階段登錄驗證機制為例，說明多階段登錄可能存在的設計缺陷。

1）程序可能會認為，用戶一旦訪問到第二階段，就已經完成第一階段的驗證，那么可能會允許攻擊者直接進入第二階段。

2）程序可能會認為，在兩個階段的執行過程中，用戶身份不會發生任何變化，于是并沒有在每個階段都確認用戶身份。例如，第一階段提交用戶名和密碼， 第二階段可能需要重新提交某個私密問題答案和一些個人信息。如果攻擊者在進行第二個階段時提供了有效數據，但是不同于第一階段時的用戶，那么程序可能會允許用戶通過驗證。