為開發人員安全意識薄弱（只注重實現功能而忽略了在使用者使用過程中個人的行為對web 應用程式的業務邏輯功能的安全性影響）、開發**頻繁迭代導致這些平台業務邏輯層面的安全風險層出不窮業務邏輯漏洞主要是開發人員業務流程設計的缺陷，不僅侷限於網路層、系統層、**層等比如登入驗證的繞過、交易中的資料篡改、介面的惡意呼叫（檔案上傳就是呼叫後台的api），都屬於業務邏輯漏洞
*測試準備準備階段主要包括對業務系統的前期的熟悉工作。針對白盒性質的測試，可以結合相關開發文件去熟悉相關系統業務；針對黑盒測試，可通過實際操作還原業務流程的方式理解業務。
*業務調研
業務調研主要針對業務系統相關負責人進行訪談調研，了解業務系統的整體情況，包括部署情況、功能模組、業務流程、資料流、業務邏輯以及現有的安全措施等內容。根據以往測試實施經驗，在業務調研前可先設計訪談問卷，訪談有可能會隨著對客戶業務系統具體情況了解的深入而不斷調整、更新問卷（黑盒測試此步驟可忽略）
*業務建模
針對不同行業、不同平台的業務系統，如電商、銀行、金融、**、保險、遊戲、社交、招聘等業務系統，識別出其中的高風險業務場景進行建模。
*業務流程梳理
建模完成後需要對重要業務場景的各個業務模組逐一進行業務流程梳理，從前台到後台、業務和支撐系統等4個不同的維度進行分析，識別個業務模組的業務邏輯、業務資料流和功能欄位等。
業務模組的流程梳理主要遵循以下原則：區分業務主流程和分支流程，業務梳理工作是圍繞主流程進行分析的，而主流程一定是核心業務流程，業務流程重點梳理的物件首先應放在核心主流程上，無比梳理出業務關鍵環節；
概括歸納業務分支流程，業務分支流程往往存在通用點，可將具有業務相似性的分支流程歸納成某一型別的業務流程，無需單獨對其進行測試；
識別業務流程資料資訊流，特別是業務資料流在互動雙方之間傳輸的先後順序、路徑等；
識別業務資料流功能字段識別資料流包含的重要程度不等的資訊，理解這些欄位的含義有助於下階段風險點分析。
在完成前期不同維度的業務流程梳理工作之後，針對前台業務應著重關注使用者介面操作每一步可能的邏輯風險呵技術風險；針對後台業務應著重關注資料安全、資料流以及處理的日誌和審計。
業務風險點識別應主要關注以下安全風險內容:業務環節存在的安全風險
業務環節存在的安全風險指的是業務使用者可見的業務存在的安全風險，如註冊、登入和密碼找回等身份認證環節，是否存在完善的驗證碼機制、資料一致性校驗機制、session和cookie 校驗機制等，是否能規避驗證碼繞過、暴力破解和sql注入等漏洞。
支援系統存在安全風險
支援系統存在安全風險，如使用者訪問控制機制是否完善，是否存在水平越權或者垂直越權漏洞。系統內加密儲存機制是否完善，業務資料是否明文傳輸。系統使用的業務介面是否可以非授權訪問/呼叫，是否可以重放、遍歷，介面呼叫引數是否可篡改等。
業務環節間存在安全風險
業務環節間存在的安全風險，如系統業務流程是否存在亂序，導致某個業務環節可以繞過、回退，或某個業務請求可以無限重放。業務環節間傳輸的資料是否粗壯乃一致性校驗機制，是否村子啊業務資料可被篡改的風險。
支援系統間存在的安全風險
支援系統間存在的安全風險，如系統間資料傳輸是否加密、系統間傳輸的引數是否可篡改。系統間輸入引數的過濾機制是否完善，是否可能導致sql 注入、xss跨站指令碼和**執行漏洞。
業務環節與支援系統間存在的安全風險
業務環節與支援系統間存在的風險，如資料傳輸是否加密、加密方式是否可完善，是否採用前端加密、簡單的md5 編碼等不安全的加密方式。系統處理多執行緒併發請求的機制是否完善，服務端邏輯與資料庫讀寫是否存在時序問題，導致競爭條件漏洞（qq刷鑽）。系統間輸入引數的過濾機制是否完善。
*開展測試對前期業務流程梳理和識別出的風險點，進行有針對的測試。
*撰寫報告
針對業務安全測試過程中發現的風險結果進行評價和建議，綜合利用場景風險程度和造成的嚴重程度，最終完成測試報告的撰寫
*商品支付金額篡改電商類**在業務流程整個環節，需要對業務資料的完整性和一致性進行保護，特別熟確保在使用者客戶端與服務、業務系統介面間的資料傳輸的一致性，通常在訂購類交易流程中，容易出現伺服器端未對使用者提交的業務資料進行強校驗，過度信賴客戶端提交的業務資料而導致商品金額篡改漏洞。商品金額篡改測試，通過抓包修改業務流程中的交易金額等字段，例如支付頁面抓取請求中商品的金額字段，修改成任意數額的金額並提交，檢視能否以修改後的金額資料完成業務流程。
該項測試主要針對訂單生成的過程中存在商品支付金額校驗不完整而產生的業務安全風險點，通常導致攻擊者用實際支付遠低於訂單支付的金額訂購商品的業務邏輯漏洞。（一分錢買電冰箱）
*前端js 限制繞過驗證
很多商品在限制使用者購買數量是，伺服器僅在頁面通過js 指令碼限制，未在伺服器端校驗使用者提交的數量，通過抓取客戶端傳送的請求包修改js 端生成處理的交易資料，如將請求中的商品數量改為大於最大數限制的值，檢視能否以非正常業務交易資料完成業務流程。
該項測試主要針對電商平台由於交易限制機制不嚴謹、不完善而導致的一些業務邏輯問題。例如，在**活動中限制商品購買數量，卻未對數量進行前、後端嚴格校驗，往往被攻擊者所利用，夠買多個**商品，造成商家的損失。
*請求重放的測試
請求重放漏洞是電商平台業務邏輯漏洞中一種常見的有設計缺陷所引發的漏洞，通常情況下所引發的安全問題表現在商品首次購買成功後，參照訂購商品的正常流程請求，進行完全模擬正常訂購業務流程的重放操作，可以實現「一次購買多次收貨」等違背正常業務邏輯的結果
該項測試主要針對電商平台訂購兌換業務流程中的對每筆交易請求的唯一性判斷缺乏有效機制的業務邏輯問題，通過該項測試可以驗證交易流程中隨機數、時間戳等生成機制是否正常。
*業務上限測試
業務上限測試主要針對一些電商類應用程式在進行業務辦理流程中，服務的沒有對使用者提交的查詢範圍、訂單數量、金額等資料進行嚴格校驗而引發的一些業務邏輯漏洞。
通常情況下，在業務流程中通過向伺服器端提交高於或低於預期的資料以校驗服務端是否對所提交的資料做預期的強校驗。存在此類脆弱性的應用程式，通常表現為查詢超預期的資訊、訂購或兌換超預期範圍的商品等。
該項測試主要判斷應用程式是否對業務預期範圍外的業務請求做出正確的回應
*商品訂購數量篡改
商品數量篡改測是通過在業務流程中抓包修改訂購數商品數量等字段，如將請求中的商品數量修改成任意非預期數額、負數等進行提交，檢視業務系統能否以修改後的數量完成業務流程。
該項測試主要針對商品訂購的過程中對異常交易資料處理缺乏風控機制而導致相關業務邏輯漏洞，例如針對訂購中的數量、**等缺乏判斷而產生的意外的結果，往往被攻擊者利用。
測試過程以damicms5.4 網上**為例。
1、抓包檢視驗證在cookie裡是否存在2、驗證碼重用-->抓包使用intruder模組用正常的賬號驗證-->檢視是否通過
檢視原始碼，檢視驗證碼的載入方式-->是否在重新整理頁面的時候重新整理-->提交資料時驗證碼是否會發生變化-->驗證碼重用
網路安全筆記
網路安全 為網路正常執行提供技術 管理措施，確保完整性，可用性，保密性。sdn 軟體控制網路。安全等級 安全服務 認證，訪問控制，資料保密性 完整性，不可否認性 安全機制 加密，簽名，訪問控制，資料完整性等。網路屬性可改，網絡卡位址，實際的實體地址不可以改。ids入侵檢測系統，ips入侵防護系統，i...
網路安全學習
小記1.1.1網路安全的目的及保護範圍 網路安全主要包括以下4點 網路安全具體包括如下內容 1.1.2現有的網路攻擊 防禦手段 常用的攻擊手段主要包括5個方面 常用的防禦技術，通常包括以下4個方面 1.1.3網路安全的四大方面 物理安全 防火 防盜 防靜電 防雷擊 防電磁洩露 邏輯安全 計算機的邏輯...
網路安全 筆記1
1.網路安全的含義 是指網路系統的硬體軟體及系統中的資料受到保護，不因偶然的或者惡意的原因遭到破壞更改或洩露，系統連續可靠正常的執行。2.網路安全的五個特徵 1 保密性 2 完整性 3 可用性 4 可控性 5 不可否認性 3.面臨的安全威脅 1 物理威脅 2 傳輸線路威脅 3 身份鑑別威脅 4 系統...