邏輯漏洞挖掘一直是安全測試中的常規(guī)性問題中培偉業(yè)安全專家高老師表示，相比SQL注入、XSS漏洞等傳統(tǒng)安全漏洞，現(xiàn)在的攻擊者更傾向于利用業(yè)務邏輯層的應用安全問題，這類問題往往危害巨大，可能造成了企業(yè)的資產(chǎn)損失和名譽受損，并且傳統(tǒng)的安全防御設備和措施收效甚微。高老師在這里分享Web安全測試中邏輯漏洞的挖掘經(jīng)驗。

一、訂單金額任意修改

解析

很多中小型的購物網(wǎng)站都存在這個漏洞。在提交訂單的時候抓取數(shù)據(jù)包或者直接修改前端代碼，然后對訂單的金額任意修改。

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

預防思路

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

2. 訂單數(shù)值較大時需要人工審核訂單信息。

3. 兩個預防思路相對簡單，第二個甚至還有一些不足之處。這里需要根據(jù)業(yè)務環(huán)境的不同總結出自己的預防方式，最好咨詢專門的網(wǎng)絡安全公司。

二、驗證碼回傳

解析

這個漏洞主要是發(fā)生在前端驗證處，并且經(jīng)常發(fā)生的位置在于

· 賬號密碼找回

· 賬號注冊

· 支付訂單等

驗證碼主要發(fā)送途徑

· 郵箱郵件

· 手機短信

黑客只需要抓取Response數(shù)據(jù)包便知道驗證碼是多少。

預防思路

1.response數(shù)據(jù)內(nèi)不包含驗證碼，驗證方式主要采取后端驗證，但是缺點是服務器的運算壓力也會隨之增加。

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

三、未進行登陸憑證驗證

解析

有些業(yè)務的接口，因為缺少了對用戶的登陸憑證的效驗或者是驗證存在缺陷，導致黑客可以未經(jīng)授權訪問這些敏感信息甚至是越權操作。

預防思路

對敏感數(shù)據(jù)存在的接口和頁面做cookie，ssid，token或者其它驗證，如下圖所示。

四、接口無限制枚舉

解析

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

預防思路

1. 在輸入接口設置驗證，如token，驗證碼等。

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

· 如果設定token，請確保每個token只能采用一次，并且對token設定時間參數(shù)。

2. 注冊界面的接口不要返回太多敏感信息，以防遭到黑客制作枚舉字典。

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

4. 優(yōu)惠券，VIP卡號請盡量不要存在規(guī)律性和簡短性，并且優(yōu)惠券最好是以數(shù)字加字母進行組合。

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

五、cookie設計存在缺陷

解析

Cookie的效驗值過于簡單。有些web對于cookie的生成過于單一或者簡單，導致黑客可以對cookie的效驗值進行一個枚舉

一些網(wǎng)站對于cookie的效驗只單純的采用了一組數(shù)字，并且數(shù)值為常量，不會改變，這樣非常容易遭到黑客的枚舉。甚至有一些網(wǎng)站做的更簡單，直接以用戶名，郵箱號或者用戶ID等來作為cookie的判斷標準。

2. cookie設置存在被盜風險

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

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

3.用戶的cookie數(shù)據(jù)加密應嚴格使用標準加密算法，并注意密鑰管理。

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

cookie中有個access token參數(shù)，看到value后面是兩個等號，習慣性的給丟去base64解碼里面，發(fā)現(xiàn)解出來后是我的用戶名。因此只要知道一個人的用戶名就可以偽造對方的cookie，登陸他人賬戶。

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

· 平行越權：權限類型不變，權限ID改變

· 垂直越權：權限ID不變，權限類型改變

· 交叉越權：即改變ID，也改變權限 

預防思路

1.cookie中設定多個驗證，比如自如APP的cookie中，需要sign和ssid兩個參數(shù)配對，才能返回數(shù)據(jù)。

2.用戶的cookie數(shù)據(jù)加密應嚴格使用標準加密算法，并注意密鑰管理。

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

4.cookie中設定session參數(shù)，以防cookie可以長時間生效。

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

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

解析

1.auth設計缺陷

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

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

用戶修改密碼時，郵箱中會收到一個含有auth的鏈接，在有效期內(nèi)用戶點擊鏈接，即可進入重置密碼環(huán)節(jié)。而大部分網(wǎng)站對于auth的生成都是采用rand()函數(shù)，那么這里就存在一個問題了，Windows環(huán)境下rand()最大值為32768，所以這個auth的值是可以被枚舉的。

2.對response做驗證

這個漏洞經(jīng)常出現(xiàn)在APP中，其主要原因是對于重置密碼的的驗證是看response數(shù)據(jù)包。

預防思路

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

2.在重置密碼的鏈接上請帶入多個安全的驗證參數(shù)。

七、單純讀取內(nèi)存值數(shù)據(jù)來當作用戶憑證

解析

實際上這個應該算作一個軟件的漏洞，但是因為和web服務器相關，所以也當作WEB的邏輯漏洞來處理了。

產(chǎn)生這個漏洞的主要原因是程序在確定一個用戶的登陸憑證的時候主要是依靠內(nèi)存值中的某個value來進行確認，而不是cookie。但是內(nèi)存值是可以更改和查看的。

預防思路

1. 走服務器端的數(shù)據(jù)最好做cookie驗證。

2. 高老師表示自己不反對直接在進程中確定用戶的登陸憑證，但是認為應該對進程進行保護，或者對進程中的value做加密處理。