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

一、訂單金額任意修改

解析

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

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

預(yù)防思路

1.訂單需要多重效驗(yàn)，如下圖所演示。

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

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

二、驗(yàn)證碼回傳

解析

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

· 賬號(hào)密碼找回

· 賬號(hào)注冊(cè)

· 支付訂單等

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

· 郵箱郵件

· 手機(jī)短信

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

預(yù)防思路

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

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

三、未進(jìn)行登陸憑證驗(yàn)證

解析

有些業(yè)務(wù)的接口，因?yàn)槿鄙倭藢?duì)用戶的登陸憑證的效驗(yàn)或者是驗(yàn)證存在缺陷，導(dǎo)致黑客可以未經(jīng)授權(quán)訪問(wèn)這些敏感信息甚至是越權(quán)操作。

預(yù)防思路

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

四、接口無(wú)限制枚舉

解析

有些關(guān)鍵性的接口因?yàn)闆](méi)有做驗(yàn)證或者其它預(yù)防機(jī)制，容易遭到枚舉攻擊。

預(yù)防思路

1. 在輸入接口設(shè)置驗(yàn)證，如token，驗(yàn)證碼等。

· 如果設(shè)定驗(yàn)證碼，最好不要單純的采取一個(gè)前端驗(yàn)證，最好選擇后端驗(yàn)證。

· 如果設(shè)定token，請(qǐng)確保每個(gè)token只能采用一次，并且對(duì)token設(shè)定時(shí)間參數(shù)。

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

3. 驗(yàn)證碼請(qǐng)不要以短數(shù)字來(lái)甚至，最好是以字母加數(shù)字進(jìn)行組合，并且驗(yàn)證碼需要設(shè)定時(shí)間期限。

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

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

五、cookie設(shè)計(jì)存在缺陷

解析

Cookie的效驗(yàn)值過(guò)于簡(jiǎn)單。有些web對(duì)于cookie的生成過(guò)于單一或者簡(jiǎn)單，導(dǎo)致黑客可以對(duì)cookie的效驗(yàn)值進(jìn)行一個(gè)枚舉

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

2. cookie設(shè)置存在被盜風(fēng)險(xiǎn)

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

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

3.用戶的cookie數(shù)據(jù)加密應(yīng)嚴(yán)格使用標(biāo)準(zhǔn)加密算法，并注意密鑰管理。

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

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

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

· 平行越權(quán)：權(quán)限類型不變，權(quán)限ID改變

· 垂直越權(quán)：權(quán)限ID不變，權(quán)限類型改變

· 交叉越權(quán)：即改變ID，也改變權(quán)限 

預(yù)防思路

1.cookie中設(shè)定多個(gè)驗(yàn)證，比如自如APP的cookie中，需要sign和ssid兩個(gè)參數(shù)配對(duì)，才能返回?cái)?shù)據(jù)。

2.用戶的cookie數(shù)據(jù)加密應(yīng)嚴(yán)格使用標(biāo)準(zhǔn)加密算法，并注意密鑰管理。

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

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

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

六、找回密碼存在設(shè)計(jì)缺陷

解析

1.auth設(shè)計(jì)缺陷

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

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

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

2.對(duì)response做驗(yàn)證

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

預(yù)防思路

1.嚴(yán)格使用標(biāo)準(zhǔn)加密算法，并注意密鑰管理。

2.在重置密碼的鏈接上請(qǐng)帶入多個(gè)安全的驗(yàn)證參數(shù)。

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

解析

實(shí)際上這個(gè)應(yīng)該算作一個(gè)軟件的漏洞，但是因?yàn)楹蛍eb服務(wù)器相關(guān)，所以也當(dāng)作WEB的邏輯漏洞來(lái)處理了。

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

預(yù)防思路

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

2. 高老師表示自己不反對(duì)直接在進(jìn)程中確定用戶的登陸憑證，但是認(rèn)為應(yīng)該對(duì)進(jìn)程進(jìn)行保護(hù)，或者對(duì)進(jìn)程中的value做加密處理。