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

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

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

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

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

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

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

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

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

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

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

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

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

2.1.1 測試準(zhǔn)備

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

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

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

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

? 業(yè)務(wù)調(diào)研階段主要針對業(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ù)以往測試實施經(jīng)驗，在業(yè)務(wù)調(diào)研前可先設(shè)計訪談問卷，訪談后可能會隨著對客?業(yè)務(wù)系統(tǒng)具體情況了解的深?而不斷調(diào)整、更新問卷（?盒測試此步驟可忽略）。

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

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

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

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

以商城??登錄。

建模完成后需要對重要業(yè)務(wù)場景的各個業(yè)務(wù)模塊逐一進(jìn)?業(yè)務(wù)流程梳理，從前臺和后臺、業(yè)務(wù)和?撐系統(tǒng)等4 個不同維度進(jìn)?分析，識別各業(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)梳理的對象?先應(yīng)放在核?主流程上，務(wù)必梳理出業(yè)務(wù)關(guān)鍵環(huán)節(jié)；

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

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

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

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

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

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

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

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

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

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

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

2.1.6 開展測試

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

2.1.7 撰寫報告

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

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

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

3.1.1 商品支付金額篡改

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

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

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

3.1.2 前端JS限制繞過

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

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

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

3.1.3 請求重放測試

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

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

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

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

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

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

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

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

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

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

3.2 密碼找回安全

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

3.2.1 驗證碼客戶端回顯測試

典型場景：

• 任意??登錄

使?驗證碼的場景：

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

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

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

3.2.2 驗證暴力破解

典型案例：

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

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

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

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

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

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

• true

• 1

• ok

• success

• 200

…

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

3.2.4 Session覆蓋

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

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

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

對?站中Session 覆蓋的測試如下：

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

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

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

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

漏洞原因：

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

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

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

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

3.2.6 密碼找回流程繞過測試

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

• ??輸?找回密碼的賬號；

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

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

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

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

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

典型案例：

• metinfo_4.0 任意賬號密碼重置

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

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

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

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

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