業務邏輯漏洞挖掘

一. 前言

隨著各類前后端框架的成熟和完善，傳統的SQL注入、XSS等常規漏洞在Web系統里逐步減少，而攻擊者更傾向于使用業務邏輯漏洞來進行突破。

業務邏輯漏洞，具有攻擊特征少、自動化脆弱性工具無法掃出等特點，也為檢測和軟件的安全性保障帶來了一定的難度。

業務邏輯漏洞簡介：

所有Web應用程序各種功能都是通過代碼邏輯實現。任何Web應用程序，都可能存在大量邏輯操作。這些邏輯就是一個復雜的攻擊面，但是它卻常常被忽略。

許多自動化的掃描工具或者代碼審計工具，都只能掃出類似SQL注入、XSS等常規的漏洞，難以發現邏輯漏洞(攻擊特征不明顯)。

業務邏輯漏洞產生的核心原因：

編程時，只考慮了常規的操作流程（如在A情況下，就會出現B，此時執行C即可）沒有考慮當用戶執行了意料之外的X時會發生什么。這種對于異常情況的欠考慮，最終導致了安全漏洞的產生。

應用中的缺陷通常分為兩種類型：

在不同的應用中有相同的特征：類似SQL注入、XSS之類的常規漏洞。這一類漏洞的產生，主要是因為應用程序依賴用戶的輸入來執行某些重要的功能，但是在用戶輸入了一些非法字符時，應用程序又未能對于這些輸入進行充分的校驗和預處理。

與應用程序/業務領域嚴格相關：是指的業務邏輯漏洞。它是由錯誤的應用程序邏輯造成的。業務邏輯缺陷允許攻擊者通過繞過應用程序的業務規則來濫用應用程序。這些攻擊被偽裝成語法上有效的Web請求，這些請求帶有惡意意圖違反預期的應用程序邏輯。

隨著ORM框架的普及，以及新一代前端框架如AngularJS、Vue等的流行，常規的SQL注入、XSS等漏洞在實際的業務系統中越來越趨于少見。而在攻防演練過程中，可以用于突破系統的漏洞往往集中于在業務邏輯實現層面的漏洞上。

邏輯漏洞主要產生的位置

1.登錄處   2.業務辦理處   3.驗證碼處   4.支付處   5.密碼找回處

登錄處存在的邏輯漏洞

1.可以暴力破解用戶名或密碼：

沒有驗證碼機制，沒有根據用戶名限制失敗次數，沒有根據ip限制失敗次數等等

通常思路：

直接拿密碼字典爆破某一個用戶名

拿固定的弱口令密碼，去跑top xxx的用戶名

如果只是用戶名限制失敗次數，可以使用思路2的方法

在存在返回提示用戶名錯誤或者密碼錯誤的情況下，可以分別爆用戶名和密碼

常見限制：

有時候會發現用戶名或者密碼是密文加密，這時可能是通過前端或者其他方式加密，對于簡單的來說base64編碼和md5的簽名是很好識破的，在爆破的時候可以選擇encode和hash

2.session沒有清空：

登出后服務器端的session內容沒有清除，因此客戶端重新帶回登出前的session，也能夠達到重新登錄

通常思路：

在登錄退出后，拿退出前的session，重新訪問需要登錄的界面

業務辦理處存在的邏輯漏洞

水平越權

通常說的越權一般是修改get或者post參數，導致的查看到他人的業務信息，一般看訂單處，個人信息處等位置的參數

通常思路：

拿2個賬號，修改賬號1的get或post參數給賬號2

篡改手機號

在需要手機號的短信驗證處，抓包修改手機號，可能做到非本賬號手機號獲取能夠編輯本賬號的驗證碼

通常思路：

抓包，查看get或者post參數存在手機號的地方，進行修改

驗證碼處存在的邏輯漏洞

登錄驗證碼未刷新

沒有清空session中的驗證碼信息

通常思路：

1.抓包多次重放，看結果是否會返回驗證碼錯誤，如沒有返回驗證碼錯誤則存在未刷新

2.觀察檢驗的處理業務，如果驗證碼和用戶名密碼是分2次http請求校驗，則也可以爆破用戶名和驗證碼

手機或郵箱驗證碼可爆破

沒有對應的手機號或郵箱，但如果驗證碼純數字4,5位左右，沒有次數校驗，可以爆破

通常思路：

拿自己的手機號或郵箱先獲取驗證碼查看驗證碼格式，之后多次提交錯誤的看是否有次數現在，沒有就爆破

手機或郵箱驗證碼回顯到客戶端

在發送給手機或者郵箱驗證碼時，會在response包中有驗證碼，因此不需要手機和郵箱就可以獲取驗證碼

通常思路：

發送驗證碼時抓包，看返回包

修改response包繞過判定

在輸入錯誤的驗證碼時會返回false之類的字段，如果修改response中的false為true，會識別為驗證通過

通常思路：

抓包，選擇do intercept-> response to this request ,放包，抓到下一個包就是response的包，可以修改，重放

支付處存在的邏輯漏洞

修改商品編號

如果業務是通過商品編號來判斷價格的話，可能存在只修改A商品編號為B商品編號，做到以A商品的價格購買B商品

通常思路：

先準備2個商品的編號，將其中一個改為另一個

條件競爭

通過條件競爭使余額達到負數，從而買多個商品

通常思路：

支付的通道，多線程請求付款確認，結果如果余額為負數，則存在該漏洞

金額修改

金額直接寫在了post或者get請求中，對其進行修改達到修改了商品金額的效果

通常思路：

抓包修改金額的字段

商品數量修改

在購買時，如果一個商品為負數，那么它的價格則會是負數，如果購買多種商品，將其中一個設為負數，降低整體的價格

通常思路：

購物車里選取多個商品，修改其中一個商品的數量，在購買后查看最終的價格

通過前端限制限購商品

有些商品限購1個，但是判定是通過前端，因此可以抓包后修改數量

通常思路：

抓取限購數量內的包，抓取后修改個數，重放

充值中放棄訂單未失效

在充值中選取大額充值訂單，放棄訂單，獲得訂單號，之后充值小額訂單，拿到充值成功的界面，將訂單號修改為放棄的大額訂單，觀察是否成功

通常思路：

看看充值的時候是否有訂單號字段，如果有在成功界面修改為未支付的訂單號，觀察充值是否成功

密碼找回處的邏輯漏洞

驗證碼處的邏輯漏洞在密碼找回處存在一樣適用

修改發送的驗證的目標為攻擊者的郵箱或手機

在找回密碼處，如果字段帶上用戶名，校驗的郵箱或者手機號，將郵箱或者手機號改為自己的，如果自己的能夠收到驗證碼并重置密碼，則該漏洞存在

通常思路：

抓包，注意找回密碼流程中的郵箱號或者手機號字段，修改其為自己即可

session覆蓋

已知A的手機號，不知B的手機號，找回A的密碼，輸入驗證碼后到了設置新密碼設置界面。這時在同一瀏覽器下重開窗口找回B的密碼，獲取驗證碼，刷新A設置新密碼的頁面，如果此時修改的是B賬號的密碼，則存在漏洞

通常思路：

準備2個賬號，測試步驟如上所述

在郵箱收到找回密碼連接時，依然可以使用該思路

弱token爆破

有些時候通過找回密碼的時候填郵箱，郵箱此時會收到一個帶有token的鏈接，點擊鏈接就能跳轉到重置密碼的頁面，如果token是base64，時間戳，位數較低的隨機數則可以爆破

通常思路：

正常找回流程獲取重置密碼的url，了解token的規則后，爆破其他郵箱的重置密碼url

密碼找回流程繞過

在找回密碼處，一般會有三個步驟頁面，頁面1找回用戶的填寫，頁面2找回時的手機號短信驗證碼填寫，頁面3填寫新密碼，如果填好頁面1，直接訪問頁面3能夠重設密碼的話，則會存在該漏洞

通常思路：

在設置好找回用戶后，直接訪問重設密碼的url頁面

避免業務邏輯漏洞

OWASP在描述業務邏輯漏洞時指出它雖然不如OWASP TOP10中的漏洞那樣常見，但也依舊在許多重要的業務系統中存在。然而業務邏輯漏洞屬于無法自動掃描出的漏洞。

OWASP指出可以使用應用程序威脅建模過程來避免系統中出現業務邏輯漏洞。

在系統生命周期里引入威脅建模可以帶來如下方面的好處：

1.進行安全設計

2.更充分的對資源進行調研；更合理的對于安全、開發以及其他任務排定優先級

3.將安全和開發結合到一起，更好的互相理解以及構建系統

4.確定威脅和兼容性的需求，并且評估它們的風險

5.定義和構建需求控制

6.平衡風險、控制和易用性

7.基于可接受的風險，確定哪塊的控制是不需要的

8.文檔化威脅和緩解措施

9.確保業務需求（或目標）在面對惡意參與者、事故或其他影響因素時得到充分保護

10.定義安全測試用例來驗證安全方面的需求

重要的安全步驟如下：

1.每一個應用程序都需要使用事務數據流和訪問控制矩陣來描述業務邏輯

2.在設計業務邏輯時，就將它設計為防止業務邏輯濫用的。使用過程驗證和控制假設應用程序業務邏輯可能被濫用的一些情況。

3.使用應用程序威脅建模來識別業務邏輯中存在設計缺陷的地方。

4.對于OWASP/WASC/SANS-25-CWE中描述的業務邏輯漏洞進行測試

5.對于業務邏輯的濫用建立確定的測試用例

6.分析風險并應用對策來減輕業務邏輯攻擊的可能性和影響

微軟也提供了威脅建模工具以供下載：https://aka.ms/threatmodelingtool

微軟威脅建模的五個關鍵步驟如下：

1.定義安全需求

2.創建應用程序簡圖

3.確定威脅

4.緩解威脅

5.校驗威脅是否被緩解