*文章原創作者： [email protected]漏洞盒子安全研究團隊，轉載請註明來自FreeBuf黑客與極客（FreeBuf.COM） 

邏輯漏洞挖掘一直是安全測試中“經久不衰”的話題。相比SQL注入、XSS漏洞等傳統安全漏洞，現在的攻擊者更傾向於利用業務邏輯層的應用安全問題，這類問題往往危害巨大，可能造成了企業的資產損失和名譽受損，並且傳統的安全防禦裝置和措施收效甚微。今天漏洞盒子安全研究團隊就與大家分享Web安全測試中邏輯漏洞的挖掘經驗。

一：訂單金額任意修改

解析

很多中小型的購物網站都存在這個漏洞。在提交訂單的時候抓取資料包或者直接修改前端程式碼，然後對訂單的金額任意修改。

如下圖所示：

經常見到的引數大多為

rmb

value

amount

cash

fee

money

等

關於支付的邏輯漏洞這一塊還有很多種思路，比如相同價格增加訂單數量，相同訂單數量減少產品價格，訂單價格設定為負數等等。

預防思路

1.訂單需要多重效驗，如下圖所演示。

2. 訂單數值較大時需要人工稽核訂單資訊，如下圖所演示。

3. 我只是提到兩個非常簡單的預防思路，第二個甚至還有一些不足之處。這裡需要根據業務環境的不同總結出自己的預防方式，最好諮詢專門的網路安全公司。

二：驗證碼回傳

解析

這個漏洞主要是發生在前端驗證處，並且經常發生的位置在於

賬號密碼找回

賬號註冊

支付訂單等

驗證碼主要傳送途徑

郵箱郵件

手機簡訊

其執行機制如下圖所示：

黑客只需要抓取Response資料包便知道驗證碼是多少。

預防思路

1.response資料內不包含驗證碼，驗證方式主要採取後端驗證，但是缺點是伺服器的運算壓力也會隨之增加。

2.如果要進行前端驗證的話也可以，但是需要進行加密。當然，這個流程圖還有一些安全缺陷，需要根據公司業務的不同而進行更改。

三．未進行登陸憑證驗證

解析

有些業務的介面，因為缺少了對使用者的登陸憑證的效驗或者是驗證存在缺陷，導致黑客可以未經授權訪問這些敏感資訊甚至是越權操作。

常見案例：

1. 某電商後臺主頁面，直接在管理員web路徑後面輸入main.php之類的即可進入。

2. 某航空公司訂單ID列舉

3. 某電子認證中心敏感檔案下載

4.某站越權操作及缺陷，其主要原因是沒對ID引數做cookie驗證導致。

5. 實際上還有很多案例，這裡就不一一例舉了，但是他們都存在一個共同的特性，就是沒有對使用者的登陸憑證進行效驗，如下圖為例。

預防思路

對敏感資料存在的介面和頁面做cookie，ssid，token或者其它驗證，如下圖所示。

四：介面無限制列舉

解析

有些關鍵性的介面因為沒有做驗證或者其它預防機制，容易遭到列舉攻擊。

常見案例：

1. 某電商登陸介面無驗證導致撞庫

2. 某招聘網驗證碼無限制列舉

3. 某快遞公司優惠券列舉

4. 某電商會員卡卡號列舉

5. 某超市註冊使用者資訊獲取

預防思路

1. 在輸入介面設定驗證，如token，驗證碼等。

如果設定驗證碼，最好不要單純的採取一個前端驗證，最好選擇後端驗證。

如果設定token，請確保每個token只能採用一次，並且對token設定時間引數。

2. 註冊介面的介面不要返回太多敏感資訊，以防遭到黑客製作列舉字典。

3. 驗證碼請不要以短數字來甚至，最好是以字母加數字進行組合，並且驗證碼需要設定時間期限。

4. 優惠券，VIP卡號請儘量不要存在規律性和簡短性，並且優惠券最好是以數字加字母進行組合。

5. 以上這是部分個人建議，實際方案需要參考業務的具體情況。

五：cookie設計存在缺陷

解析

這裡需要對其詳細的說一下。我們先一個一個來吧。

1. Cookie的效驗值過於簡單。有些web對於cookie的生成過於單一或者簡單，導致黑客可以對cookie的效驗值進行一個列舉，如下圖所示

根據上圖，我們可以分析出，這家網站對於cookie的效驗只單純的採用了一組數字，並且數值為常量，不會改變，這樣非常容易遭到黑客的列舉。甚至有一些網站做的更簡單，直接以使用者名稱，郵箱號或者使用者ID等來作為cookie的判斷標準。

2. cookie設定存在被盜風險

有很多時候，如果一個使用者的cookie被盜取，就算使用者怎麼修改賬號和密碼，那段cookie一樣有效。詳情可以參考《BlackHat（世界黑帽大會）官方APP出現兩個邏輯漏洞》。

其原理如下：

國內大部分廠商都不會把這個地方當作安全漏洞來處理，他們認為這個漏洞的利用條件是黑客必須要大批量獲取到使用者的cookie。雖然事實如此，但是這個也是一個安全隱患。

3.使用者的cookie資料加密應嚴格使用標準加密演算法，並注意金鑰管理。

有一些廠商為了圖方便，沒有對使用者的cookie做太多的加密工作，僅僅是單純的做一個靜態加密就完事了。我之前就碰到一個，可以為大家還原一下當時的場景。

當時我看到cookie中有個access token引數，看到value後面是兩個等號，習慣性的給丟去base64解碼裡面，發現解出來後是我的使用者名稱。因此只要知道一個人的使用者名稱就可以偽造對方的cookie，登陸他人賬戶。

4.還有多個案例不再做重複說明，大家可以深入研究一下cookie中的邏輯漏洞。但是cookie中的漏洞大多都是屬於一個越權漏洞。越權漏洞又分為平行越權，垂直越權和交叉越權。

平行越權：許可權型別不變，許可權ID改變

垂直越權：許可權ID不變，許可權型別改變

交叉越權：即改變ID，也改變許可權

如下圖所示：

預防思路

1.cookie中設定多個驗證，比如自如APP的cookie中，需要sign和ssid兩個引數配對，才能返回資料。

2.使用者的cookie資料加密應嚴格使用標準加密演算法，並注意金鑰管理。

3.使用者的cookie的生成過程中最好帶入使用者的密碼，一旦密碼改變，cookie的值也會改變。

4.cookie中設定session引數，以防cookie可以長時間生效。

5.還有很多方法，不再一一例舉，請根據業務不同而思考。

六：找回密碼存在設計缺陷

解析

1.auth設計缺陷

經常研究邏輯漏洞的人可能會對以下URL很熟悉

www.xxx.com/resetpassword.php?id=MD5

使用者修改密碼時，郵箱中會收到一個含有auth的連結，在有效期內使用者點選連結，即可進入重置密碼環節。而大部分網站對於auth的生成都是採用rand()函式，那麼這裡就存在一個問題了，Windows環境下rand()最大值為32768，所以這個auth的值是可以被列舉的。

如下面這個程式碼可以對auth的值做一個字典。

然後重置某個賬號，並且對重置連結內的auth進行列舉

整個漏洞的運作的流程圖如下：

2.對response做驗證

這個漏洞經常出現在APP中，其主要原因是對於重置密碼的的驗證是看response資料包，由於之前的案例沒有截圖，只能畫個流程圖給大家演示一下。

3.《密碼找回邏輯漏洞總結》這篇文章很全面的總結了密碼找回漏洞的幾個具體思路和分析，這裡我就不再繼續滾輪子了。

預防思路

1.嚴格使用標準加密演算法，並注意金鑰管理。

2.在重置密碼的連結上請帶入多個安全的驗證引數。

七：單純讀取記憶體值資料來當作使用者憑證

解析

實際上這個應該算作一個軟體的漏洞，但是因為和web伺服器相關，所以也當作WEB的邏輯漏洞來處理了。最能當作例子是《騰訊QQ存在高危漏洞可讀取並下載任意使用者離線檔案（洩漏敏感資訊）》這個漏洞，但是我相信這種奇葩的漏洞不一定只有騰訊才有，只是還沒人去檢測罷了。

產生這個漏洞的主要原因是程式在確定一個使用者的登陸憑證的時候主要是依靠記憶體值中的某個value來進行確認，而不是cookie。但是記憶體值是可以更改和檢視的。其流程圖如下：

預防思路

1. 走伺服器端的資料最好做cookie驗證。

2. 我不反對直接在程序中確定使用者的登陸憑證，但是請對程序進行保護，或者對程序中的value做加密處理。

總結

以上見到的只是幾個比較經典的和常見的邏輯漏洞，這些邏輯漏洞也是程式開發人員和安全檢測人員需要留意的。

如果對邏輯漏洞感興趣的可以檢視以下的擴充套件閱讀：

*文章原創作者： ArthurKiller @漏洞盒子安全研究團隊，轉載請註明來自FreeBuf黑客與極客（FreeBuf.COM）