天天看點

Web安全測試中常見邏輯漏洞解析(實戰篇)

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

一、訂單金額任意修改

解析

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

如下圖所示:

Web安全測試中常見邏輯漏洞解析(實戰篇)
Web安全測試中常見邏輯漏洞解析(實戰篇)

經常見到的參數大多為

rmb

value

amount

cash

fee

money

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

預防思路

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

Web安全測試中常見邏輯漏洞解析(實戰篇)

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

Web安全測試中常見邏輯漏洞解析(實戰篇)

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

二、驗證碼回傳

這個漏洞主要是發生在前端驗證處,并且經常發生的位置在于

賬号密碼找回

賬号注冊

支付訂單等

驗證碼主要發送途徑

郵箱郵件

手機短信

其運作機制如下圖所示:

Web安全測試中常見邏輯漏洞解析(實戰篇)

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

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

Web安全測試中常見邏輯漏洞解析(實戰篇)

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

Web安全測試中常見邏輯漏洞解析(實戰篇)

三、未進行登陸憑證驗證

有些業務的接口,因為缺少了對使用者的登陸憑證的效驗或者是驗證存在缺陷,導緻黑客可以未經授權通路這些敏感資訊甚至是越權操作。

常見案例:

1. 某電商背景首頁面,直接在管理者web路徑後面輸入main.php之類的即可進入。

Web安全測試中常見邏輯漏洞解析(實戰篇)

2. 某航空公司訂單id枚舉

Web安全測試中常見邏輯漏洞解析(實戰篇)

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

Web安全測試中常見邏輯漏洞解析(實戰篇)

4.某站越權操作及缺陷,其主要原因是沒對id參數做cookie驗證導緻。

Web安全測試中常見邏輯漏洞解析(實戰篇)

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

Web安全測試中常見邏輯漏洞解析(實戰篇)

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

Web安全測試中常見邏輯漏洞解析(實戰篇)

四、接口無限制枚舉

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

1. 某電商登陸接口無驗證導緻撞庫

Web安全測試中常見邏輯漏洞解析(實戰篇)

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

Web安全測試中常見邏輯漏洞解析(實戰篇)

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

Web安全測試中常見邏輯漏洞解析(實戰篇)

4. 某電商會員卡卡号枚舉

Web安全測試中常見邏輯漏洞解析(實戰篇)

5. 某超市注冊使用者資訊擷取

Web安全測試中常見邏輯漏洞解析(實戰篇)

1. 在輸入接口設定驗證,如token,驗證碼等。

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

如果設定token,請確定每個token隻能采用一次,并且對token設定時間參數。

2. 注冊界面的接口不要傳回太多敏感資訊,以防遭到黑客制作枚舉字典。

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

4. 優惠券,vip卡号請盡量不要存在規律性和簡短性,并且優惠券最好是以數字加字母進行組合。

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

五、cookie設計存在缺陷

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

cookie的效驗值過于簡單。有些web對于cookie的生成過于單一或者簡單,導緻黑客可以對cookie的效驗值進行一個枚舉,如下圖所示

Web安全測試中常見邏輯漏洞解析(實戰篇)

根據上圖,我們可以分析出,這家網站對于cookie的效驗隻單純的采用了一組數字,并且數值為常量,不會改變,這樣非常容易遭到黑客的枚舉。甚至有一些網站做的更簡單,直接以使用者名,郵箱号或者使用者id等來作為cookie的判斷标準。

2. cookie設定存在被盜風險

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

其原理如下:

Web安全測試中常見邏輯漏洞解析(實戰篇)

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

3.使用者的cookie資料加密應嚴格使用标準加密算法,并注意密鑰管理。

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

Web安全測試中常見邏輯漏洞解析(實戰篇)

當時我看到cookie中有個access token參數,看到value後面是兩個等号,習慣性的給丢去base64解碼裡面,發現解出來後是我的使用者名。是以隻要知道一個人的使用者名就可以僞造對方的cookie,登陸他人賬戶。

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

平行越權:權限類型不變,權限id改變

垂直越權:權限id不變,權限類型改變

交叉越權:即改變id,也改變權限

Web安全測試中常見邏輯漏洞解析(實戰篇)

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的值做一個字典。

Web安全測試中常見邏輯漏洞解析(實戰篇)

然後重置某個賬号,并且對重置連結内的auth進行枚舉。

Web安全測試中常見邏輯漏洞解析(實戰篇)

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

Web安全測試中常見邏輯漏洞解析(實戰篇)

2.對response做驗證

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

Web安全測試中常見邏輯漏洞解析(實戰篇)

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

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

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

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

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

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

Web安全測試中常見邏輯漏洞解析(實戰篇)

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

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

總結

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

作者:漏洞盒子

來源:51cto

繼續閱讀