介紹：這里對Web應用業務邏輯方面的安全缺陷進行介紹和常見案例講解。

任意用戶密碼重置

常見的缺陷：

* 1.驗證碼類缺陷

-場景：1.1 驗證碼回顯在客戶端(響應主體、Set-Cookie等等…)。

1.2 驗證碼過于簡易時效性過長，接口未做限制(一般為純數字4-8位數，時效性長達30分鐘以上可以對驗證碼進行枚舉)。

* 2.未校驗權限/前端校驗/越權

-場景：2.1 任意手機號驗證碼都可重置任意賬號。

2.2 修改響應包的主體(根據實際情況來修改 例如驗證請求對應的響應報文的主體為false你可以修改為true)。

2.3 同一瀏覽器進入A用戶的重置，然后關閉再進入B用戶的重置 而實際上重置A用戶。

2.4 修改重置密碼的相關參數(例如 userid等等…)。

* 3.HOST頭偽造

-場景：3.1 在郵箱找回密碼的時候，可以簡單替換Host部分進行Fuzz，看看找回密碼的鏈接中的域名是否是根據Host來生成的如果是可以替換成自己的域名。但是這種思路很雞肋，因為需要用戶的點擊，這樣才可以根據日志看到重置密碼的鏈接，萬一重置密碼的鏈接時效性過去就無奈了。

* 4.找回密碼的憑證脆弱

-場景：4.1 見過最多的是找回密碼的token是base64編碼的，而解碼后的明文根據其規則修改就可以成為別人用戶找回密碼的憑證了。

驗證碼繞過

常見的缺陷：

1）圖形類驗證碼繞過

* 1.圖形驗證碼可復用

-場景：3.1 驗證碼刷新之后，而歷史刷新的驗證碼還是可以繼續使用。

3.2 驗證碼使用過后不刷新，時效性不過期，可以一直復用。

* 2.圖形驗證碼易識別

-場景 4.1 很多驗證碼的顯示很簡單，容易被機器識別。

2）短信類驗證碼繞過

* 1.驗證碼過于簡易&接口未限制

-場景：1.1 有些手機短信驗證碼都為 4-8位 純數字的驗證碼，在接口沒有任何限制的情況下是可以直接爆破的。

* 2.驗證碼發送復用&時效性過長&接口未限制

-場景：2.1 6位數驗證碼時效性為5分鐘，但是在這里同一手機號發送的驗證碼都是一樣的，所以可以在4分鐘的時候重新發送一次驗證碼這樣驗證碼就又有效了，因為驗證碼一直在被復用，所以可以爆破。

* 3.萬能驗證碼

-場景：3.1 這是很多大企業的詬病，在未上線前為了方便測試加了888888、000000這樣的萬能驗證碼但是上線后沒去刪除測試的內容導致被惡意利用。

短信/語音驗證碼重放

無論是發送短信還是語音驗證碼來做驗證，都是需要手機號的，而發送驗證碼實際上是需要成本的，需要跟運營商或者是第三方驗證碼平臺進行合作，多數驗證碼為0.01元一條，當然也有更便宜的，所以這邊的問題也會影響到一個企業的資產方面。

常見缺陷：

* 1.無限制發送

-場景：1.1 廠商對驗證碼發送這一塊并沒有進行限制時間發送

* 2.代碼層邏輯校驗問題

-場景：2.1 很多廠商會對手機號進行限制，如果60秒內發送過就不會發送，但是程序員在設計代碼層的邏輯時會出現很多奇葩的問題，例如其為了方便用戶體驗，正常的代碼層的流程為：

a.去除用戶手誤輸入的空格以及一些特殊符號

b.驗證手機號是否發送過驗證碼

某些程序員會這樣設計流程：

a.驗證手機號是否發送過驗證碼（發送過則不放行 沒發送過則進入下一步）

b.去除用戶手誤輸入的空格以及一些特殊符號

c.發送手機號驗證碼

* 3.手機號可遍歷發送

-場景：3.1 我之前有提到驗證碼發送會影響到企業資產，那么發送驗證碼限制就不能僅僅針對于單一手機號的限制，例如我可以載入一堆手機號的字典，然后直接遍歷發送驗證碼，這也是危害之一。

業務流程繞過

常見缺陷：

* 1.無驗證步驟跳躍

-場景：1.1 出現的場景很多：密碼重置步驟、支付步驟，對于這種的測試方法有很多中：

a.對比法，使用A、B兩個賬號，A賬號先正常走一遍流程，然后記錄流程的請求報文跟響應報文，使用B賬號來測試是否能繞過直接進入最后一步驟。

b.第六感，假設步驟1的網址為:http://www.test.com/step1，這時候你可以憑借你的第六感修改下鏈接為/step2之類的來測試。

加密算法脆弱

常見缺陷：

* 1.前端呈現加密算法代碼

-場景：1.1 很多廠商算法寫的很好，可沒用，因為他用的是JS代碼，在前端會直接能看見，而嘗試跟蹤JS的代碼就會知道是怎么加密的從而可以直接繞過。

* 2.算法脆弱，明文可判斷

-場景：2.1 這是一個看運氣的問題，一段密文為md5的，這時候你要做好自己的分析明文到底是什么，然后去碰撞，例如可能是md5(用戶名+郵箱)這樣的的組合。

支付邏輯漏洞

常見缺陷：

* 1.金額修改

-場景：1.1 支付的過程中有很多涉及金額的元素可以修改運費、優惠價、折扣等，可以修改為負數金額也可以修改金額為小于原金額的數進行測試，有時候會遇到溢出，你修改金額為較大的數看你會出現只支付1元的情況。

* 2.數量修改

-場景：2.1 修改購買物品的數量為小數或者負數，同上，有時候會遇到溢出，你修改數量為較大的數看你會出現只支付1元的情況。

* 3.sign值可逆

-場景：3.1 這是一個看運氣的問題，sign多數為對比確認金額的一段內容，很多都是md5加密的，這時候你要做好自己的分析明文到底是什么，然后去碰撞，例如可能是md5(訂單號+金額)這樣的的組合，然后修改金額重新生成sign就可以繞過金額固定的限制了。

條件競爭(HTTP并發)

常見缺陷：

* 1.條件競爭（HTTP并發）

-場景：1.1 在簽到、轉賬、兌換、購買等場景是最容易出現這樣的問題，而并發測試的方法可以使用Fiddler也可以使用BurpSuite Intruder模塊。

這里例舉下Fiddler測試方法（BurpSuite測試很簡單就不說明了）：

配置好代理，設置好攔截：

然后點擊兌換、轉賬、簽到等最后一步按鈕的時候會抓到一個請求，右鍵這一請求然后按住Shift點擊Replay->Reissue Requests：

填入要重發的次數：

一般為20即可，然后點擊GO放行：

最后看你自己來判斷是否存在并發的問題，例如簽到，如果存在那么肯定是簽到天數或者簽到所獲得的獎勵會一下子有很多，也可以看Fiddler中的響應報文結果。

審核編輯 ：李倩