隨著各類前后端框架的成熟和完善，傳統的SQL注入、XSS等常規漏洞在Web系統里逐步減少，而攻擊者更傾向于使用業務邏輯漏洞來進行突破。業務邏輯漏洞，具有攻擊特征少、自動化脆弱性工具無法掃出等特點，也為檢測和軟件的安全性保障帶來了一定的難度。

本文介紹了業務邏輯漏洞的特征并列舉了一些常見的業務邏輯漏洞，同時介紹了如何使用行為分析模型對于業務邏輯漏洞來進行檢測，以及如何使用應用程序威脅建模過程規范軟件開發流程避免在系統里出現業務邏輯漏洞。

一、什么是業務邏輯漏洞

所有Web應用程序都是通過代碼邏輯實現各種功能。即使一個簡單的Web應用程序，都可能包含著數目龐大的邏輯操作。這些邏輯就是一個復雜的攻擊面，但是它卻常常被忽略。許多自動化的掃描工具或者代碼審計工具，都只能掃出類似SQL注入、XSS等常規的漏洞，因為它們相比于業務邏輯漏洞而言具有顯著的攻擊特征。

業務邏輯漏洞產生的最核心原因，就是在編寫程序時，只考慮常規的操作流程，即“當在A情況下，就會出現B，此時執行C即可",但是開發者卻沒有考慮當用戶執行了意料之外的X時會發生什么.這種對于異常情況的欠考慮，最終導致了安全漏洞的產生。

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

在不同的應用中有相同的特征;

與應用程序/業務領域嚴格相關。

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

而第二種類型的缺陷，則是指的業務邏輯漏洞。它是由錯誤的應用程序邏輯造成的。業務邏輯缺陷允許攻擊者通過繞過應用程序的業務來規則來濫用應用程序。這些攻擊被偽裝成語法上有效的Web請求，這些請求帶有惡意意圖來違反預期的應用程序邏輯。

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

二、業務邏輯漏洞實際案例

筆者現總結一下常見的業務邏輯漏洞以及它們產生的原因，并簡單介紹一下當使用這些業務邏輯進行攻擊時可以用什么樣的方式來進行檢測。

2.1 越權訪問

2.1.1 現象

所謂越權訪問，即用戶A訪問到了自己笨沒有權限訪問到的頁面或者接口。

越權又分為水平越權和垂直越權:

水平越權:

即用戶A和用戶B屬于同一個權限組，水平越權就是用戶A可以看到用戶B才可以看到的一些內容。一個簡單的例子，就是保單管理系統中，每個人都只可以看到自己的保單，如果出現用戶A可以查看到用戶B的保單的現象，此時就發生了水平越權。

圖1 紅線處即為水平越權

垂直越權:

即用戶A和用戶B屬于不同的權限組，如用戶A屬于普通用戶權限組，而用戶B屬于管理員權限組，垂直越權就是用戶A可以看到用戶B才可以看到的內容。一個簡單的例子，用戶A可以看到通訊錄界面，用戶B可以看到通訊錄和用戶管理的界面（其中用戶管理界面可以看到用戶密碼）。如果用戶A修改一下請求的URL即可以看到作為管理員才可已看到的全部用戶密碼，此時就發生了垂直越權。

圖2 紅線處即為垂直越權

2.1.2?檢測思路

出現越權訪問漏洞的主要原因，是因為開發人員只是在前端界面進行了簡單的菜單隱藏，而沒有用統一的服務端攔截器/中間件對于全部URL請求進行權限判斷。這樣，攻擊者只需要在瀏覽器或者BurpSuite之類的攻擊工具中，發出對于指定URL的請求，即可以實現對于特定接口的越權訪問。

越權訪問請求，本身是不具有攻擊特征的，如果要進行檢測，需要采取UEBA的檢測思路。

假設對于獨立的用戶A在時間間隔N內的Web訪問行為進行刻畫，即可以得到他慣常訪問的URL合集：

?

圖3 用戶A及用戶A的慣常訪問URL合集

如果將用戶A與他所屬的權限組/不同權限組用戶群體的慣常訪問URL合集進行比對，可以發現有些URL是多個用戶都會訪問的，而有的URL（或者請求中含有的特定的參數）是各個用戶訪問時都存在差異的。這類具有差異性的URL即為敏感URL。

當用戶A訪問了不在慣常訪問URL合集內的URL，且此URL為敏感URL，即可以判定為發生了越權訪問。

?

?

圖4 水平越權和垂直越權的判定

2.2?Cookie提權

2.2.1 現象

由于本身HTTP請求是無狀態的，所以為了可以記錄用戶的登錄狀態，Web站點通常在Cookie中記錄SessionId來實現對于用戶登錄狀態的識別。

但是，有的Web站點的開發者，除了在Cookie里記錄SessionId外，還記錄了該用戶的權限。后續在做用戶的權限判定時，都直接從Cookie里取值判定一個用戶是普通用戶還是管理員。

由于Cookie本身在瀏覽器側是可以手動修改的，這樣攻擊者一旦修改了Cookie里記錄的權限值，即可以將一個普通用戶提權為該Web站點的管理員。

如下，就是一個站點在Cookie里使用websitesuperid判定時普通用戶(值為0)還是管理員(值為1)。這樣，當將該值修改為1后，即可以實現對于登錄用戶的提權，從而看到站點內只有管理員才可以看到的相關菜單:

圖5 修改cookie內的權限字段進行提權

2.2.2 檢測思路

此種攻擊主要是針對Cookie內的參數進行修改，達到提權的目的。與針對Cookie的SQL注入、XSS攻擊不同的是，攻擊者雖然也存在針對Cookie內參數的修改行為，但是所輸入的值卻不存在攻擊特征。

針對Cookie提權攻擊，我們可以基于Cookie參數對于返回內容的影響進行檢測：

1.提取歷史時間段，一個用戶在一個Web站點訪問一個URL的Cookie參數;

2.Cookie參數內值不變的部分為觀察對象;

3.當在歷史時間內為定值的Cookie在實時流量中出現了變化，且影響了返回內容，則表明存在Cookie提權攻擊。

在檢測Cookie參數對于返回內容的影響時，主要是需要檢測返回內容中菜單的變化情況。而一般菜單在頁面開發的過程中，標簽的class屬性都會帶上menu關鍵字，可以基于此關鍵字識別返回的DOM結構里的菜單標簽及其內容，并檢測Cookie參數對于它的影響。

?

圖6 識別DOM結構里的菜單標簽

2.3?驗證碼更新邏輯繞過導致可暴破

2.3.1 現象

為了防止登錄界面被暴力破解，很多Web站點都增加了驗證碼。有很多Web站點的驗證碼刷新邏輯如下:

圖7 存在漏洞的驗證碼刷新邏輯

乍一看，按照上圖所示的驗證碼校驗與刷新邏輯仿佛沒有問題。但其實，攻擊者通過工具或者腳本直接調用紅框里的用戶名密碼校驗接口，就橈骨了驗證碼的校驗和刷新邏輯，即可以對于登錄接口進行暴力破解。在這種場景下，驗證碼雖然在界面存在，但實際并未起到可以防范暴力破解攻擊的效用。

2.3.2?檢測思路

在繞過驗證碼暴力破解登錄界面的攻擊行為中，我們有2種方法進行檢測：

1.檢測登錄接口的暴力破解行為;

2.檢測繞過驗證碼校驗的異常訪問行為.

2.3.2.1 檢測登錄接口的暴力破解行為

檢測登錄接口的暴力破解行為，最核心的就是從Web站點的訪問日志中，識別出哪個URL是登錄接口。

我們可以定義用戶名/密碼參數字典，例如用戶名在HTTP請求中的參數名通常為username,uname,而密碼在HTTP請求中的參數名通常為password,pwd。當一個Web訪問請求的GET參數或者POST參數里包含用戶名/密碼參數字典里的字符串，則認為該接口為登錄接口。

一個源IP（如果攻擊者掛了代理，可以使用X-Forward-For字段里記錄的真實IP代替），在短時間內對于一個站點的登錄接口發出大量的請求，且用戶名/密碼的參數的值在不斷變化，則可以判定為在對于此登錄接口進行暴力破解。

2.3.2.2?檢測繞過驗證碼校驗的異常訪問行為

檢測繞過驗證碼校驗的異常訪問行為，可以基于訪問圖基線進行實現。

通過采集N天的Web訪問日志，我們可以對于一個站點的訪問行為，以及在各個頁面的跳轉關系(referer，uri以及url訪問的先后順序以及時間間隔)繪制出訪問圖基線:

圖8 基于圖基線檢測繞過驗證碼校驗

如圖8所示，在歷史的圖基線中，我們發現通常的訪問順序都是：

驗證碼校驗url -> 登錄校驗url -> 驗證碼刷新url

如果突然出現了在圖基線中并不存在的邊，如圖所示即用戶直接訪問登錄校驗url的行為，則認為屬于發生異常訪問行為。具體到這個例子，即為繞過驗證碼校驗的異常登錄行為。

從上面的幾個例子中可以看出來，基于業務邏輯漏洞的攻擊通常都沒有或者只有較少的攻擊特征。隨著攻擊者手法的豐富多樣化，防守方不能只專注于基于攻擊特征的檢測方式，只有將基于攻擊的檢測方式與基于異常行為的檢測方式結合起來，才能讓自己更好的在未來的安全運營過程中發現威脅。

三、如何避免系統存在業務邏輯漏洞

OWASP在描述業務邏輯漏洞時指出它雖然不如OWASP TOP10中的漏洞那樣常見，但也依舊在許多重要的業務系統中存在。然而業務邏輯漏洞屬于無法自動掃描出的漏洞，我們該如何避免系統中出現業務邏輯漏洞呢？OWASP指出可以使用應用程序威脅建模過程來避免系統中出現業務邏輯漏洞。

圖9 應用程序威脅建模過程

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

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

?

?

圖10 威脅建模的五個關鍵步驟

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

1.定義安全需求;

2.創建應用程序簡圖;

3.確定威脅;

4.緩解威脅;

5.校驗威脅是否被緩解;

?

參考文獻：

【1】《黑客攻防技術寶典Web實戰篇》

【2】《黑客大曝光-Web應用安全》

【3】《What is a Business Logic Flaw Vulnerability》

【4】《OWASP Business Logic Vulnerability》

【5】《How to Prevent Business Flaws Vulnerabilities In Web Applications》

【6】《Microsoft Threat Modeling》

總結

以上是生活随笔為你收集整理的攻防演练中的业务逻辑漏洞及检测思路的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。