前言

與傳統類型漏洞相比，邏輯漏洞具有不易發現、不易防護的特點，不像SQL注入、XSS有像WAF那樣現成的防護手段;而且，每個企業的業務邏輯參差不齊，也形成了千奇百怪的邏輯漏洞。下面就和大家分享一下我都是從哪些維度去發現邏輯漏洞的。

一、未授權

形成未授權的原因一般是由于代碼未做登錄驗證或者登錄驗證失效引起，從而使后臺或者帶有敏感信息的頁面直接裸露在公網。

site：在baidu、Google、bing、360等搜索引擎中使用site命令去搜索所要查詢的域名信息，因為此時搜索以“全”為目的，所以不需要加任何搜索條件。

比如想查詢a.com下的未授權，site:a.com即可。一般看搜索結果前十頁。如果遇到被搜索引擎收錄過多的域名，這時就需要加一些條件了，具體可以參考site命令用法。通過site命令，一般會很容易發現某個域名下的后臺地址和直接暴露在公網的敏感信息頁面。

域名爆破：通過爆破發現更多的二級、三級域名，然后導出域名列表通過腳本查看域名banner名稱，或者挨個手工訪問，觀察是否有未授權登錄的后臺。一般大家都使用layer子域名挖掘和subDomainsBrute來進行子域名發現。

端口及banner掃描：端口不容小視，很多運維自作聰明，把后臺或者其它管理系統直接改個非80端口綁定到公網。可以通過namp對域名所在ip段內的服務器進行端口掃描，生成ip+端口列表，然后通過腳本批量獲取http banner。夫子通過這種方法成功發現并進入了各種知名互聯網公司后臺，當然，漏洞都已提交給他們的src了。

域名關聯：目前有很多公司的域名是未做域名隱私保護的，可以通過whois查詢某個域名所有人還擁有哪些域名，然后重復上述步驟。

二、登錄與賬戶

一個業務，如果登錄或者賬戶信息出現漏洞，信息被一些不法分子利用，可能出現類似電信詐騙的現象。

圖形驗證碼：很多后臺/前臺在登錄或注冊時，是沒有圖形驗證碼的。這也就給爆破帶來了便利。讓人更不可思議的是，很多驗證碼只是個擺設，哪怕輸入錯誤的驗證碼也能提交。

短信驗證碼：在app盛行的時代，短信登錄更為便捷，所以在使用過程中也產生了諸多問題。

例如很多app登錄時使用4位純數字作為手機驗證碼。如果用戶基數較大，在某一時間段，會有部分人使用同一個手機驗證碼登錄。如果通過大量撞庫，可能登錄他人賬號;又因為是4位驗證碼，如果單一賬號也沒限制短信登錄重試次數，同時也存在通過爆破4位驗證碼登錄的現象。

賬號登錄回顯與注冊：很多開發者或者產品，為了提升體驗，在設計開發系統登錄功能時會加一些友好的提示信息。比如提示“該用戶不存在”、“該用戶已注冊”，這無疑是一個變相的撞庫漏洞。在撞庫之前，測試者一般都先搜集好精確的用戶名字典，而提示用戶不存在或登錄時不存在的用戶請求返回字節不一樣，都構成了撞庫。

明文密碼登錄：不少應用在登錄時使用了明文密碼登錄，或者使用未加鹽的md5，或者使用了外圍人員不知道的加密方法，這些都是不可靠的。

拿加鹽的md5值作為密碼登錄為例。登錄時，只需在burp這類工具拿出幾個常用密碼加密后的密文，即可實現fuzz。終究的防護辦法還是登錄時加入簽名，簽名一旦被篡改，就無法登錄。

賬號及其它個人信息篡改：通過抓包方式對賬號信息進行攔截，如手機號、uid、郵箱、token，篡改后提交數據包，從而達到登錄別人賬號的目的。一般防護辦法是使用多個參數進行驗證，當滿足所有條件時才驗證通過。

密碼重置：密碼重置也是一個重災區，常見的密碼重置繞過方式有數字驗證碼繞過，比如4位數字，通過爆破進行;有的通過修改返回結果，如把false改成true。還有的可以構造密碼重置鏈接。這部分夫子接觸較少，更多姿勢可以參考烏云鏡像案例。

三、越權

越權漏洞是邏輯安全中的重中之重，由于產品、研發追趕項目進度，會在項目開發過程中損耗一些安全屬性。接下來我們看一下比較典型的越權漏洞，這些越權漏洞一旦發生，危害等同于脫褲。

訂單遍歷：訂單遍歷一般發生在三種場景，分別是前臺訂單遍歷、后臺訂單遍歷、前后臺訂單遍歷。

1. 前臺訂單遍歷指的是你在某平臺購物或者下單訂了個外賣，然后在查看訂單時發現訂單id為一串有規律的數字，這時可能通過變換id數字就可以查看他人訂單信息了。

2. 后臺訂單遍歷指的是一些管理后臺，在前端展現的時候，每個用戶只能查看系統分配給自己的一些訂單信息。但是通過burp抓包進行fuzz時，多數都可越權查看其它賬戶下的訂單信息，這就成了一個變相的脫褲。防護策略就是將訂單id加密或者變成一串很大的數字，這樣一來也就無法遍歷。

3. 剛才說了兩種場景，接下來說一下第三種場景。這個姿勢稍微有點淫蕩，我把這個場景稱為前后端訂單遍歷。舉個例子，當我們在某外賣提交訂單時，信息里面會包含一個訂單號，而這個訂單需要一個商家端來接單。商家端接單時可以抓包，然后就可以進行訂單遍歷了。當然，前提是你得有一個商家端。

商家資質遍歷：商家在運營過程中，會向平臺提交一些身份證、營業執照等敏感信息。一些服務端為了方便保存，直接對上傳文件以用戶id或者一串數字保存，這樣一來可能通過改id就可獲取其它商家信息。修復辦法就是將文件名稱進行hash命名。

取消他人訂單、惡意刷評：取消訂單時對訂單號進行攔截篡改，從而達到取消他人訂單的目的;評論時更換評論者id，從而實現惡意刷好評、差評的目的。

四、支付

你想買個紅色的愛瘋7，于是給自己購物賬戶充值了5000軟妹幣，等你下單完畢后，發現賬戶余額變成了10000，這是為什么呢?

金額篡改：在下單時，通過攔截篡改支付額度后提交請求，一般會看到出其不意的效果，如把訂單金額改小、改成負數。造成這一現象的原因是服務器端對金額未做二次校驗。

充值與提現：充值和提現過程中都可能存在漏洞。

1. 充值一般會出現兩種漏洞：

一種是少充多得，比如充值100元時通過篡改金額改成10元，最終充值完畢后賬戶變成了100元，而實際付款卻只有10元;

另一種是繞過活動頁金額限制，比如很多公司做活動強制用戶充值金額不能低于10000，而通過攔截修改金額，可以充值任意金額。

2. 接下來我們再說說提現：

提現一般也是由于服務器端參數校驗不嚴格，會經常存在一些信息泄露、無限提款的漏洞。一般提現時，我們可以通過篡改提現額度、銀行卡號來實現。防護手段是手機號、姓名、銀行卡賬戶、額度四個統一。

數量、商品/優惠id篡改：下單時，通過攔截篡改商品數量、商品id、優惠券等信息。如把數量改為一正一負、如替換優惠券滿減id。

比如你有2張優惠券，一張id為1的優惠券滿100減10塊，一張id為2的優惠券滿200減20。這時你買了100塊錢的物品，勾選了滿100減10塊的優惠券，提交請求時把優惠卷id1篡改成了2，結果只支付了80塊錢。

支付上的漏洞遠不止這些。如果想深挖，可以嘗試實現多個組合，通過頻繁組合與篡改，觀察效果。

五、API

現在是app盛行的時代，客戶端使用API與服務器端進行數據傳輸，所以API安全問題頻出，接下來說一下API常見的安全問題。

參數校驗：舉個例子，你在某個app內充值話費，返回查看訂單時url參數包含了手機號、銀行卡、充值金額，你通過改變手機號，獲取到了其它用戶的充值信息(銀行卡號、金額)。這樣你便獲取了一一對應的手機號和銀行卡，是不是很恐怖呢?其實這也是典型的平行越權。

短信郵箱炸彈：短信和郵箱經常出現的漏洞分為兩種。一種是無任何頻率限制，利用者可以無限制對目標手機號或者郵箱發送垃圾短信/郵件;另一種是對短信/郵件內容實現篡改。

關鍵參數不加密：如同上面說的訂單號、銀行卡號、身份證等敏感信息，這類數據要進行hash，從而減少被直接明文越權/遍歷的風險。

分享了這么多，說說這兩年從接觸安全到能發現邏輯漏洞的一些心得。

1. 有棗沒棗先打三竿：上來先動手跑幾十萬數據試試，畢竟光看是看不出安全漏洞細節的。

2. 觀察每一個參數：邏輯問題重要的是測業務邏輯，所以每條http請求都不能放過，每個參數也要盡可能知道是干啥的，看看能不能改變某個參數引起異常返回結果。

3. 大膽假設：不要以為互聯網巨頭沒安全漏洞，往往是比小公司安全問題更多。只有想不到，沒有做不到。

4. 時間投入：一些漏洞，真不是1-2天能發現的，很多時候需要耗時幾天甚至更久，需要分析業務請求才能發現，所以要頭腦冷靜急不得。