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

任意用戶密碼重置

常見的缺陷：

* 1.驗(yàn)證碼類缺陷

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

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

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

-場景：2.1 任意手機(jī)號驗(yàn)證碼都可重置任意賬號。

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

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

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

* 3.HOST頭偽造

-場景：3.1 在郵箱找回密碼的時(shí)候，可以簡單替換Host部分進(jìn)行Fuzz，看看找回密碼的鏈接中的域名是否是根據(jù)Host來生成的如果是可以替換成自己的域名。但是這種思路很雞肋，因?yàn)樾枰脩舻狞c(diǎn)擊，這樣才可以根據(jù)日志看到重置密碼的鏈接，萬一重置密碼的鏈接時(shí)效性過去就無奈了。

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

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

驗(yàn)證碼繞過

常見的缺陷：

1）圖形類驗(yàn)證碼繞過

* 1.圖形驗(yàn)證碼可復(fù)用

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

3.2 驗(yàn)證碼使用過后不刷新，時(shí)效性不過期，可以一直復(fù)用。

* 2.圖形驗(yàn)證碼易識別

-場景 4.1 很多驗(yàn)證碼的顯示很簡單，容易被機(jī)器識別。

2）短信類驗(yàn)證碼繞過

* 1.驗(yàn)證碼過于簡易&接口未限制

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

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

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

* 3.萬能驗(yàn)證碼

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

短信/語音驗(yàn)證碼重放

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

常見缺陷：

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

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

* 2.代碼層邏輯校驗(yàn)問題

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

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

b.驗(yàn)證手機(jī)號是否發(fā)送過驗(yàn)證碼

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

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

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

c.發(fā)送手機(jī)號驗(yàn)證碼

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

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

業(yè)務(wù)流程繞過

常見缺陷：

* 1.無驗(yàn)證步驟跳躍

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

a.對比法，使用A、B兩個(gè)賬號，A賬號先正常走一遍流程，然后記錄流程的請求報(bào)文跟響應(yīng)報(bào)文，使用B賬號來測試是否能繞過直接進(jìn)入最后一步驟。

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

加密算法脆弱

常見缺陷：

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

-場景：1.1 很多廠商算法寫的很好，可沒用，因?yàn)樗玫氖荍S代碼，在前端會直接能看見，而嘗試跟蹤JS的代碼就會知道是怎么加密的從而可以直接繞過。

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

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

支付邏輯漏洞

常見缺陷：

* 1.金額修改

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

* 2.數(shù)量修改

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

* 3.sign值可逆

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

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

常見缺陷：

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

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

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

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

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

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

一般為20即可，然后點(diǎn)擊GO放行：

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

審核編輯 ：李倩