WEB安全新玩法 [9] 重置密碼之驗證流程防繞過

通常來講，業務流程中出現多個操做環節時，是須要順序完成的。程序設計者每每按照正經常使用戶的操做順序實現功能，而忽略了攻擊者可以繞過中途環節，直接在後續環節上進行非法操做。iFlow 業務安全加固平臺可以在不修改網站程序的狀況下，強制流程的順序執行。

---

某網站系統在用戶重置密碼時，需進行算術題人機識別驗證，再進入郵箱驗證碼驗證環節，經過後才能真正地重置密碼。因爲程序設計不當，攻擊者能夠輸入任意受害者帳號，並正常完成算術題驗證後，直接繞過郵箱驗證碼驗證過程，進入到重置受害者密碼的環節。咱們接下來會看到如何利用 iFlow 來防範這類流程繞過。

1、原始網站

1.1 正經常使用戶訪問

用戶進入登陸頁面，點擊找回密碼連接。

在第一步確認帳號頁面中輸入用戶名和算術題驗證碼。

正確提交答案後，網站向用戶的註冊郵箱發送驗證碼。用戶進入第二步進行安全驗證的頁面，用戶將郵件中的驗證碼在頁面中輸入。

郵件驗證碼正確，則用戶可在第三步設置新密碼中重置密碼。

HTTP 交互流程以下：

sequenceDiagram participant 正經常使用戶 participant 瀏覽器 participant Web服務器 participant 郵件系統 正經常使用戶->>瀏覽器: 點擊找回密碼連接 瀏覽器->>Web服務器: GET /one/getpassword.php Web服務器->>正經常使用戶: 顯示：第一步頁面 正經常使用戶->>瀏覽器: 填寫用戶名和算術題驗證碼 瀏覽器->>Web服務器: POST /one/getpassword.php<br/>action=step1,username=test01 Web服務器->>郵件系統: 發送驗證碼到郵箱 Web服務器->>正經常使用戶: 顯示：第二步頁面 正經常使用戶->>郵件系統: 以test01收取驗證碼 正經常使用戶->>瀏覽器: 填寫郵箱驗證碼 瀏覽器->>Web服務器: POST /one/getpassword.php<br/>action=step2,yzm=338238 Note over Web服務器: 驗證郵箱驗證碼正確 Web服務器->>正經常使用戶: 顯示：第三步頁面 正經常使用戶->>瀏覽器: 填寫新的密碼 瀏覽器->>Web服務器: POST /one/getpassword.php<br/>action=step3，password=123456 Web服務器->>正經常使用戶: 顯示：設置新密碼成功

1.2 攻擊者訪問

攻擊者使用 Burpsuite 工具做爲瀏覽器和 Web 服務器之間的代理，Burpsuite 能夠攔截報文並修改其中內容後再發出。

攻擊者在第一步確認帳號頁面中填寫受害者的帳號和正確的算術題驗證碼並點擊下一步。

而後，點擊瀏覽器的回退按鈕回到上述頁面，打開 Burpsuite 的攔截開關，從新填寫信息，並點擊下一步。攻擊者能夠在 Burpsuite 看到發出的第一步請求報文。

攻擊者在 Burpsuite 中將請求體內容修改成第三步的報文，發往網站服務器。

攻擊者在瀏覽器中能夠看到密碼重置成功的提示。

至此，攻擊者在未訪問受害者郵箱的狀況下，順利修改了受害者的密碼。

HTTP 交互流程以下：

sequenceDiagram participant 攻擊者 participant 瀏覽器 participant 攻擊工具 participant Web服務器 participant 郵件系統 攻擊者->>瀏覽器: 點擊找回密碼連接 瀏覽器->>Web服務器: GET /one/getpassword.php Web服務器->>攻擊者: 顯示：第一步頁面 攻擊者->>瀏覽器: 填寫用戶名和算術題驗證碼 瀏覽器->>Web服務器: POST /one/getpassword.php<br/>action=step1,username=test01 Web服務器->>郵件系統: 發送驗證碼到郵箱 Web服務器->>攻擊者: 顯示：第二步頁面 攻擊者->>瀏覽器: 點擊回退按鈕 瀏覽器->>Web服務器: GET /one/getpassword.php Web服務器->>攻擊者: 顯示：第一步頁面 攻擊者->>瀏覽器: 填寫用戶名和算術題驗證碼 瀏覽器->>攻擊工具: POST /one/getpassword.php<br/>action=step1,username=test01 rect rgb(250, 128, 128) Note over 攻擊工具: 將請求修改爲第三步報文 end 攻擊工具->>Web服務器: POST /one/getpassword.php<br/>action=step3，password=123456 Web服務器->>攻擊者: 顯示：設置用戶密碼成功

2、iFlow虛擬補丁後的網站

咱們在 Web 服務器前部署 iFlow 業務安全加固平臺，它有能力攔截、計算和修改雙向 HTTP 報文並具有存儲能力，成爲 Web 應用的虛擬補丁。在本例中，iFlow 在進行第三步操做時，檢查了第二步操做中所做的記號，確保操做沒法繞過第二步直接進入第三步。

2.1 正經常使用戶訪問

在第二步郵箱驗證碼返回正確信息時，iFlow 給會話設置一個第二步完成標誌。在第三步提交新密碼時，iFlow 會檢查第二步完成標誌，若是這個標誌存在，則將請求發到後端 Web 服務器進行正常處理。

正經常使用戶的 HTTP 交互流程以下：

sequenceDiagram participant 正經常使用戶 participant 瀏覽器 participant iFlow participant Web服務器 participant 郵件系統 正經常使用戶->>瀏覽器: 點擊找回密碼連接 瀏覽器->>Web服務器: GET /one/getpassword.php Web服務器->>正經常使用戶: 顯示：第一步頁面 正經常使用戶->>瀏覽器: 填寫用戶名和算術題驗證碼 瀏覽器->>Web服務器: POST /one/getpassword.php<br/>action=step1,username=test01 Web服務器->>郵件系統: 發送驗證碼到郵箱 Web服務器->>正經常使用戶: 顯示：第二步頁面 正經常使用戶->>郵件系統: 以test01收取驗證碼 正經常使用戶->>瀏覽器: 填寫郵箱驗證碼 瀏覽器->>Web服務器: POST /one/getpassword.php<br/>action=step2,yzm=338238 Note over Web服務器: 驗證郵箱驗證碼正確 Web服務器->>iFlow: 返回：第二步頁面 rect rgb(160, 250, 160) Note over iFlow: 設置第二步完成標誌 end iFlow->>正經常使用戶: 顯示：第二步頁面 正經常使用戶->>瀏覽器: 填寫新的密碼 瀏覽器->>iFlow: POST /one/getpassword.php<br/>action=step3，password=123456 rect rgb(160, 250, 160) Note over iFlow: 檢查第二步完成標誌：存在 end iFlow->>Web服務器: 原請求報文 Web服務器->>正經常使用戶: 顯示：設置新密碼成功

2.2 攻擊者訪問

如前所示，若是攻擊者直接將第二步請求的報文修改成第三步請求的報文發出，iFlow 會攔截這個報文並檢查第二步完成標誌。因爲攻擊者沒有實際完成第二步操做，所以也就沒有第二步完成標誌，iFlow 不會繼續向後端 Web 服務器執行密碼重置操做。

攻擊者的 HTTP 協議交互過程以下：

sequenceDiagram participant 攻擊者 participant 瀏覽器 participant 攻擊工具 participant iFlow participant Web服務器 攻擊者->>瀏覽器: 點擊找回密碼連接 瀏覽器->>Web服務器: GET /one/getpassword.php Web服務器->>攻擊者: 顯示：第一步頁面 攻擊者->>瀏覽器: 填寫用戶名和算術題驗證碼 瀏覽器->>Web服務器: POST /one/getpassword.php<br/>action=step1,username=test01 Web服務器->>攻擊者: 顯示：第二步頁面 攻擊者->>瀏覽器: 點擊回退按鈕 瀏覽器->>Web服務器: GET /one/getpassword.php Web服務器->>攻擊者: 顯示：第一步頁面 攻擊者->>瀏覽器: 填寫用戶名和算術題驗證碼 瀏覽器->>攻擊工具: POST /one/getpassword.php<br/>action=step1,username=test01 rect rgb(250, 128, 128) Note over 攻擊工具: 修改爲第三步請求 end 攻擊工具->>iFlow: POST /one/getpassword.php<br/>action=step3，password=123456 rect rgb(160, 250, 160) Note over iFlow: 第二步完成標誌：不存在 end iFlow->>攻擊者: 顯示：訪問被拒絕

2.3 代碼

iFlow 內置的 W2 語言是一種專門用於實現 Web 應用安全加固的類編程語言。它介於配置和通用語言之間，具有編程的基本要素和針對 HTTP 協議的特有擴展，能爲業務系統編寫涉及複雜判斷和動態修改的邏輯。

考慮到安全產品的使用者一般爲非程序員，他們習慣面對配置文件而非一段代碼。所以，W2 語言雖包含語言要素，仍以規則文件方式呈現，並採用能夠體現層次結構和方便詞法校驗的 JSON 格式。

用 W2 語言實現上述虛擬補丁的代碼以下：

[
	{
		"if": [
			"REQUEST_FILENAME == '/ajax/yzm_check_ajax.php'",
			{
				"variable": "RESPONSE_BODY",
				"operator": "contain",
				"pattern": "window.document.userreg.yzm_mobile2.value='yes'"
			}
		],
        "then": "SESSION.step2_ok@300 = true"
    },
    {
        "if": [
			"REQUEST_METHOD == 'POST'",
			"REQUEST_FILENAME == '/one/getpassword.php'",
			"@ARGS.action == 'step3'"
		],
        "then": {
            "if": "SESSION.step2_ok",
            "then": "SESSION.step2_ok=null",
			"else": {
				"execution": "SESSION.step2_ok=null",
				"verdict": {
                    "action": "deny",
                    "log": "invalid access step3!"
                }
            }
        }
    }
]

示例代碼中有兩條規則，分別做用以下：

第一條規則

當服務器在第二步操做返回郵箱驗證碼成功時，iFlow 攔截此響應。而且，iFlow 將建立一個會話 (SESSION) 的存儲變量 step2_ok 爲 true。

第二條規則

當瀏覽器請求第三步操做即確認重置密碼時，iFlow 攔截此請求。iFlow 將檢查會話 (SESSION) 的存儲變量 step2_ok 是否存在：若是存在則放行，不存在則拒絕訪問。無論哪一種情形，存儲變量 step2_ok 都會被清除，以防止第三步被重複單獨訪問。

注意：上述會話中的 step2_ok 是保存在服務器端的 iFlow 存儲中的，攻擊者在瀏覽器端是看不到數據更沒法進行修改的。

3、總結

iFlow 使用兩條規則在不修改服務器端代碼的前提下，保證了順序操做中的關鍵環節不被繞過。

此外，咱們注意到，關鍵環節的完成判斷是以響應內容做爲依據而非以發起請求做爲依據的，這樣能夠避免攻擊者隨手發出一個不成功的操做來欺騙 iFlow。固然，這樣作的前提是 iFlow 具有強大的響應報文識別能力。（張戈 | 天存信息）