【CyberSecurityLearning 65】业务安全+业务逻辑漏洞实战
目錄
業務安全
* 業務安全概述
* 黑客攻擊的目標
業務安全測試流程
* 測試準備
* 業務調研
* 業務建模
* 業務流程梳理
* 業務風險點識別
* 開展測試
* 撰寫報告
萬能用戶名|密碼
業務數據安全
* 商品支付金額篡改
* 前端JS 限制繞過驗證
* 請求重放測試
* 業務上限測試
* 商品訂購數量篡改
密碼找回安全
* 驗證碼客戶端回顯測試
* 驗證碼暴力破解
* Response 狀態值修改測試
* Session 覆蓋
* 弱Token 設計缺陷測試
* 密碼找回流程繞過測試
* 接口參數賬號修改
實驗
1、登錄用戶爆破
2、用戶登錄密碼爆破
業務安全
* 業務安全概述
??? 近年來，隨著信息化技術的迅速發展和全球一體化進程的不斷加快，計算機和網絡已經成為與所有人都息息相關的工具和媒介，個人的工作、生活和娛樂，企業的管理，乃至國家的發展和改革都無處其外。信息和互聯網帶來的不僅僅是便利和高效，大量隱私、敏感和高價值的信息數據和資產，成為惡意攻擊者攻擊和威脅的主要目標，從早期以極客為核心的黑客黃金時代，到現在利益鏈驅動的龐大黑色產業，網絡安全已經成為任何個人、企業、組織和國家所必須面臨的重要問題。“網絡安全和信息化是事關國家安全和國家發展、事關廣大人民群眾工作生活的重大戰略問題，沒有網絡安全就沒有國家安全，沒有信息化就沒有現代化。”
??? 隨著互聯網+ 的發展，經濟形態不斷地發生演變。眾多傳統行業逐步地融入互聯網并利用信息通信技術以及互聯網平臺進行著頻繁的商務活動，這些平臺（如銀行、保險、證券、電商、P2P、O2O、游戲、社交、招聘、航空等）由于涉及大量的金錢、個人信息、交易等重要隱私數據，成為了黑客攻擊的首要目標，而因為開發人員安全意識淡薄（只注重實現功能而忽略了在用戶使用過程中個人的行為對Web 應用程序的業務邏輯功能的安全性影響）、開發代碼頻繁迭代導致這些平臺業務邏輯層面的安全風險層出不窮（業務邏輯漏洞主要是開發人員業務流程設計的缺陷，不僅限于網絡層、系統層、代碼層等。比如登錄驗證的繞過、交易中的數據篡改、接口的惡意調用等，都屬于業務邏輯漏洞）。
* 黑客攻擊的目標
?? 一方面隨著社會和科技的發展，購物、社交、P2P、O2O、游戲、招聘等業務紛紛具備了在線支付功能。如電商支付系統保存了用戶手機號、姓名、家庭住址，包括支付的銀行卡信息、支付密碼信息等，這些都是黑客感興趣的敏感信息。攻擊者可以利用程序員的設計缺陷進行交易數據篡改、敏感信息盜取、資產的竊取等操作。現在的黑客不在以炫耀技能為主要攻擊目的，而主要以經濟利益為目的，攻擊的目的逐漸轉變為趨利化。
??? 另一方面，如今的業務系統對于傳統安全漏洞防護的技術和設備越來越成熟，基于傳統漏洞入侵也變得越來越困難，增加了黑客攻擊的成本。而業務邏輯漏洞可以逃逸各種安全防護，迄今為止沒有很好的解決辦法。也是為什么黑客偏好使用業務邏輯漏洞攻擊的一個原因。
業務安全測試流程
* 測試準備
??? 準備階段主要包括對業務系統的前期熟悉工作。針對白盒性質的測試，可以結合相關開發文檔去熟悉相關系統業務；針對黑盒測試，可通過實際操作還原業務流程的方式理解業務。
* 業務調研
??? 業務調研階段主要針對業務系統相關負責人進行訪談調研，了解業務系統的整體情況，包括部署情況、功能模塊、業務流程、數據流、業務邏輯以及現有的安全措施等內容。根據以往測試實施經驗，在業務調研前可先設計訪談問卷，訪談后可能會隨著對客戶業務系統具體情況了解的深入而不斷調整、更新問卷（黑盒測試此步驟可忽略）。
* 業務建模
??? 針對不同行業、不同平臺的業務系統，如電商、銀行、金融、證券、保險、游戲、社交、招聘等業務系統，識別出其中的高風險業務場景進行建模。
* 業務流程梳理
??? 建模完成后需要對重要業務場景的各個業務模塊逐一進行業務流程梳理，從前臺和后臺、業務和支撐系統等4個不同維度進行分析，識別各業務模塊的業務邏輯、業務數據流和功能字段等。
??? 業務模塊的流程梳理主要遵循以下原則：
??? · 區分業務主流程和分支流程，業務梳理工作是圍繞主流程進行分析的，而主流程一定是核心業務流程，業務流程重點梳理的對象首先應放在核心主流程上，務必梳理出業務關鍵環節；
??? · 概括歸納業務分支流程，業務分支流程往往存在通用點，可將具有業務相似性的分支流程歸納成某一類型的業務流程，無須單獨對其進行測試；
??? · 識別業務流程數據信息流，特別是業務數據流在交互方雙方之間傳輸的先后順序、路徑等；
??? · 識別業務數據流功能字段，識別數據流中包含的重要程度不等的信息，理解這些字段的含義有助于下階段風險點分析。
??? 通過業務流程的各個階段梳理出業務流程各個關鍵環節點。
* 業務風險點識別
??? 在完成前期不同維度的業務流程梳理工作后，針對前臺業務應著重關注用戶界面操作每一步可能的邏輯風險和技術風險；針對后臺業務應著重關注數據安全、數據流轉以及處理的日志和審計。
??? 業務風險點識別應主要關注以下安全風險內容。
??? （1）業務環節存在的安全風險
??? 業務環節存在的安全風險指的是業務使用者可見的業務存在的安全風險，如注冊、登錄和密碼找回等身份認證環節，是否存在完善的驗證碼機制、數據一致性校驗機制、Session 和 Cookie 校驗機制等，是否能規避驗證碼繞過、暴利破解和SQL注入等漏洞。
??? （2）支持系統存在的安全風險
??? 支持系統存在的安全風險，如用戶訪問控制機制是否完善，是否存在水平越權或垂直越權漏洞。系統內加密存儲機制是否完善，業務數據是否明文傳輸。系統使用的業務接口是否可以未授權訪問/調用，是否可以調用重放、遍歷，接口調用參數是否可篡改等。
??? （3）業務環節間存在的安全風險
??? 業務環節間存在的安全風險，如系統業務流程是否存在亂序，導致某個業務環節可繞過、回退，或某個業務請求可以無限重放。業務環節間傳輸的數據是否有一致性校驗機制，是否存在業務數據可被篡改的風險。
??? （4）支持系統間存在的安全風險
??? 支持系統間存在的安全風險，如系統間數據傳輸是否加密、系統間傳輸的參數是否可篡改。系統間輸入參數的過濾機制是否完善，是否可能導致SQL 注入、XSS跨站腳本和代碼執行漏洞。
??? （5）業務環節與支持系統間存在的安全風險
??? 業務環節與支持系統間存在的風險，如數據傳輸是否加密、加密方式是否完善，是否采用前端加密、簡單MD5編碼等不安全的加密方式。系統處理多線程并發請求的機制是否完善，服務端邏輯與數據庫讀寫是否存在時序問題（QQ刷鉆），導致競爭條件漏洞。系統間輸入參數的過濾機制是否完善。
* 開展測試
??? 對前期業務流程梳理和識別出的風險點，進行有針對性的測試。
* 撰寫報告
??? 針對業務安全測試過程中發現的風險結果進行評價和建議，綜合評價利用場景的風險程度和造成影響的嚴重程度，最終完成測試報告的編寫。
?
萬能用戶名|密碼
萬能用戶名：
ajest' or 1=1 #???????? /密碼隨意
ajest' or '1'='1???????? /密碼隨意??? or 1=1恒為真
admin' or '1'='1?
ajest'#/?? ??? ??? ??? ????? ????（X）
萬能密碼：
ppp/123' or 1=1 #
admin/123' or '1'='1
業務數據安全
* 商品支付金額篡改
一分錢買電冰箱
??? 電商類網站在業務流程整個環節，需要對業務數據的完整性和一致性進行保護，特別是確保在用戶客戶端與服務、業務系統接口之間的數據傳輸的一致性，通常在訂購類交易流程中，容易出現服務器端未對用戶提交的業務數據進行強制校驗，過度信賴客戶端提交的業務數據而導致的商品金額篡改漏洞。商品金額篡改測試，通過抓包修改業務流程中的交易金額等字段，例如在支付頁面抓取請求中商品的金額字段，修改成任意數額的金額并提交，查看能否以修改后的金額數據完成業務流程。
??? 該項測試主要針對訂單生成的過程中存在商品支付金額校驗不完整而產生業務安全風險點，通常導致攻擊者用實際支付遠低于訂單支付的金額訂購商品的業務邏輯漏洞。
* 前端JS 限制繞過驗證
??? 很多商品在限制用戶購買數量時，服務器僅在頁面通過JS腳本限制，未在服務器端校驗用戶提交的數量，通過抓取客戶端發送的請求包修改JS端生成處理的交易數據，如將請求中的商品數量改為大于最大數限制的值，查看能否以非正常業務交易數據完成業務流程。
??? 該項測試主要針對電商平臺由于交易限制機制不嚴謹、不完善而導致的一些業務邏輯問題。例如，在促銷活動中限制商品購買數量，卻未對數量進行前、后端嚴格校驗，往往被攻擊者所利用，購買多個促銷商品，造成商家的損失。
* 請求重放測試
??? 請求重放漏洞是電商平臺業務邏輯漏洞中一種常見的由設計缺陷所引發的漏洞，通常情況下所引發的安全問題表現在商品首次購買成功后，參照訂購商品的正常流程請求，進行完全模擬正常訂購業務流程的重放操作，可以實現“一次購買多次收貨”等違背正常業務邏輯的結果。
??? 該項測試主要針對電商平臺訂購兌換業務流程中對每筆交易請求的唯一性判斷缺乏有效機制的業務邏輯問題，通過該項測試可以驗證交易流程中隨機數、時間戳等生成機制是否正常。
* 業務上限測試
??? 業務上限測試主要是針對一些電商類應用程序在進行業務辦理流程中，服務端沒有對 用戶提交的查詢范圍、訂單數量、金額等數據進行嚴格校驗而引發的一些業務邏輯漏洞。 通常情況下，在業務流程中通過向服務端提交高于或低于預期的數據以校驗服務端是否對所提交的數據做預期強校驗。存在此類脆弱性的應用程序，通常表現為查詢到超出預期的信息、訂購或兌換超出預期范圍的商品等。
??? 該項測試主要判斷應用程序是否對業務預期范圍外的業務請求做出正確回應。
* 商品訂購數量篡改
??? 商品數量篡改測試是通過在業務流程中抓包修改訂購商品數量等字段，如將請求中的商品數量修改成任意非預期數額、負數等進行提交，查看業務系統能否以修改后的數量完成業務流程。
??? 該項測試主要針對商品訂購的過程中對異常交易數據處理缺乏風控機制而導致相關業務邏輯漏洞，例如針對訂購中的數量、價格等缺乏判斷而產生意外的結果，往往被攻擊者利用。
??? 測試過程以damiCMSV5.4 網上商城為例。
大米cms504源碼下載：http://30tqyb.com/ruanjianxiazai/29184.html#down-mian
實驗演示：我們把源代碼復制到win2008的phpstudy根目錄
先注冊一下
注冊后登錄
點擊立即購買，寫一個訂單：
提交訂單，并用Bp抓包
將數量修改為-1，價格修改為54，提交
價格修改失敗，但是數量修改成功
賬戶余額增加。
密碼找回安全
* 驗證碼客戶端回顯測試
??? 找回密碼測試中要注意驗證碼是否會回顯在響應中，有些網站程序會選擇將驗證碼回顯在響應中，來判斷用戶輸入的驗證碼是否和響應中的驗證碼一致，如果一致就會通過校驗。
* 驗證碼暴力破解
??? 找回密碼功能模塊中通常會將用戶憑證（一般為驗證碼）發送到用戶自己才可以看到的手機號或者郵箱中，只要用戶不泄露自己的驗證碼就不會被攻擊者利用，但是有些應用 程序在驗證碼發送功能模塊中驗證碼位數及復雜性較弱，也沒有對驗證碼做次數限制而導 致驗證碼可被暴力枚舉并修改任意用戶密碼。
??? 在測試驗證碼是否可以被暴力枚舉時，可以先將驗證碼多次發送給自己的賬號，觀察驗證碼是否有規律，如每次接收到的驗證碼為純數字并且是4位數。
* Response 狀態值修改測試
??? Response狀態值修改測試，即修改請求的響應結果來達到密碼重置的目的，存在這種漏洞的網站或者手機App往往因為校驗不嚴格而導致了非常危險的重置密碼操作。
??? 這種漏洞的利用方式通常是在服務端發送某個密碼重置的憑證請求后，出現特定的響應值，比如true、1、ok、success等，網站看到回顯內容為特定值后即修改密碼，通常這種漏洞的回顯值校驗是在客戶端進行的，所以只需要修改回顯即可。
* Session 覆蓋
??? 找回密碼邏輯漏洞測試中也會遇到參數不可控的情況，比如要修改的用戶名或者綁定的手機號無法在提交參數時修改，服務端通過讀取當前session會話來判斷要修改密碼的賬號，這種情況下能否對Session中的內容做修改以達到任意密碼重置的目的呢？
??? 在某網站中的找回密碼功能中，業務邏輯是：由用戶使用手機進行注冊，然后服務端向手機發送驗證碼短信，用戶輸入驗證碼提交后，進入密碼重置頁面。
對網站中Session覆蓋的測試如下：
??? （1）需要準備自己的賬號接收憑證（短信驗證碼）；
??? （2）獲得憑證校驗成功后進入密碼重置頁面；
??? （3）在瀏覽器新標簽重新打開找回密碼頁面，輸入目標手機號；
??? （4）此時當前 Session 賬戶已經被覆蓋，重新回到第二步中打開的重置密碼頁面即可重置目標手機號。
* 弱Token 設計缺陷測試
??? 在找回密碼功能中，很多網站會向用戶郵箱發送找回密碼頁面鏈接。用戶只需要進入郵箱，打開找回密碼郵件中的鏈接，就可以進入密碼重置頁面了。找回密碼的鏈接通常會加入校驗參數來確認鏈接的有效性，通過校驗參數的值與數據庫生成的值是否一致來判斷當前找回密碼的鏈接是否有效。
??? [http://www.xxx.com/findpwd?uid=xx-uu-xx-sxx&token=1497515314]
* 密碼找回流程繞過測試
??? 很多網站的密碼找回功能一般有以下幾個步驟。
??? （1）用戶輸入找回密碼的賬號；
??? （2）校驗憑證：向用戶發送短信驗證碼或者找回密碼鏈接，用戶回填驗證碼或單擊 鏈接進入密碼重置頁面，以此方式證明當前操作用戶是賬號主人；
??? （3）校驗成功進入重置密碼頁面。
??? 在找回密碼邏輯中，第二步校驗憑證最為重要。不是賬號主人是無法收到校驗憑的，試想有沒有辦法可以繞過第二步憑證校驗，直接進入第三步重置密碼呢？
??? 用戶修改密碼需要向服務器發送修改密碼請求，服務器通過后再修改數據庫中相應的密碼，所以在測試中我們首先要收集三個步驟的請求接口，重點是收集到最后一步重置密碼的接口，這樣我們可以直接跳過憑證校驗的接口去嘗試直接重置密碼。?
* 接口參數賬號修改
??? 找回密碼功能邏輯中常常會在用戶修改密碼接口提交參數中存在傳遞用戶賬號的參數，而用戶賬號參數作為一個可控變量是可以被篡改的，從而導致修改賬號密碼的憑證或修改的目標賬號出現偏差，最終造成任意賬號密碼修改的漏洞。
??? 通常在找回密碼邏輯中，服務端會要求用戶提供要修改的賬號，然后給這個賬號發送只有賬號主人才能看到的憑證。比如給這個賬號主人綁定的郵箱或者手機號發送驗證碼，或者找回密碼鏈接，這樣可以保證只有賬號主人才可以看到這些憑證。但是如果服務器對賬號的控制邏輯不當，就會導致原有賬號被篡改為其他賬號，服務器端把憑證發送給篡改后的賬號的郵箱或手機，最終造成可利用憑證重置任意賬號密碼的漏洞。
??? 接口參數賬號修改流程測試為攔截前端請求，通過修改請求內的賬號ID 、名稱或者郵箱、手機號等參數，將修改后的數據發送給服務器進行欺騙達到密碼重置的目的。
??? 以下，我們以metinfov4.0 來例子，來說明這個問題。
實驗
1、登錄用戶爆破
注冊一個賬號
賬密[GGG/123456]
登錄
修改密碼，并用Bp抓包?
密碼:[111111]
提交
使用賬密[GGG/222222]登錄成功，說明我可可以通過修改數據包中的值來達到修改密碼的目的
我們再次來到修改密碼界面，使用Bp 抓包
我們來到管理員登陸界面，使用賬密[admin/222222]成功登錄。
進入后臺
2、用戶登錄密碼爆破
輸入用戶名錯誤的密碼提交，使用Bp 抓包，發送至intruder模塊
將用戶密碼設置為變量
添加密碼字典
爆破成功。
如果驗證碼信息在cookie里面，爆破的時候可以無視驗證碼
總結
以上是生活随笔為你收集整理的【CyberSecurityLearning 65】业务安全+业务逻辑漏洞实战的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 【CyberSecurityLearni
- 下一篇： 作者：李茹姣（1976-），女，博士，中