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

任意用戶密碼重置

常見的缺陷：

* 1.驗證碼類缺陷

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

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

* 2.未校驗權(quán)限/前端校驗/越權(quán)

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

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

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

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

* 3.HOST頭偽造

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

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

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

驗證碼繞過

常見的缺陷：

1）圖形類驗證碼繞過

* 1.圖形驗證碼可復用

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

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

* 2.圖形驗證碼易識別

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

2）短信類驗證碼繞過

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

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

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

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

* 3.萬能驗證碼

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

短信/語音驗證碼重放

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

常見缺陷：

* 1.無限制發(fā)送

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

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

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

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

b.驗證手機號是否發(fā)送過驗證碼

某些程序員會這樣設(shè)計流程：

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

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

c.發(fā)送手機號驗證碼

* 3.手機號可遍歷發(fā)送

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

業(yè)務流程繞過

常見缺陷：

* 1.無驗證步驟跳躍

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

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

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

加密算法脆弱

常見缺陷：

* 1.前端呈現(xiàn)加密算法代碼

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

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

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

支付邏輯漏洞

常見缺陷：

* 1.金額修改

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

* 2.數(shù)量修改

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

* 3.sign值可逆

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

條件競爭(HTTP并發(fā))

常見缺陷：

* 1.條件競爭（HTTP并發(fā)）

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

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

配置好代理，設(shè)置好攔截：

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

填入要重發(fā)的次數(shù)：

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

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

審核編輯 ：李倩