邏輯漏洞挖掘一直是安全測試中“經(jīng)久不衰”的話(huà)題。相比SQL注入、XSS漏洞等傳統安全漏洞，現在的攻擊者更傾向于利用業(yè)務(wù)邏輯層的應用安全問(wèn)題，這類(lèi)問(wèn)題往往危害巨大，可能造成了企業(yè)的資產(chǎn)損失和名譽(yù)受損，并且傳統的安全防御設備和措施收效甚微。今天漏洞盒子安全研究團隊就與大家分享Web安全測試中邏輯漏洞的挖掘經(jīng)驗。
一、訂單金額任意修改
解析
很多中小型的購物網(wǎng)站都存在這個(gè)漏洞。在提交訂單的時(shí)候抓取數據包或者直接修改前端代碼，然后對訂單的金額任意修改。
如下圖所示：
經(jīng)常見(jiàn)到的參數大多為
關(guān)于支付的邏輯漏洞這一塊還有很多種思路，比如相同價(jià)格增加訂單數量，相同訂單數量減少產(chǎn)品價(jià)格，訂單價(jià)格設定為負數等等。
預防思路
1.訂單需要多重效驗，如下圖所演示。
2. 訂單數值較大時(shí)需要人工審核訂單信息，如下圖所演示。
3. 我只是提到兩個(gè)非常簡(jiǎn)單的預防思路，第二個(gè)甚至還有一些不足之處。這里需要根據業(yè)務(wù)環(huán)境的不同總結出自己的預防方式，最好咨詢(xún)專(zhuān)門(mén)的網(wǎng)絡(luò )安全公司。
二、驗證碼回傳
解析
這個(gè)漏洞主要是發(fā)生在前端驗證處，并且經(jīng)常發(fā)生的位置在于
驗證碼主要發(fā)送途徑
其運行機制如下圖所示：
黑客只需要抓取Response數據包便知道驗證碼是多少。
預防思路
1.response數據內不包含驗證碼，驗證方式主要采取后端驗證，但是缺點(diǎn)是服務(wù)器的運算壓力也會(huì )隨之增加。
2.如果要進(jìn)行前端驗證的話(huà)也可以，但是需要進(jìn)行加密。當然，這個(gè)流程圖還有一些安全缺陷，需要根據公司業(yè)務(wù)的不同而進(jìn)行更改。
三、未進(jìn)行登陸憑證驗證
解析
有些業(yè)務(wù)的接口，因為缺少了對用戶(hù)的登陸憑證的效驗或者是驗證存在缺陷，導致黑客可以未經(jīng)授權訪(fǎng)問(wèn)這些敏感信息甚至是越權操作。
常見(jiàn)案例：
1. 某電商后臺主頁(yè)面，直接在管理員web路徑后面輸入main.php之類(lèi)的即可進(jìn)入。
2. 某航空公司訂單ID枚舉
3. 某電子認證中心敏感文件下載
4.某站越權操作及缺陷，其主要原因是沒(méi)對ID參數做cookie驗證導致。
5. 實(shí)際上還有很多案例，這里就不一一例舉了，但是他們都存在一個(gè)共同的特性，就是沒(méi)有對用戶(hù)的登陸憑證進(jìn)行效驗，如下圖為例。
預防思路
對敏感數據存在的接口和頁(yè)面做cookie，ssid，token或者其它驗證，如下圖所示。
四、接口無(wú)限制枚舉
解析
有些關(guān)鍵性的接口因為沒(méi)有做驗證或者其它預防機制，容易遭到枚舉攻擊。
常見(jiàn)案例：
1. 某電商登陸接口無(wú)驗證導致撞庫
2. 某招聘網(wǎng)驗證碼無(wú)限制枚舉
3. 某快遞公司優(yōu)惠券枚舉
4. 某電商會(huì )員卡卡號枚舉
5. 某超市注冊用戶(hù)信息獲取
預防思路
1. 在輸入接口設置驗證，如token，驗證碼等。
2. 注冊界面的接口不要返回太多敏感信息，以防遭到黑客制作枚舉字典。
3. 驗證碼請不要以短數字來(lái)甚至，最好是以字母加數字進(jìn)行組合，并且驗證碼需要設定時(shí)間期限。
4. 優(yōu)惠券，VIP卡號請盡量不要存在規律性和簡(jiǎn)短性，并且優(yōu)惠券最好是以數字加字母進(jìn)行組合。
5. 以上這是部分個(gè)人建議，實(shí)際方案需要參考業(yè)務(wù)的具體情況。
五、cookie設計存在缺陷
解析
這里需要對其詳細的說(shuō)一下。我們先一個(gè)一個(gè)來(lái)吧。
Cookie的效驗值過(guò)于簡(jiǎn)單。有些web對于cookie的生成過(guò)于單一或者簡(jiǎn)單，導致黑客可以對cookie的效驗值進(jìn)行一個(gè)枚舉，如下圖所示
根據上圖，我們可以分析出，這家網(wǎng)站對于cookie的效驗只單純的采用了一組數字，并且數值為常量，不會(huì )改變，這樣非常容易遭到黑客的枚舉。甚至有一些網(wǎng)站做的更簡(jiǎn)單，直接以用戶(hù)名，郵箱號或者用戶(hù)ID等來(lái)作為cookie的判斷標準。
2. cookie設置存在被盜風(fēng)險
有很多時(shí)候，如果一個(gè)用戶(hù)的cookie被盜取，就算用戶(hù)怎么修改賬號和密碼，那段cookie一樣有效。詳情可以參考《BlackHat(世界黑帽大會(huì ))官方APP出現兩個(gè)邏輯漏洞》。
其原理如下：
國內大部分廠(chǎng)商都不會(huì )把這個(gè)地方當作安全漏洞來(lái)處理，他們認為這個(gè)漏洞的利用條件是黑客必須要大批量獲取到用戶(hù)的cookie。雖然事實(shí)如此，但是這個(gè)也是一個(gè)安全隱患。
3.用戶(hù)的cookie數據加密應嚴格使用標準加密算法，并注意密鑰管理。
有一些廠(chǎng)商為了圖方便，沒(méi)有對用戶(hù)的cookie做太多的加密工作，僅僅是單純的做一個(gè)靜態(tài)加密就完事了。我之前就碰到一個(gè)，可以為大家還原一下當時(shí)的場(chǎng)景。
當時(shí)我看到cookie中有個(gè)access token參數，看到value后面是兩個(gè)等號，習慣性的給丟去base64解碼里面，發(fā)現解出來(lái)后是我的用戶(hù)名。因此只要知道一個(gè)人的用戶(hù)名就可以偽造對方的cookie，登陸他人賬戶(hù)。
4.還有多個(gè)案例不再做重復說(shuō)明，大家可以深入研究一下cookie中的邏輯漏洞。但是cookie中的漏洞大多都是屬于一個(gè)越權漏洞。越權漏洞又分為平行越權，垂直越權和交叉越權。
如下圖所示：
預防思路
1.cookie中設定多個(gè)驗證，比如自如APP的cookie中，需要sign和ssid兩個(gè)參數配對，才能返回數據。
2.用戶(hù)的cookie數據加密應嚴格使用標準加密算法，并注意密鑰管理。
3.用戶(hù)的cookie的生成過(guò)程中最好帶入用戶(hù)的密碼，一旦密碼改變，cookie的值也會(huì )改變。
4.cookie中設定session參數，以防cookie可以長(cháng)時(shí)間生效。
5.還有很多方法，不再一一例舉，請根據業(yè)務(wù)不同而思考。
六、找回密碼存在設計缺陷
解析
1.auth設計缺陷
經(jīng)常研究邏輯漏洞的人可能會(huì )對以下URL很熟悉
用戶(hù)修改密碼時(shí)，郵箱中會(huì )收到一個(gè)含有auth的鏈接，在有效期內用戶(hù)點(diǎn)擊鏈接，即可進(jìn)入重置密碼環(huán)節。而大部分網(wǎng)站對于auth的生成都是采用rand()函數，那么這里就存在一個(gè)問(wèn)題了，Windows環(huán)境下rand()最大值為32768，所以這個(gè)auth的值是可以被枚舉的。
如下面這個(gè)代碼可以對auth的值做一個(gè)字典。
然后重置某個(gè)賬號，并且對重置鏈接內的auth進(jìn)行枚舉。
整個(gè)漏洞的運作的流程圖如下：
2.對response做驗證
這個(gè)漏洞經(jīng)常出現在A(yíng)PP中，其主要原因是對于重置密碼的的驗證是看response數據包，由于之前的案例沒(méi)有截圖，只能畫(huà)個(gè)流程圖給大家演示一下。
3.《密碼找回邏輯漏洞總結》這篇文章很全面的總結了密碼找回漏洞的幾個(gè)具體思路和分析，這里我就不再繼續滾輪子了。
預防思路
1.嚴格使用標準加密算法，并注意密鑰管理。
2.在重置密碼的鏈接上請帶入多個(gè)安全的驗證參數。
七、單純讀取內存值數據來(lái)當作用戶(hù)憑證
解析
實(shí)際上這個(gè)應該算作一個(gè)軟件的漏洞，但是因為和web服務(wù)器相關(guān)，所以也當作WEB的邏輯漏洞來(lái)處理了。最能當作例子是《騰訊QQ存在高危漏洞可讀取并下載任意用戶(hù)離線(xiàn)文件(泄漏敏感信息)》這個(gè)漏洞，但是我相信這種奇葩的漏洞不一定只有騰訊才有，只是還沒(méi)人去檢測罷了。
產(chǎn)生這個(gè)漏洞的主要原因是程序在確定一個(gè)用戶(hù)的登陸憑證的時(shí)候主要是依靠?jì)却嬷抵械哪硞€(gè)value來(lái)進(jìn)行確認，而不是cookie。但是內存值是可以更改和查看的。其流程圖如下：
預防思路
1. 走服務(wù)器端的數據最好做cookie驗證。
2. 我不反對直接在進(jìn)程中確定用戶(hù)的登陸憑證，但是請對進(jìn)程進(jìn)行保護，或者對進(jìn)程中的value做加密處理。
總結
以上見(jiàn)到的只是幾個(gè)比較經(jīng)典的和常見(jiàn)的邏輯漏洞，這些邏輯漏洞也是程序開(kāi)發(fā)人員和安全檢測人員需要留意的。
【編輯推薦】
聯(lián)系客服
