1、概述
為開發人員安全意識薄弱（只注重實現功能而忽略了在用戶使用過程中個人的行為對Web 應用程序的業務邏輯功能的安全性影響）、開發代碼頻繁迭代導致這些平台業務邏輯層面的安全風險層出不窮
業務邏輯漏洞主要是開發人員業務流程設計的缺陷，不僅局限於網絡層、系統層、代碼層等比如登錄驗證的繞過、交易中的數據篡改、接口的惡意調用（文件上傳就是調用后台的API），都屬於業務邏輯漏洞
2、業務安全測試流程
*測試准備
准備階段主要包括對業務系統的前期的熟悉工作。針對白盒性質的測試，可以結合相關開發文檔去熟悉相關系統業務；針對黑盒測試，可通過實際操作還原業務流程的方式理解業務。
*業務調研
業務調研主要針對業務系統相關負責人進行訪談調研，了解業務系統的整體情況，包括部署情況、功能模塊、業務流程、數據流、業務邏輯以及現有的安全措施等內容。根據以往測試實施經驗，在業務調研前可先設計訪談問卷，訪談有可能會隨着對客戶業務系統具體情況了解的深入而不斷調整、更新問卷（黑盒測試此步驟可忽略）
*業務建模
針對不同行業、不同平台的業務系統，如電商、銀行、金融、證券、保險、游戲、社交、招聘等業務系統，識別出其中的高風險業務場景進行建模。
*業務流程梳理
建模完成后需要對重要業務場景的各個業務模塊逐一進行業務流程梳理，從前台到后台、業務和支撐系統等4個不同的維度進行分析，識別個業務模塊的業務邏輯、業務數據流和功能字段等。
業務模塊的流程梳理主要遵循以下原則：
區分業務主流程和分支流程，業務梳理工作是圍繞主流程進行分析的，而主流程一定是核心業務流程，業務流程重點梳理的對象首先應放在核心主流程上，無比梳理出業務關鍵環節；
概括歸納業務分支流程，業務分支流程往往存在通用點，可將具有業務相似性的分支流程歸納成某一類型的業務流程，無需單獨對其進行測試；
識別業務流程數據信息流，特別是業務數據流在交互雙方之間傳輸的先后順序、路徑等；
識別業務數據流功能字段識別數據流包含的重要程度不等的信息，理解這些字段的含義有助於下階段風險點分析。
3、業務風險點識別
在完成前期不同維度的業務流程梳理工作之后，針對前台業務應着重關注用戶界面操作每一步可能的邏輯風險呵技術風險；針對后台業務應着重關注數據安全、數據流以及處理的日志和審計。
業務風險點識別應主要關注以下安全風險內容:
業務環節存在的安全風險
業務環節存在的安全風險指的是業務使用者可見的業務存在的安全風險，如注冊、登錄和密碼找回等身份認證環節，是否存在完善的驗證碼機制、數據一致性校驗機制、Session和cookie 校驗機制等，是否能規避驗證碼繞過、暴力破解和SQL注入等漏洞。
支持系統存在安全風險
支持系統存在安全風險，如用戶訪問控制機制是否完善，是否存在水平越權或者垂直越權漏洞。系統內加密存儲機制是否完善，業務數據是否明文傳輸。系統使用的業務接口是否可以非授權訪問/調用，是否可以重放、遍歷，接口調用參數是否可篡改等。
業務環節間存在安全風險
業務環節間存在的安全風險，如系統業務流程是否存在亂序，導致某個業務環節可以繞過、回退，或某個業務請求可以無限重放。業務環節間傳輸的數據是否粗壯乃一致性校驗機制，是否村子啊業務數據可被篡改的風險。
支持系統間存在的安全風險
支持系統間存在的安全風險，如系統間數據傳輸是否加密、系統間傳輸的參數是否可篡改。系統間輸入參數的過濾機制是否完善，是否可能導致SQL 注入、XSS跨站腳本和代碼執行漏洞。
業務環節與支持系統間存在的安全風險
業務環節與支持系統間存在的風險，如數據傳輸是否加密、加密方式是否可完善，是否采用前端加密、簡單的md5 編碼等不安全的加密方式。系統處理多線程並發請求的機制是否完善，服務端邏輯與數據庫讀寫是否存在時序問題，導致競爭條件漏洞（qq刷鑽）。系統間輸入參數的過濾機制是否完善。
4、報告
*開展測試
對前期業務流程梳理和識別出的風險點，進行有針對的測試。
*撰寫報告
針對業務安全測試過程中發現的風險結果進行評價和建議，綜合利用場景風險程度和造成的嚴重程度，最終完成測試報告的撰寫
5、業務數據安全
*商品支付金額篡改
電商類網站在業務流程整個環節，需要對業務數據的完整性和一致性進行保護，特別熟確保在用戶客戶端與服務、業務系統接口間的數據傳輸的一致性，通常在訂購類交易流程中，容易出現服務器端未對用戶提交的業務數據進行強校驗，過度信賴客戶端提交的業務數據而導致商品金額篡改漏洞。商品金額篡改測試，通過抓包修改業務流程中的交易金額等字段，例如支付頁面抓取請求中商品的金額字段，修改成任意數額的金額並提交，查看能否以修改后的金額數據完成業務流程。
該項測試主要針對訂單生成的過程中存在商品支付金額校驗不完整而產生的業務安全風險點，通常導致攻擊者用實際支付遠低於訂單支付的金額訂購商品的業務邏輯漏洞。（一分錢買電冰箱）
*前端JS 限制繞過驗證
很多商品在限制用戶購買數量是，服務器僅在頁面通過JS 腳本限制，未在服務器端校驗用戶提交的數量，通過抓取客戶端發送的請求包修改JS 端生成處理的交易數據，如將請求中的商品數量改為大於最大數限制的值，查看能否以非正常業務交易數據完成業務流程。
該項測試主要針對電商平台由於交易限制機制不嚴謹、不完善而導致的一些業務邏輯問題。例如，在促銷活動中限制商品購買數量，卻未對數量進行前、后端嚴格校驗，往往被攻擊者所利用，夠買多個促銷商品，造成商家的損失。
*請求重放的測試
請求重放漏洞是電商平台業務邏輯漏洞中一種常見的有設計缺陷所引發的漏洞，通常情況下所引發的安全問題表現在商品首次購買成功后，參照訂購商品的正常流程請求，進行完全模擬正常訂購業務流程的重放操作，可以實現“一次購買多次收貨”等違背正常業務邏輯的結果
該項測試主要針對電商平台訂購兌換業務流程中的對每筆交易請求的唯一性判斷缺乏有效機制的業務邏輯問題，通過該項測試可以驗證交易流程中隨機數、時間戳等生成機制是否正常。
*業務上限測試
業務上限測試主要針對一些電商類應用程序在進行業務辦理流程中，服務的沒有對用戶提交的查詢范圍、訂單數量、金額等數據進行嚴格校驗而引發的一些業務邏輯漏洞。
通常情況下，在業務流程中通過向服務器端提交高於或低於預期的數據以校驗服務端是否對所提交的數據做預期的強校驗。存在此類脆弱性的應用程序，通常表現為查詢超預期的信息、訂購或兌換超預期范圍的商品等。
該項測試主要判斷應用程序是否對業務預期范圍外的業務請求做出正確的回應
*商品訂購數量篡改
商品數量篡改測是通過在業務流程中抓包修改訂購數商品數量等字段，如將請求中的商品數量修改成任意非預期數額、負數等進行提交，查看業務系統能否以修改后的數量完成業務流程。
該項測試主要針對商品訂購的過程中對異常交易數據處理缺乏風控機制而導致相關業務邏輯漏洞，例如針對訂購中的數量、價格等缺乏判斷而產生的意外的結果，往往被攻擊者利用。
測試過程以damiCMS5.4 網上商城為例。
http://172.16.13.35/dmcms/index.php?s=/articles/127.html
6、密碼找回安全
*驗證碼客戶端回顯測試
找回密碼測試中要注意驗證碼是否回顯在像一只中，有些網站程序會選擇將驗證碼回顯在響應中，來判斷用戶輸入的驗證碼是否和響應的驗證碼一致，如果一致就會通過校驗。
*驗證碼暴力破解
找回密碼功能模塊中通常會將用戶憑證（一般為驗證碼）發送到用戶自己才可以看到的手機號或者郵箱中，只要用戶不泄露自己的驗證碼就不會被攻擊者利用，但是有些應用程序在驗證碼發送功能模塊中驗證碼位數及復雜性較弱，也沒有對驗證碼做次數限制而導致驗證碼可被暴力破解枚舉並修改任意用戶名密碼。
在測試驗證碼是否可以被暴力破解枚舉時，可以先將驗證碼多次發送給自己的賬號，觀察驗證碼是否有規律，如每次接收到的驗證碼為重數字並且是4位數。
*Reponse 狀態值修改測試
Reponse 狀態值修改測試，即修改請求的響應結果來達到密碼重置的目的，存在這種漏洞的網站或者app 往往因為校驗不合格而導致了非常危險的重置密碼操作。
這種漏洞的利用方式通常實在服務器端發送某個密碼重置的憑證請求后，出現特定的響應值，比如true、1、ok、success等，網站看到回顯內容位特定值后即修改密碼，通常這種漏洞的回顯值校驗實在客戶端進行的，所以只需要修改回顯即可。
*Session 覆蓋
找回密碼邏輯漏洞測試種也會遇到參數不可控的情況，比如要修改的用戶名或者綁定的手機號無法提交參數時修改，服務端通過讀取當前session 會話來判斷要修改密碼的賬號，這種情況下能否對Session 中的內容做修改以達到任意密碼重置的目的呢？
在某網站種的找回密碼功能種，業務邏輯是：由用戶使用手機進行注冊然后服務端向手機發送驗證碼短信，用戶輸入驗證碼提交后，進入密碼重置頁面。
對網站中Session 覆蓋的測試如下：
1、需要准備自己的賬號接受憑證（短信驗證碼）；
2、獲得憑證校驗成功后進入密碼重置頁面；
3、在瀏覽器新標簽重新打開找回密碼頁面，輸入目標手機號；
4、此時當前 Session
賬戶已經被覆蓋，重新找回到第二步中打開的重置密碼頁面即可重置目標手機號。
*弱Token 設計缺陷測試
再找回密碼功能中，很多網站回鄉用戶郵箱發送找回密碼頁面鏈接。用戶只需要進入郵箱，打開找回密碼郵箱中的鏈接，就可以進入密碼重置頁面了。找回密碼的鏈接通常會加入校驗參數來確認鏈接是否有效性，通過校驗參數的值與數據庫生成的值是否一致來判斷當前找回密碼的鏈接是否有效。
htttp://www/xxx.com/findpwd?uid=xx-sxx&token=1497515314
*密碼找回流程繞過測試
很多網站密碼找回功能一般由以下幾個步驟。
1、用戶輸入找回密碼的賬號；
2、校驗憑證：向用戶發送短信驗證碼或者找回鏈接，用戶填寫驗證碼或單擊鏈接進入密碼重置頁面，以此方式證明當前操作用戶是賬戶本人；
3、校驗成功進入重置密碼頁面。
再找回密碼邏輯中，第二步憑證最為重要。不是賬戶主人是無法收到校驗憑證的。試想辦法可以繞過第二步憑證校驗，直接進入第三步重置密碼呢?
用戶修改密碼需要向服務器發送修改密碼請求，服務器通過后再修改數據庫中相應的密碼，所以在測試中我們首先要收集三個步驟的請求接口，重點是收集到最后一步重置密碼的接口，這樣我們可以直接跳過憑證校驗的接口嘗試直接重置密碼。
*接口參數賬號修改
找回密碼功能邏輯是常常會在用戶修改密碼接口提交參數中存在傳遞用戶賬號的參數，而用戶賬號參數作為一個可控的變量是可以被篡改的，從而導致修改賬號密碼的憑證或修改的目標賬戶出現偏差，最終造成任意賬號密碼修改漏洞。
通常在找回密碼邏輯中，服務端會要求用戶提供的要修改的賬號，然后給這個賬號發送只有賬號主人才能看到的憑證。比如這個賬號主人綁定的郵箱或者手機號發送驗證碼，或者找回密碼鏈接，這樣可以保證只有賬號主人才可以看到這些憑證。但是如果服務器對賬號的控制邏輯不當，就會導致原有賬號被篡改位其他賬號，服務器端把憑證發送給篡改后的賬戶的郵箱或手機，最終造成可利用憑證重置任意賬號密碼的漏洞。
接口參數賬號修改流程測試為攔截前端請求，通過修改請求內的賬號ID 、名稱或者郵箱、手機號等參數，將修改的數據發送給服務器進行欺騙達到密碼重置的目的。
7、驗證碼相關
1、抓包查看驗證在Cookie里是否存在
2、驗證碼重用-->抓包使用Intruder模塊用正常的賬號驗證-->查看是否通過
查看源碼，查看驗證碼的載入方式-->是否在刷新頁面的時候刷新-->提交數據時驗證碼是否會發生變化-->驗證碼重用