3.4 邏輯漏洞

邏輯漏洞是指在程序開發過程中，由于對程序處理邏輯未進行嚴密的考慮，導致在到達分支邏輯功能時，不能進行正常的處理或導致某些錯誤，進而產生危害。

一般而言，功能越復雜的應用，權限認證和業務處理流程越復雜，開發人員要考慮的內容會大幅增加，因此對于功能越復雜的應用，開發人員出現疏忽的可能性就越大，當這些出現疏忽的點會造成業務功能的異常執行時，邏輯漏洞便形成了。由于邏輯漏洞實際依托于正常的業務功能存在，因此業務功能的不同直接導致每個邏輯漏洞的利用都不相同，也就無法像SQL注入漏洞總結出一個通用的利用流程或繞過方法，而這對于測試人員在業務邏輯梳理方面便有著更高的要求。

與前面的SQL注入、文件上傳等傳統漏洞不同，如果僅從代碼層面分析，邏輯漏洞通常是難以發現的。因此，傳統的基于“輸入異常數據—得到異常響應”的漏洞掃描器對于邏輯漏洞的發現通常也是無力的。目前，對于邏輯漏洞的挖掘方法仍以手工測試為主，并且由于與業務功能密切相關，也就與測試人員的經驗密切相關。

3.4.1 常見的邏輯漏洞

由于邏輯漏洞實際依托于正常的業務功能存在，無法總結出一個對所有邏輯漏洞行之有效的利用方法，但是對于這些邏輯漏洞而言，導致其發生的原因存在一定共性，憑此可以將這些邏輯漏洞進行一個粗略的分類，歸結為兩種：權限問題、數據問題。

1．與權限相關的邏輯漏洞

我們先了解什么是權限相關的邏輯漏洞。在正常的業務場景中，絕大多數操作需要對應的權限才能進行。而常見的用戶權限如匿名訪客、普通登錄用戶、會員用戶、管理員等，都擁有其各自所特有的權限操作。匿名訪客權限可執行的操作如瀏覽信息、搜索特定內容等，而登錄權限則可以確認訂單支付，會員權限可以提前預約等，這些操作與用戶所擁有的權限息息相關。

當權限的分配、確認、使用這些過程出現了問題，導致某些用戶可執行他本身權限所不支持的特權操作，此時便可稱為發生了與權限相關的邏輯漏洞。

權限邏輯漏洞中常見的分類為未授權訪問、越權訪問、用戶驗證缺陷。

未授權訪問是指用戶在未經過授權過程時，能直接獲取原本需要經過授權才能獲取的文本內容或頁面等信息。其實質是由于在進行部分功能開發時，未添加用戶身份校驗步驟，導致在未授權用戶訪問相應功能時，沒有進行有效的身份校驗，從而瀏覽了他原有權限不支持查看的內容，也就是導致了未授權訪問（見圖3-4-1）。

越權訪問主要為橫向越權和縱向越權。橫向越權漏洞指的是權限同級的用戶之間發生的越權行為，在這個過程中，權限始終限制在同一個級別中，因此被稱為橫向。與之相對，縱向越權漏洞則指在權限不同級的用戶之間發生了越權行為，并且通常是用來描述低級權限用戶向高級權限用戶的越權行為。

假設存在兩個用戶A和B，各自擁有3種行為的權限，見圖3-4-2。

橫向越權即用戶A與用戶B之間的越權，如用戶A可查看用戶B的歷史訂單信息，其中權限變更過程為“普通用戶 → 普通用戶”（見圖3-4-3），本質的權限等級未變化。

縱向越權則會涉及管理員與用戶之間的權限變更，如用戶A通過越權行為可對首頁廣告進行編輯，那么權限變更過程為“普通用戶 → 高級權限用戶”，本質的權限等級發生了變化。

用戶驗證缺陷通常會涉及多個部分，包括登錄體系安全、密碼找回體系、用戶身份認證體系等。通常而言，最終目的都是獲取用戶的相應權限。以登錄體系為例，一個完整的體系中至少包括：用戶名密碼一致校驗，驗證碼防護，Cookie（Session）身份校驗，密碼找回。例如，Cookie（Session）身份校驗，當用戶通過一個配對的用戶名與密碼登錄至業務系統后，會被分配一個Cookie（Session）值，通常表現為唯一的字符串，服務端系統通過Cookie（Session）實現對用戶身份的判斷，見圖3-4-4。

打開瀏覽器的控制臺，通過JavaScript可以查看當前頁面擁有的Cookie，見圖3-4-5。或者在網絡請求部分也可以查看當前頁面Cookie，見圖3-4-6。

Cookie數據以鍵值對的形式展現，修改數值后，對應Cookie鍵的內容便同時被修改。若Cookie中用于驗證身份的鍵值對在傳輸過程中未經過有效保護，則可能被攻擊者篡改，進而服務端將攻擊者識別為正常用戶。假設用于驗證身份的Cookie鍵值對為“auth_priv=guest”，當攻擊者將其修改為“auth_priv=admin”時，服務端會將攻擊者的身份識別為admin用戶，而不是正常的guest，此時便在Cookie驗證身份環節產生了一個Cookie仿冒的邏輯漏洞。

對于Session機制而言，由于Session存儲于服務端，攻擊者利用的角度會發生些許變化。與Cookie校驗不同的是，當使用Session校驗時，用戶打開網頁后便會被分配一個Session ID，通常為由字母和數字組成的字符串。用戶登錄后，對應的Session ID會記錄對應的權限。其驗證流程見圖3-4-7。

Session驗證的關鍵點在于“通過Session ID識別用戶身份”，在該關鍵點上對應存在一個Session會話固定攻擊，其攻擊流程見圖3-4-8。

簡單而言，其攻擊流程如下：攻擊者打開頁面，獲得一個Session ID，我們將其稱為S；攻擊者發送一個鏈接給受害者，使得受害者使用S進行登錄操作，如http://session.demo.com/login.php？sessionId=xxxx；受害者B執行登錄后，S對應的Session ID將包含用戶B的身份識別信息，攻擊者同樣可以通過S獲得受害者B的賬號權限。

2．與數據相關的邏輯漏洞

現實中，對于業務功能交織的購物系統，正常的業務功能會涉及多種場景，如商品余額、金錢花費、商品歸屬判定、訂單修改、代金券的使用等。以其中的購買功能為例，購買過程中會涉及商戶商品余額變化、買方金額的消費、服務端的交易歷史記錄等數據，由于涉及的數據種類較多，因此在實際開發過程中，對于部分數據的類型校驗便存在考慮不周的可能，如花費金額的正負判定、數額是否可更改等問題。這些問題往往都不是由代碼層面的漏洞直接導致，而是由于業務處理邏輯的部分判斷缺失導致的。

與數據相關的邏輯漏洞通常將關注點放在業務數據篡改、重放等方面。

業務數據篡改包含了前文提到的諸多問題，與開發人員對正常業務所做的合法規定密切相關，如限購行為中，對于最大購買量的突破也是作為業務數據篡改來看待。除此之外，在購買場景下常見的幾個業務數據篡改可包括：金額數據篡改，商品數量篡改，限購最大數修改，優惠券ID可篡改。不同場景下，可篡改的數據存在差異，需要針對實際情況具體分析，因此上面4類數據也只是針對購買場景而言。

攻擊者通過篡改業務數據可以修改原定計劃執行的任務，如消費金額的篡改，若某支付鏈接為http://demo.meizj.com/pay.php？money=1000&purchaser=jack&productid=1001&seller=john。其中，各參數含義如下：money代表本次購買所花費的金額，purchaser代表購買者的用戶名，productid代表購買的商品信息，seller代表售賣者用戶名。

若后臺的購買功能是通過這個URL來實現的，那么業務邏輯可以描述為“purchaser花費了money向seller購買了productid商品”。當交易正常完成時，purchaser的余額會扣除money對應的份額，但是當服務端扣費僅依據URL中的money參數時，攻擊者可以輕易篡改money參數來改變自己的實際消費金額。例如，篡改后的URL為http://demo.meizj.com/pay.php？money=1&purchaser=jack&productid=1001&seller=john。此時，攻擊者僅通過1元便完成了購買流程。這本質上是因為后端對于數據的類型、格式沒有進行有效校驗，導致了意外情況的產生。

所以，在筆者看來，數據相關的邏輯漏洞基本均為對數據的校驗存在錯漏所導致。

3.4.2 CTF中的邏輯漏洞

相較于Web安全的其他漏洞，邏輯漏洞通常需要多個業務功能漏洞的組合利用，因此往往存在業務體系復雜的環境中，部署成本頗大，在CTF比賽中出現的頻率較低。

2018年，X-NUCA中有一道名為“blog”的Web題目，實現了一個小型的OAuth 2.0認證系統，選手需要找出其中的漏洞，以登錄管理員賬號，并在登錄后的后臺頁面獲得flag。

OAuth 2.0是一個行業的標準授權協議，目的是為第三方應用頒發具有時效性的Token，使得第三方應用可以通過Token獲取相關資源。常見的場景為需要登錄某網站時，用戶未擁有該網站賬號，但該網站接入了QQ、微信等快捷登錄接口，用戶在進行快捷登錄時使用的便是OAuth 2.0。

OAuth 2.0的認證流程見圖3-4-9，具體為：客戶端頁面向用戶請求授權許可→客戶端頁面獲得用戶授權許可→客戶端頁面向授權服務器（如微信）請求發放Token→授權服務器確認授權有效，發放Token至客戶端頁面→客戶端頁面攜帶Token請求資源服務器→資源服務器驗證Token有效后，返回資源。

這個題目中存在以下功能：普通用戶的注冊登錄功能；OAuth網站的用戶注冊登錄功能；將普通用戶與OAuth網站賬號綁定；發送一個鏈接至管理員，管理員自動訪問，鏈接必須為題目網址開頭；任意地址跳轉漏洞。

在進行普通用戶與OAuth的賬號綁定時，先返回一個Token，隨后頁面攜帶Token進行跳轉，完成OAuth賬號與普通用戶的綁定。攜帶Token進行賬號綁定的鏈接形式為：http://oauth.demo.com/main/oauth/？state=******。訪問鏈接后，將自動完成OAuth賬號與普通賬號的綁定。

此時攻擊點出現了，關鍵在于普通用戶訪問攜帶了Token的鏈接便能完成普通賬號與OAuth賬號的綁定；同理，管理員訪問該鏈接同樣可以完成賬號的綁定。此處可以利用任意地址跳轉漏洞，在遠程服務器上部署一個地址跳轉的頁面，跳轉地址便是攜帶Token進行綁定的鏈接。當管理員訪問提交的鏈接時，先被重定向至遠程服務器，繼續被重定向至綁定頁面，從而完成OAuth賬號與管理員賬號的綁定。至此，使用OAuth賬號快捷登錄，便可登錄管理員賬號。

3.4.3 邏輯漏洞小結

相較于前面提到的各種Web漏洞，邏輯漏洞沒有一種固定的格式來呈現。要進行邏輯漏洞的挖掘，需要參賽者對業務流程做到心中有數。現實環境下的邏輯漏洞挖掘還需要考慮多種認證方式及不同的業務線，這里不再討論，讀者可以在日常工作生活中發現其中的樂趣。