一、 業(yè)務(wù)安全概述

1.1 業(yè)務(wù)安全現(xiàn)狀

1.1.1 業(yè)務(wù)邏輯漏洞

? 近年來，隨著信息化技術(shù)的迅速發(fā)展和全球一體化進(jìn)程的不斷加快，計(jì)算機(jī)和網(wǎng)絡(luò)已經(jīng)成為與所有人都息息相關(guān)的工具和媒介，個(gè)人的工作、生活和娛樂，企業(yè)的管理，乃至國家的發(fā)展和改革都無處其外。信息和互聯(lián)網(wǎng)帶來的不僅僅是便利和高效，大量隱私、敏感和高價(jià)值的信息數(shù)據(jù)和資產(chǎn)，成為惡意攻擊者攻擊和威脅的主要目標(biāo)，從早期以極客為核心的黑客黃金時(shí)代，到現(xiàn)在利益鏈驅(qū)動(dòng)的龐大黑色產(chǎn)業(yè)，網(wǎng)絡(luò)安全已經(jīng)成為任何個(gè)人、企業(yè)、組織和國家所必須面臨的重要問題。網(wǎng)絡(luò)安全和信息化是事關(guān)國家安全和國家發(fā)展、事關(guān)廣大人民群眾工作生活的重大戰(zhàn)路問題，沒有網(wǎng)絡(luò)安全就沒有國家安全，沒有信息化就沒有現(xiàn)代化?！?br /> ? 隨著互聯(lián)網(wǎng)+的發(fā)展，經(jīng)濟(jì)形態(tài)不斷地發(fā)生演變。眾多傳統(tǒng)行業(yè)逐步地融入互聯(lián)網(wǎng)并利用信息通信技術(shù)以及互聯(lián)網(wǎng)平臺(tái)進(jìn)行著頻繁的商務(wù)活動(dòng)，這些平臺(tái)（如銀行、保險(xiǎn)、證券、電商、P2P、O2O、游戲、社交、招聘、航空等)由于涉及大量的金錢、個(gè)人信息、交易等重要隱私數(shù)據(jù)，成為了黑客攻擊的首要目標(biāo)，而因?yàn)殚_發(fā)人員安全意識(shí)淡薄（只注重實(shí)現(xiàn)功能而忽路了在用戶使用過程中個(gè)人的行為對(duì)Wb應(yīng)用程序的業(yè)務(wù)邏輯功能的安全性影響)、開發(fā)代碼頻繁迭代導(dǎo)致這些平臺(tái)業(yè)務(wù)邏輯層面的安全風(fēng)險(xiǎn)層出不窮。

? 業(yè)務(wù)邏輯漏洞主要是開發(fā)人員業(yè)務(wù)流程設(shè)計(jì)的缺陷，不僅限于網(wǎng)絡(luò)層、系統(tǒng)層、代碼層等。比如登錄驗(yàn)證的繞過、交易中的數(shù)據(jù)篡改、接口的惡意調(diào)用等，都屬于業(yè)務(wù)邏輯漏洞。

1.1.2 黑客攻擊的目標(biāo)

? 一方面隨著社會(huì)和科技的發(fā)展，購物、社交、P2P、O20、游戲、招聘等業(yè)務(wù)紛紛具備了在線支付功能。如電商支付系統(tǒng)保存了用戶手機(jī)號(hào)、姓名、家庭住址，包括支付的銀行卡信息、支付密碼信息等，這些都是黑客感興趣的敏感信息。攻擊者可以利用程序員的設(shè)計(jì)缺陷進(jìn)行交易數(shù)據(jù)篡改、敏感信息盜取、資產(chǎn)的竊取等操作?，F(xiàn)在的黑客不在以炫耀技能為主要攻擊目的，而主要以經(jīng)濟(jì)利益為目的，攻擊的目的逐漸轉(zhuǎn)變?yōu)橼吚?/p>

? 另一方面，如今的業(yè)務(wù)系統(tǒng)對(duì)于傳統(tǒng)安全漏洞防護(hù)的技術(shù)、設(shè)備和開發(fā)框架越來越成熟，基于傳統(tǒng)漏洞入侵也變得越來越困難，增加了黑客攻擊的成本。而業(yè)務(wù)邏輯漏洞可以逃逸各種安全防護(hù)，迄今為止沒有很好的解決辦法。也是為什么黑客偏好使用業(yè)務(wù)邏輯漏洞攻擊的一個(gè)原因。

? 一夜薅走星巴克上千萬，背后的“?毛黨”究竟有多可怕？

? 拼多多一夜被薅200億？4毛充100話費(fèi)，一個(gè)bug引發(fā)的慘案！

為了解決業(yè)務(wù)安全所帶來的風(fēng)險(xiǎn)，所以要對(duì)業(yè)務(wù)安全進(jìn)行審計(jì)。

二、 業(yè)務(wù)安全測(cè)試

2.1 業(yè)務(wù)安全測(cè)試流程

2.1.1 測(cè)試準(zhǔn)備

• 準(zhǔn)備階段主要包括對(duì)業(yè)務(wù)系統(tǒng)的前期熟悉?作，以了解被測(cè)試業(yè)務(wù)系統(tǒng)的數(shù)量、規(guī)模和場(chǎng)景等內(nèi)容。

• 針對(duì)?盒測(cè)試，可以結(jié)合相關(guān)開發(fā)?檔去熟悉相關(guān)系統(tǒng)的業(yè)務(wù)；

• 針對(duì)?盒測(cè)試，可通過實(shí)際操作還原業(yè)務(wù)流程的?式理解業(yè)務(wù)。

2.1.2 業(yè)務(wù)調(diào)研

? 業(yè)務(wù)調(diào)研階段主要針對(duì)業(yè)務(wù)系統(tǒng)相關(guān)負(fù)責(zé)?進(jìn)?訪談?wù){(diào)研，了解業(yè)務(wù)系統(tǒng)的整體情況，包括部署情況、功能模塊、業(yè)務(wù)流程、數(shù)據(jù)流、業(yè)務(wù)邏輯以及現(xiàn)有的安全措施等內(nèi)容。根據(jù)以往測(cè)試實(shí)施經(jīng)驗(yàn)，在業(yè)務(wù)調(diào)研前可先設(shè)計(jì)訪談問卷，訪談后可能會(huì)隨著對(duì)客?業(yè)務(wù)系統(tǒng)具體情況了解的深?而不斷調(diào)整、更新問卷（?盒測(cè)試此步驟可忽略）。

2.1.3 業(yè)務(wù)建模

? 針對(duì)不同?業(yè)、不同平臺(tái)的業(yè)務(wù)系統(tǒng)，如電商、銀?、?融、證券、保險(xiǎn)、游戲、社交、招聘等業(yè)務(wù)系統(tǒng)，識(shí)別出其中的??險(xiǎn)業(yè)務(wù)場(chǎng)景進(jìn)?建模。

以電商系統(tǒng)為例：

2.1.4 業(yè)務(wù)流程梳理

以商城??登錄。

建模完成后需要對(duì)重要業(yè)務(wù)場(chǎng)景的各個(gè)業(yè)務(wù)模塊逐一進(jìn)?業(yè)務(wù)流程梳理，從前臺(tái)和后臺(tái)、業(yè)務(wù)和?撐系統(tǒng)等4 個(gè)不同維度進(jìn)?分析，識(shí)別各業(yè)務(wù)模塊的業(yè)務(wù)邏輯、業(yè)務(wù)數(shù)據(jù)流和功能字段（傳參點(diǎn)）等。

業(yè)務(wù)模塊的流程梳理主要遵循以下原則：

• 區(qū)分業(yè)務(wù)主流程和分?流程，業(yè)務(wù)梳理?作是圍繞主流程進(jìn)?分析的，而主流程一定是核?業(yè)務(wù)流程，業(yè)務(wù)流程重點(diǎn)梳理的對(duì)象?先應(yīng)放在核?主流程上，務(wù)必梳理出業(yè)務(wù)關(guān)鍵環(huán)節(jié)；

• 概括歸納業(yè)務(wù)分?流程，業(yè)務(wù)分?流程往往存在通?點(diǎn)，可將具有業(yè)務(wù)相似性的分?流程歸納成某一類型的業(yè)務(wù)流程，?須單獨(dú)對(duì)其進(jìn)?測(cè)試；

• 識(shí)別業(yè)務(wù)流程數(shù)據(jù)信息流，特別是業(yè)務(wù)數(shù)據(jù)流在交互?雙?之間傳輸?shù)南群箜樞?、路徑?#xff1b;

• 識(shí)別業(yè)務(wù)數(shù)據(jù)流功能字段，識(shí)別數(shù)據(jù)流中包含的重要程度不等的信息，理解這些字段的含義有助于下階段?險(xiǎn)點(diǎn)分析。

2.1.5 業(yè)務(wù)風(fēng)險(xiǎn)點(diǎn)識(shí)別

? 在完成前期不同維度的業(yè)務(wù)流程梳理?作后，針對(duì)前臺(tái)業(yè)務(wù)應(yīng)著重關(guān)注??界?操作每一步可能的邏輯?險(xiǎn)和技術(shù)?險(xiǎn)；針對(duì)后臺(tái)業(yè)務(wù)應(yīng)著重關(guān)注數(shù)據(jù)安全、數(shù)據(jù)流轉(zhuǎn)及處理的?志和審計(jì)。

? 業(yè)務(wù)?險(xiǎn)點(diǎn)識(shí)別應(yīng)主要關(guān)注以下安全?險(xiǎn)內(nèi)容。

? 業(yè)務(wù)環(huán)節(jié)存在的安全?險(xiǎn)，業(yè)務(wù)環(huán)節(jié)存在的安全?險(xiǎn)指的是業(yè)務(wù)使?者可?的業(yè)務(wù)存在的安全?險(xiǎn)，如注冊(cè)、登錄和密碼找回等?份認(rèn)證環(huán)節(jié)，是否存在完善的驗(yàn)證碼機(jī)制、數(shù)據(jù)一致性校驗(yàn)機(jī)制、Session 和Cookie 校驗(yàn)機(jī)制等，是否能規(guī)避驗(yàn)證碼繞過、暴?破解和SQL 注?等漏洞。

? ?持系統(tǒng)存在的安全?險(xiǎn)，?持系統(tǒng)存在的安全?險(xiǎn)，如??訪問控制機(jī)制是否完善，是否存在?平越權(quán)或垂直越權(quán)漏洞。系統(tǒng)內(nèi)加密存儲(chǔ)機(jī)制是否完善，業(yè)務(wù)數(shù)據(jù)是否明?傳輸。系統(tǒng)使?的業(yè)務(wù)接口是否可以未授權(quán)訪問或調(diào)?，是否可以調(diào)?重放、遍歷，接口調(diào)?參數(shù)是否可篡改等。

? 業(yè)務(wù)環(huán)節(jié)間存在的安全?險(xiǎn)，業(yè)務(wù)環(huán)節(jié)間存在的安全?險(xiǎn)，如系統(tǒng)業(yè)務(wù)流程是否存在亂序，導(dǎo)致某個(gè)業(yè)務(wù)環(huán)節(jié)可繞過、回退，或某個(gè)業(yè)務(wù)請(qǐng)求可以?限重放。業(yè)務(wù)環(huán)節(jié)間傳輸?shù)臄?shù)據(jù)是否有一致性校驗(yàn)機(jī)制，是否存在業(yè)務(wù)數(shù)據(jù)可被篡改的?險(xiǎn)。

? ?持系統(tǒng)間存在的安全?險(xiǎn)，?持系統(tǒng)間存在的安全?險(xiǎn)，如系統(tǒng)間數(shù)據(jù)傳輸是否加密、系統(tǒng)間傳輸?shù)膮?shù)是否可篡改。系統(tǒng)間輸?參數(shù)的過濾機(jī)制是否完善，是否可能導(dǎo)致SQL 注?、XSS 跨站腳本和代碼執(zhí)?漏洞。

? 業(yè)務(wù)環(huán)節(jié)與?持系統(tǒng)間存在的安全?險(xiǎn)，業(yè)務(wù)環(huán)節(jié)與?持系統(tǒng)間存在的?險(xiǎn)，如數(shù)據(jù)傳輸是否加密、加密?式是否完善，是否采?前端加密、簡單MD5 編碼等不安全的加密?式。系統(tǒng)處理多線程并發(fā)請(qǐng)求的機(jī)制是否完善，服務(wù)端邏輯與數(shù)據(jù)庫讀寫是否存在時(shí)序問題，導(dǎo)致競(jìng)爭(zhēng)條件漏洞。系統(tǒng)間輸?參數(shù)的過濾機(jī)制是否完善。

2.1.6 開展測(cè)試

對(duì)前期業(yè)務(wù)流程梳理和識(shí)別出的?險(xiǎn)點(diǎn)，進(jìn)?有針對(duì)性的測(cè)試。

2.1.7 撰寫報(bào)告

? 針對(duì)業(yè)務(wù)安全測(cè)試過程中發(fā)現(xiàn)的?險(xiǎn)結(jié)果進(jìn)?評(píng)價(jià)和建議，綜合評(píng)價(jià)利?場(chǎng)景的?險(xiǎn)程度和造成影響的嚴(yán)重程度，最終完成測(cè)試報(bào)告的編寫。

三、 業(yè)務(wù)安全經(jīng)典場(chǎng)景

3.1 業(yè)務(wù)數(shù)據(jù)安全

3.1.1 商品支付金額篡改

典型案例: 1 毛錢買電冰箱

? 電商類?站在業(yè)務(wù)流程整個(gè)環(huán)節(jié)，需要對(duì)業(yè)務(wù)數(shù)據(jù)的完整性和一致性進(jìn)?保護(hù)，特別是確保在??客?端與服務(wù)端、業(yè)務(wù)系統(tǒng)接口之間的數(shù)據(jù)傳輸?shù)囊恢滦?#xff0c;通常在訂購類交易流程中，容易出現(xiàn)服務(wù)器端未對(duì)??提交的業(yè)務(wù)數(shù)據(jù)進(jìn)?強(qiáng)制校驗(yàn)，過度信賴客?端提交的業(yè)務(wù)數(shù)據(jù)而導(dǎo)致的商品?額篡改漏洞。商品?額篡改測(cè)試，通過抓包修改業(yè)務(wù)流程中的交易?額等字段，例如在?付??抓取請(qǐng)求中商品的?額字段，修改成任意數(shù)額的?額并提交，查看能否以修改后的?額數(shù)據(jù)完成業(yè)務(wù)流程。

? 該項(xiàng)測(cè)試主要針對(duì)訂單?成的過程中存在商品?付?額校驗(yàn)不完整而產(chǎn)?業(yè)務(wù)安全?險(xiǎn)點(diǎn)，通常導(dǎo)致攻擊者?實(shí)際?付遠(yuǎn)低于訂單?付的?額訂購商品的業(yè)務(wù)邏輯漏洞。

3.1.2 前端JS限制繞過

典型案例：繞過JS 限制，購買多個(gè)打折商品

? 很多商品在限制??購買數(shù)量時(shí)，Web 應(yīng)?僅在??通過JS 腳本限制，未在服務(wù)器端校驗(yàn)??提交的數(shù)量，通過抓取客?端發(fā)送的請(qǐng)求包修改JS端?成處理的交易數(shù)據(jù)，如將請(qǐng)求中的商品數(shù)量改為?于最?數(shù)限制的值，查看能否以?正常業(yè)務(wù)交易數(shù)據(jù)完成業(yè)務(wù)流程。

? 該項(xiàng)測(cè)試主要針對(duì)電商平臺(tái)由于交易限制機(jī)制不嚴(yán)謹(jǐn)、不完善而導(dǎo)致的一些業(yè)務(wù)邏輯問題。例如，在促銷活動(dòng)中限制商品購買數(shù)量，卻未對(duì)數(shù)量進(jìn)?前、后端嚴(yán)格校驗(yàn)，往往被攻擊者所利?，購買多個(gè)促銷商品，造成商家的損失。

3.1.3 請(qǐng)求重放測(cè)試

典型案例：一次購買，多次收貨

? 請(qǐng)求重放漏洞是電商平臺(tái)業(yè)務(wù)邏輯漏洞中一種常?的由設(shè)計(jì)缺陷所引發(fā)的漏洞，通常情況下所引發(fā)的安全問題表現(xiàn)在商品?次購買成功后，參照訂購商品的正常流程請(qǐng)求，進(jìn)?完全模擬正常訂購業(yè)務(wù)流程的重放操作，可以實(shí)現(xiàn)“一次購買，多次收貨” 等違背正常業(yè)務(wù)邏輯的結(jié)果。

? 該項(xiàng)測(cè)試主要針對(duì)電商平臺(tái)訂購兌換業(yè)務(wù)流程中對(duì)每筆交易請(qǐng)求的唯一性判斷缺乏有效機(jī)制的業(yè)務(wù)邏輯問題，通過該項(xiàng)測(cè)試可以驗(yàn)證交易流程中隨機(jī)數(shù)、時(shí)間戳等?成機(jī)制是否正常。

3.1.4 業(yè)務(wù)上限測(cè)試

典型案例：?限制查詢歷史消費(fèi)記錄。

	業(yè)務(wù)上限測(cè)試主要是針對(duì)一些電商類應(yīng)?程序在進(jìn)?業(yè)務(wù)辦理流程中，服務(wù)端沒有對(duì)??提交的查詢范圍、訂單數(shù)量、?額等數(shù)據(jù)進(jìn)?嚴(yán)格校驗(yàn)而引發(fā)的一些業(yè)務(wù)邏輯漏洞。通常情況下，在業(yè)務(wù)流程中通過向服務(wù)端提交?于或低于預(yù)期的數(shù)據(jù)以校驗(yàn)服務(wù)端是否對(duì)所提交的數(shù)據(jù)做預(yù)期強(qiáng)校驗(yàn)。存在此類脆弱性的應(yīng)?程序，通常表現(xiàn)為查詢到超出預(yù)期的信息、訂購或兌換超出預(yù)期范圍的商品等。該項(xiàng)測(cè)試主要判斷應(yīng)?程序是否對(duì)業(yè)務(wù)預(yù)期范圍外的業(yè)務(wù)請(qǐng)求做出正確回應(yīng)。

3.1.5 商品訂購數(shù)量篡改

典型案例：damicms_5.4_?上商城任意商品購買

? 商品數(shù)量篡改測(cè)試是通過在業(yè)務(wù)流程中抓包修改訂購商品數(shù)量等字段，如將請(qǐng)求中的商品數(shù)量修改成任意?預(yù)期數(shù)額、負(fù)數(shù)等進(jìn)?提交，查看業(yè)務(wù)系統(tǒng)能否以修改后的數(shù)量完成業(yè)務(wù)流程。

? 該項(xiàng)測(cè)試主要針對(duì)商品訂購的過程中對(duì)異常交易數(shù)據(jù)處理缺乏?控機(jī)制而導(dǎo)致相關(guān)業(yè)務(wù)邏輯漏洞，例如針對(duì)訂購中的數(shù)量、價(jià)格等缺乏判斷而產(chǎn)?意外的結(jié)果，往往被攻擊者利?。

3.2 密碼找回安全

• ??提交修改密碼請(qǐng)求；
• 賬號(hào)認(rèn)證：服務(wù)器發(fā)送唯一ID（例如短信驗(yàn)證碼）只有賬?所有者才能看的地?，完成?份驗(yàn)證；
• ?份驗(yàn)證：??提交驗(yàn)證碼完成?份驗(yàn)證；

3.2.1 驗(yàn)證碼客戶端回顯測(cè)試

典型場(chǎng)景：

• 任意??登錄

使?驗(yàn)證碼的場(chǎng)景：

• ?機(jī)驗(yàn)證：防?機(jī)器操作，爆破表單。

• 唯一憑據(jù)：唯一性判斷，任意賬?登錄。

? 找回密碼測(cè)試中要注意驗(yàn)證碼是否會(huì)回顯在響應(yīng)中，有些?站程序會(huì)選擇將驗(yàn)證碼回顯在響應(yīng)中，來判斷??輸?的驗(yàn)證碼是否和響應(yīng)中的驗(yàn)證碼

3.2.2 驗(yàn)證暴力破解

典型案例：

• 驗(yàn)證碼?使?次數(shù)限制

   找回密碼功能模塊中通常會(huì)將??憑證（一般為驗(yàn)證碼）發(fā)送到????才可以看到的?機(jī)號(hào)或者郵箱中，只要??不泄露??的驗(yàn)證碼就不會(huì)被攻擊者利?，但是有些應(yīng)?程序在驗(yàn)證碼發(fā)送功能模塊中驗(yàn)證碼位數(shù)及復(fù)雜性較弱，也沒有對(duì)驗(yàn)證碼使?次數(shù)做限制而導(dǎo)致驗(yàn)證碼可被暴?枚舉并修改任意??密碼。
  

? 在測(cè)試驗(yàn)證碼是否可以被暴?枚舉時(shí)，可以先將驗(yàn)證碼多次發(fā)送給??的賬號(hào)，觀察驗(yàn)證碼是否有規(guī)律，如每次接收到的驗(yàn)證碼為純數(shù)字并且是4位數(shù)。

3.2.3 Response 狀態(tài)值修改測(cè)試

? Response 狀態(tài)值修改測(cè)試，即修改請(qǐng)求的響應(yīng)結(jié)果來達(dá)到密碼重置的?的，存在這種漏洞的?站或者?機(jī)App 往往因?yàn)樾ｒ?yàn)不嚴(yán)格而導(dǎo)致了?常危險(xiǎn)的重置密碼操作。

? 這種漏洞的利??式通常是在服務(wù)端發(fā)送某個(gè)密碼重置的憑證請(qǐng)求后，出現(xiàn)特定的響應(yīng)值，?如：

• true

• 1

• ok

• success

• 200

…

	?站看到回顯內(nèi)容為特定值后即修改密碼或者登陸，通常這種漏洞的回顯值校驗(yàn)是在客?端進(jìn)?的，所以只需要修改服務(wù)器的響應(yīng)數(shù)據(jù)包即可。

3.2.4 Session覆蓋

? Session ID 也叫會(huì)話ID，服務(wù)器對(duì)瀏覽器客?端???份進(jìn)?唯一性標(biāo)志。

	找回密碼邏輯漏洞測(cè)試中也會(huì)遇到參數(shù)不可控的情況，?如要修改的??名或者綁定的?機(jī)號(hào)?法在提交參數(shù)時(shí)修改，服務(wù)端通過讀取當(dāng)前session 會(huì)話來判斷要修改密碼的賬號(hào)，這種情況下能否對(duì)session 中的內(nèi)容做修改以達(dá)到任意密碼重置的?的呢？

? 在某?站中的找回密碼功能中，業(yè)務(wù)邏輯是：由??使??機(jī)進(jìn)?密碼重置，然后服務(wù)端向?機(jī)發(fā)送驗(yàn)證碼短信，??輸?驗(yàn)證碼提交后，進(jìn)?密碼重置??。

對(duì)?站中Session 覆蓋的測(cè)試如下：

• 打開瀏覽器，訪問重置密碼??，并提交??的?機(jī)號(hào)（133），同時(shí)瀏覽器接收Session ID；

• ???的賬號(hào)（?機(jī)號(hào)，133）接收憑證（短信驗(yàn)證碼）；

• 獲得憑證校驗(yàn)成功后，進(jìn)?密碼重置??；

• 在瀏覽器新標(biāo)簽重新打開找回密碼??，輸??標(biāo)?機(jī)號(hào)(177)，此時(shí)服務(wù)器就會(huì)重新下發(fā)Session ID；此時(shí)當(dāng)前SessionID 已經(jīng)被覆蓋，重新回到第三步中打開的重置密碼??即可重置?標(biāo)?機(jī)號(hào)密碼。

漏洞原因：

? 在驗(yàn)證碼校驗(yàn)之后，沒有及時(shí)更新Session ID，或者沒有及時(shí)更新服務(wù)器端SESSION 信息。SessionID 不僅要與?機(jī)號(hào)綁定，還要與驗(yàn)證碼綁定。

3.2.5 弱Token設(shè)計(jì)缺陷測(cè)試

? 在找回密碼功能中，很多?站會(huì)向??郵箱發(fā)送找回密碼??鏈接。??只需要進(jìn)?郵箱，打開找回密碼郵件中的鏈接，就可以進(jìn)?密碼重置??了。找回密碼的鏈接通常會(huì)加?校驗(yàn)參數(shù)來確認(rèn)鏈接的有效性，通過校驗(yàn)參數(shù)的值與數(shù)據(jù)庫?成的值是否一致來判斷當(dāng)前找回密碼的鏈接是否有效。

http://www.xxx.com/findpwd?uid=ajest&token=ajest-2021-1026-1324

3.2.6 密碼找回流程繞過測(cè)試

很多?站的密碼找回功能一般有以下?個(gè)步驟：

• ??輸?找回密碼的賬號(hào)；

• 校驗(yàn)憑證：向??發(fā)送短信驗(yàn)證碼或者找回密碼鏈接，??回填驗(yàn)證碼或單擊鏈接進(jìn)?密碼重置??，以此?式證明當(dāng)前操作??是賬號(hào)主?；

• 校驗(yàn)成功進(jìn)?重置密碼??（接口）。

? 在找回密碼邏輯中，第?步校驗(yàn)憑證最為重要。不是賬號(hào)主?是?法收到校驗(yàn)憑證的，試想有沒有辦法可以繞過第?步憑證校驗(yàn)，直接進(jìn)?第三步重置密碼呢？

? ??修改密碼需要向服務(wù)器發(fā)送修改密碼請(qǐng)求，服務(wù)器通過后再修改數(shù)據(jù)庫中相應(yīng)的密碼，所以在測(cè)試中我們?先要收集三個(gè)步驟的請(qǐng)求接口，重點(diǎn)是收集到最后一步重置密碼的接口，這樣我們可以直接跳過憑證校驗(yàn)的接口去嘗試直接重置密碼。

3.2.7 接口參數(shù)賬號(hào)修改

典型案例：

• metinfo_4.0 任意賬號(hào)密碼重置

? 找回密碼功能邏輯中常常會(huì)在??修改密碼的接口提交的參數(shù)中存在傳遞??賬號(hào)的參數(shù)，而??賬號(hào)參數(shù)作為一個(gè)可控變量是可以被篡改的，從而導(dǎo)致修改賬號(hào)密碼的憑證或修改的?標(biāo)賬號(hào)出現(xiàn)偏差，最終造成任意賬號(hào)密碼修改的漏洞。

? 通常在找回密碼邏輯中，服務(wù)端會(huì)要求??提供要修改的賬號(hào)，然后給這個(gè)賬號(hào)發(fā)送只有賬號(hào)主?才能看到的憑證。?如給這個(gè)賬號(hào)主?綁定的郵箱或者?機(jī)號(hào)發(fā)送驗(yàn)證碼，或者找回密碼鏈接，這樣可以保證只有賬號(hào)主?才可以看到這些憑證。但是如果服務(wù)器對(duì)賬號(hào)的控制邏輯不當(dāng)，就會(huì)導(dǎo)致原有賬號(hào)被篡改為其他賬號(hào)，服務(wù)器端把憑證發(fā)送給篡改后的賬號(hào)的郵箱或?機(jī)，最終造成可利?憑證重置任意賬號(hào)密碼的漏洞。

而??賬號(hào)參數(shù)作為一個(gè)可控變量是可以被篡改的，從而導(dǎo)致修改賬號(hào)密碼的憑證或修改的?標(biāo)賬號(hào)出現(xiàn)偏差，最終造成任意賬號(hào)密碼修改的漏洞。

? 通常在找回密碼邏輯中，服務(wù)端會(huì)要求??提供要修改的賬號(hào)，然后給這個(gè)賬號(hào)發(fā)送只有賬號(hào)主?才能看到的憑證。?如給這個(gè)賬號(hào)主?綁定的郵箱或者?機(jī)號(hào)發(fā)送驗(yàn)證碼，或者找回密碼鏈接，這樣可以保證只有賬號(hào)主?才可以看到這些憑證。但是如果服務(wù)器對(duì)賬號(hào)的控制邏輯不當(dāng)，就會(huì)導(dǎo)致原有賬號(hào)被篡改為其他賬號(hào)，服務(wù)器端把憑證發(fā)送給篡改后的賬號(hào)的郵箱或?機(jī)，最終造成可利?憑證重置任意賬號(hào)密碼的漏洞。

? 接口參數(shù)賬號(hào)修改流程測(cè)試為攔截前端請(qǐng)求，通過修改請(qǐng)求內(nèi)的賬號(hào)ID 、名稱或者郵箱、?機(jī)號(hào)等參數(shù)，將修改后的數(shù)據(jù)發(fā)送給服務(wù)器進(jìn)?欺騙達(dá)到密碼重置的?的。