Web安全中的業務安全問題

今天下午看完了《業務安全實戰指南》，是一本2018年的新書。這本書包含的業務安全内容感覺挺全的，不過編排并不好，很多地方都有重複；應該是不同作者寫了不同章節，但是事先沒有分的太清楚。

我将結合以往知識與這本書的内容總結一下Web安全中的業務安全問題。

業務安全問題給我的最大感覺就是：漏洞本身技術含量并不高，關鍵是處理邏輯是否足夠嚴密。我想大緻可以将導緻業務漏洞的原因分為以下兩類：1.過于信賴用戶端傳入的資料，沒有在伺服器端驗證一緻性；2.暴露密令或者密令過于簡單。

業務安全漏洞可以分為如下幾種類型：1.篡改型 2.回顯型 3.跳過型 4.弱驗證

篡改型

1.對各類id的篡改

說是對各類id的篡改，其實就是對各種辨別的篡改，隻是這些辨別往往起名為uid、pid之類的名字是以我這麼叫它。

各種id可以存在于很多地方，最多的肯定就是url中，還有可能出現在post内容和cookie中，它們往往可以代表使用者辨別、訂單辨別、商品辨別等等，通過對它的篡改往往造成水準越權通路，或者是用A商品的價格購買B商品。

2.對郵箱、手機号的篡改

涉及到郵箱與手機号的地方往往是在對使用者的身份進行驗證，它最常出現在忘記密碼、重置密碼的位置。假設我們用陌生人A的賬号進行重置密碼操作，本地也許會向伺服器發送一個請求其中包含A的注冊用手機号或者郵箱，如果我們修改為自己的手機号或者郵箱也許就能獲得該驗證碼。

3.對session的篡改

這裡主要想說的是session覆寫。還是以重置密碼舉例子，假設重置密碼需要三個步驟：

1. 輸入賬号
2. 輸入驗證碼
3. 輸入新密碼

我們自己已經新增賬號B，目标是修改賬号A的密碼。那麼，在第一步我們輸入B的賬号，此時session被設定為賬号B的資訊。然後進行第二步，由于B賬号是自己的，我們可以擷取到驗證碼并進入第三步。這時新打開一個标簽頁，在第一步輸入賬号A并進入第二步，這時session被更新為A的資訊。再傳回剛才标簽的第三步，如果上面有賬号提示可以重新整理看看是否會變成A的賬号，如果變成此時再輸入新密碼就更新了A的密碼。

4.對傳回值的篡改

假如在輸入某一個無法擷取的驗證碼時，有可能送出驗證碼的頁面邏輯是發送Ajax請求并讀取傳回值結果。比如我們輸入錯誤的驗證碼會傳回{res:0}，也許用burpsuite截取response并将其改為{res:1}再傳給本地就相當于輸入了正确的驗證碼。不過我覺得這種本地處理直接看代碼也可以繞過，但是比較麻煩。

5.對數量、金額的篡改

這種篡改不必多說，是一種讓人很容易想到的篡改，填負數之類都是常見的手段。不過我今天看到一個之前沒有注意過的金額篡改，就是一些網站在調用支付寶之類第三方付款時，也許付款成功就算成功，并不檢查付款金額，是以可以抓調用支付寶的請求并修改其中金額。

回顯型

回顯型主要是指各種驗證碼，密保問題答案被隐藏在用戶端中，比如URL中、頁面源代碼中。這種隐藏也許是編碼後的，也許是未編碼的。

跳過型

所謂跳過型，舉這麼一個例子。我想往我的賬戶上充值100元，分為下面幾步：

1. 打開充值頁面，選擇充值方式(www.xxx.com/pay.php)
2. 跳轉第三方支付并成功
3. 傳回原網站，并顯示充值成功(www.xxx.com/pay_success.php?num=100)

假設我跳過1、2步，直接輸入第三步的URL，也許同樣能夠充值成功。

弱驗證

1.校驗碼弱驗證

假設驗證碼位數比較少，重新重新整理時間又比較充足，就可以使用窮舉的方式破解驗證碼。

2.密碼重置連結Token弱驗證

在很多網站密碼重置的方式是向注冊用郵箱發送一個重置連結，點選連結進行重置。雖然我們不能登入攻擊目标的郵箱，卻可以嘗試猜解該重置連結的Token。

比如自己先注冊一個名為test的使用者，驗證發現它的重置連結是：

www.xxx.com/changePass.php?id=test&token=098F6BCD4621D373CADE4E832627B4F6
           

Token就是md5加密的test，我們找到該規律後就可以猜到目标使用者的重置連結。