邏輯漏洞挖掘
邏輯漏洞
邏輯漏洞是指由於程式邏輯輸入管控不嚴或者邏輯太複雜，導致程式不能夠正常處理或處理錯誤，邏輯漏洞根據功能需求的不同產生的漏洞方式也不同。一般出現在網站程式的登入註冊、密碼找回、驗證方式、資訊檢視、交易支付金額等地方。
這類漏洞不同於常見WEB漏洞，常見WEB漏洞都可以總結為一定的正規化，而邏輯漏洞不行
邏輯漏洞出現的原因也是有很多種，需要有一定個人經驗積累才能在程式碼審計過程中發現此類漏洞
挖掘思路
首先將所有邏輯漏洞的問題分為前端和後端兩個部分，先測試繞過前端規則限制再測試繞過後端規則限制，一般情況下只要能夠突破原有規則限制的都就可以算是漏洞。
挖掘邏輯漏洞總體步驟分為以下三步：
- 明確業務邏輯流程，根據業務需求的特點，有針對性的進行測試。
- 尋找流程中可以被操控的環節，分析可被操控環節中可能產生的邏輯問題。
- 珠寶修改引數觸發邏輯問題，重放包對比結果差異。
業務邏輯漏洞
登入模組
- 暴力破解
- 任意使用者/密碼登陸
- 簡訊/郵箱轟炸
- 驗證碼繞過/爆破/重放/回傳
- 使用者名稱/手機號列舉
- 越權登陸（例如修改封包中使用者ID）
- 賬號許可權繞過（越權）
- Cookie偽造
- 使用者空密碼登陸
註冊模組
- 前端驗證繞過
- 使用者任意/批次註冊
- 惡意驗證註冊賬戶
- 賬戶重複註冊
- 使用者名稱/繫結手機號列舉
- 註冊資訊插入XSS
- 簡訊/郵箱轟炸
- 驗證碼繞過/爆破/重放/回傳
- 其他驗證機制繞過
密碼找回
- 任意/批次使用者密碼重置
- 任意郵箱/手機號驗證（驗證碼與繫結使用者未統一驗證）
- 使用者繫結手機號列舉
- 新密碼劫持
- 簡訊驗證碼劫持/繞過/回傳/爆破/重放
- 使用者郵箱劫持/篡改
- 其他驗證機制繞過
購買支付/充值
- 商品金額/數量篡改
- 替換支付模組
- 交易資訊洩露
- 虛假充值金額
- 充值賬戶/金額/數量篡改
- 支付驗證繞過
- 整數溢位，int最大值為2147483647
- 修改本地JS或伺服器端返回的封包中的關鍵值
個人資料
- 手機號/使用者/郵箱列舉
- 修改個人資料插入XSS
- 郵箱/使用者/手機號篡改
- 使用者資訊遍歷/洩露
- 越權修改他人賬戶資料
抽獎/活動
- 任意抽獎
- 盜刷獎品/積分
- 抽獎積分/次數篡改
- 並行抽獎
- 邀請碼XSS（驗證碼URL可能包含使用者名稱，可將使用者名稱修改為XSS程式碼）
代金券/優惠券
- 批次刷取代金券/優惠券
- 更改代金券金額/數量
- 更改優惠券數量
- 並行邏輯漏洞（burp批次獲取優惠劵等）
訂單
- 訂單資訊遍歷/洩露
- 訂單資訊洩露導致使用者資訊洩露
- 越權修改/刪除他人訂單
賬戶
- 賬戶驗證繞過
- 賬戶金額篡改
- 賬戶繫結手機號繞過
- 賬戶第三方賬戶繫結繞過
會員系統
- 使用者越權操作存取
- 個人資料資訊遍歷/洩露
- 修改個人資訊頭像上傳任意檔案
- 如果遇到xlsx/docx，可能存在XXE，上傳惡意檔案盲測
- 修改個人資訊頁面插入XSS
傳輸過程
- POST/Cookie注入
- cookie劫持
- 修改資訊處無session/token導致CSRF
- 明文傳輸賬號密碼
評論模組
- POST注入
- 無session/token導致CSRF
- 評論時插入XSS
- 遍歷使用者ID導致使用者資訊洩露
- 惡意批次刷評論數量
第三方系統
- 第三方系統未授權存取
- 第三方賬戶資訊遍歷
- 第三方賬戶越權存取
- 第三方賬戶資訊洩露
- 第三方應用版本漏洞
驗證碼安全
- 驗證碼引數刪除繞過
- 驗證碼生成規律預測
- 驗證碼影象內容可被工具識別
- 驗證碼長期不失效，進行爆破
- 驗證碼回顯到頁面或者封包中
- 單個驗證碼可多次重複利用
- 簡訊驗證碼與手機號未統一驗證
- 簡訊驗證碼未對單個手機號傳送次數進行限制
- 簡訊驗證碼未做傳送時間限制，導致簡訊轟炸
- 可能存在萬能驗證碼
介面呼叫
-
未授權存取敏感資料介面
-
簡訊api介面洩露被惡意呼叫
-
資料庫介面洩露，導致資料可被惡意操作
邏輯漏洞利用
驗證碼
萬能驗證碼：
程式設計師在開發驗證碼模組時，為了方便呼叫驗證碼驗證功能是否完善，故意設定了幾個萬能的驗證碼作為測試資料。在開發結束後由於程式設計師的疏忽，沒有刪除該測試驗證碼資料從而導致該漏洞的產生。
驗證碼回傳：
通過抓包的方式，可以看到驗證碼內容回顯在了封包中；或者通過檢視網頁原始碼可以看到驗證碼中的內容，導致正確驗證碼可以被直接讀取利用到。
刪除驗證碼繞過：
通過抓包將驗證碼的值刪除或者直接刪除驗證碼引數，然後將修改後的封包進行重放導致驗證碼驗證被繞過。
驗證碼爆破：
此處驗證碼爆破通常是指手機簡訊驗證的方式，由於沒有對輸入同一個驗證碼的次數做限制，並且驗證碼的內容太簡單，例如4位元或者6位的純數位組成。可以通過Burp的Intruder模組對驗證碼內容進行爆破，直到匹配到正確的驗證碼。
驗證碼重放
首先，輸入錯誤的驗證碼，進行抓包重放一次，觀察驗證的返回的封包內容，再用正確的驗證碼再進行抓包重放，對比兩個封包的差異，然後根據這些差異驗證碼是否失效。
然後將正確的驗證碼傳送至Burp的Intruder模進行不斷的重放，比較這些封包是否都是正確驗證碼時返回的一樣內容，如果封包內容一樣說明存在驗證碼重放的漏洞。
驗證碼與手機號未統一匹配
首先用自己的手機收到正確驗證碼，在點選註冊時攔截包將手機號改為其他手機號，如果成功的話就註冊了別人的手機號，這是因為後端僅驗證了驗證碼是否是正確的而沒有驗證驗證碼是否與手機匹配。
簡訊轟炸
嘗試不斷重放傳送驗證碼的封包，檢視手機是否在短時間內收到了多條簡訊，是的話則存在簡訊轟炸漏洞，這是因為後端沒有對傳送手機簡訊做時間/次數限制。
如果後端對簡訊驗證碼做了限制，那麼可以嘗試以下幾種方式進行繞過：
- 刪除修改cookie或者返回值，重放封包
- 遍歷引數傳送封包
- 對引數進行疊加
- 手機號後面加空格(%20)或者前面加其他的比如+86、逗號、分號、字母等
- 請求引數修改大小寫，或者新增請求引數&id=1
- 多介面測試，可能登陸位置做了防護，但密碼找回出沒有防護
- 利用呼叫介面繞過簡訊轟炸限制
- 修改IP繞過簡訊轟炸限制
- 新增重複的手機號引數，重放封包
越權操作
首先用一個賬號登陸系統後，通過抓包修改使用者引數，可以達到檢視或者修改他人賬號的目的，儘量對多介面或者多功能模組進行不斷測試越權操作。同時也要多個賬號登陸，分析對比這些賬號封包中的請求引數差異，通過修改這些存在差異的引數，看看是否能夠達到越權操作的目的。
越權漏洞又分為平行越權，垂直越權和交叉越權。
- 平行越權：許可權型別不變，許可權ID改變
- 垂直越權：許可權ID不變，許可權型別改變
- 交叉越權：即改變ID，也改變許可權
使用者資訊洩露
可能存在使用者個人資訊頁面、密碼找回處以及各種呼叫到使用者資訊資料的地方，通過抓包檢視返回資訊是否載入了一些敏感的資料資訊，比如查詢使用者資訊的時候也將使用者的密碼資料在封包中回顯了；或者在使用者個人資料頁面，通過抓包修改使用者ID引數，可以通過遍歷查詢到其他賬號的使用者資料，導致使用者資訊洩露；
任意使用者密碼重置
通常發生在忘記密碼處，由於系統沒有嚴格匹配使用者忘記密碼時的驗證方式，通過抓包修改使用者引數，導致任意使用者的密碼都能夠被重置。
比如某個忘記密碼功能處採用手機號簡訊驗證的方式來重置使用者密碼，如果該驗證手機號沒有對使用者賬戶進行繫結，那麼就可以通過輸入任意手機號接收簡訊驗證，然後就可以利用該驗證碼重置使用者密碼了。
訂單金額任意修改
很多中小型的購物網站都存在訂單金額任意修改漏洞。在提交訂單的時候抓取封包或者直接修改前端程式碼，然後對訂單的金額任意修改。
經常見到的引數大多為：rmb 、value 、amount 、cash 、fee 、money 等
關於支付的邏輯漏洞這一塊還有很多種思路，比如相同價格增加訂單數量，相同訂單數量減少產品價格，訂單價格設定為負數等等。
未授權存取
有些業務的介面，因為缺少了對使用者的登陸憑證的較驗或者是驗證存在缺陷，導致駭客可以未經授權存取這些敏感資訊甚至是越權操作。
一般容易出現在檔案匯出下載，JSON資料頁面，第三方應用頁面等位置。
常見案例：
- 某電商後臺主頁面，直接在管理員web路徑後面輸入main.php之類的即可進入。
- 某航空公司訂單ID列舉
- 某電子認證中心敏感檔案下載
- 某站越權操作及缺陷，其主要原因是沒對ID引數做cookie驗證導致
實際上還有很多案例，他們都存在一個共同的特性，就是沒有對使用者的登陸憑證進行效驗
介面無限制列舉
有些關鍵性的介面因為沒有做驗證或者其它預防機制，容易遭到列舉攻擊。
常見案例：
- 某電商登陸介面無驗證導致撞庫
- 某招聘網驗證碼無限制列舉
- 某快遞公司優惠券列舉
- 某電商會員卡卡號列舉
- 某超市註冊使用者資訊獲取
cookie/token設計存在缺陷
cookie的效驗值過於簡單。有些web對於cookie的生成過於單一或者簡單，導致駭客可以對cookie的效驗值進行一個列舉。或者通過修改cookie中的某個引數可以登陸其他使用者，即cookie仿冒。
token一般是操作令牌，每個使用者在登入系統時，伺服器會為每個使用者生成token令牌作為操作憑證。如果token設計太過於簡單，那麼可能會被破解；或者token沒有設定過期的時間，使得使用者token不唯一，導致使用者token存在被盜用的風險。
找回密碼存在設計缺陷
auth設計缺陷
經常研究邏輯漏洞的人可能會對以下URL很熟悉
www.xxx.com/resetpassword.php?id=MD5
使用者修改密碼時，郵箱中會收到一個含有auth的連結，在有效期內使用者點選連結，即可進入重置密碼環節。而大部分網站對於auth的生成都是採用rand()函數，那麼這裡就存在一個問題了，Windows環境下rand()最大值為32768，所以這個auth的值是可以被列舉的。
如下面這個程式碼可以對auth的值做一個字典。
$a=0;
for ($a=0;$a<=32768;$a++){
$b=md5($a);
echo "\r\n";
echo $b;
}
然後重置某個賬號，並且對重置連結內的auth進行列舉。
簽約漏洞
- 使用A手機登陸賬號A開啟要測試的業務，點選自動續費，支付時停留在支付介面。
- 使用B手機登陸賬號A開啟要測試的業務，點選自動續費，支付時停留在支付介面。
- 重複多臺手機進行同樣操作
- A手機點選支付進行簽約
- A手機支付成功後，在第三方APP中解除自動續費
- B手機進行支付，支付成功後在第三方APP中解除自動續費
- 全部支付完成後，系統就會為你開通相應的次數，由於提前開啟了支付介面，所以金額都是享受到新使用者首月優惠的金額。
- 最終的效果是，一個
賬戶享受到了多次新使用者首月優惠金額，即證明漏洞的存在。
通常這種漏洞比較容易出現在活動頁面的會員優惠開通，而且要考慮到支付後要比正常購買優惠才算是漏洞。
會員升級
- 使用A手機登陸賬號A，並且開通會員。開通超級會員，進入到升級頁面，進行補齊差價開通。
- 使用B手機登陸賬號A，點選開通超級會員，進入到升級頁面，進行補齊差價開通。
- A手機進行支付，B手機進行支付。伺服器認為你補齊了多個月份的超級會員，然後到賬多次。
- 其實這個和簽約漏洞的原理差不多，繞過了支付後伺服器才去校驗是否可以升級的邏輯。
訂單關閉
- 使用優惠券建立一個訂單，停留在支付介面
- 關閉訂單，返回優惠券
- 使用優惠券再次建立訂單；把第一個未支付的訂單進行支付
- 商品從關閉，重新進入到了代發貨的階段，優惠券卻仍然存在，即證明漏洞存在
支付金額
- 有些業務在支付時會忽略分以後的單位，這時候就導致了存在分單位的金額也可以生成訂單
- 比如0.019=0.02，在支付時使用者端給伺服器傳了0.019元的訂單。而第三方付支通常最小的單位為分
- 這就導致了返回的金額會吧後面的9遮蔽掉，只返回0.01（也有些直接四捨五入變成0.02的）
- 當你支付完0.01後，第三方會通知伺服器支付成功，而伺服器那邊生成的是0.019，可能這個軟體的僑胞最小單位也是分，四捨五入變成了0.02
int整數溢位
注意：在做溢位測試時，有可能導致目標伺服器宕機，需要向授權單位申請授權後才能進行測試。
- int的範圍是-2147483648~2147483647。你可以把它看作是一個迴圈，當超過最大值後就重新從0開始計算
- 比如2147483649=-2147483647。有時候支付裡面沒有負數所以從0開始計算了
- 當支付金額為2147483649時，支付金額就變成了1，即2147483649-2147483648=1
- 支付的時候可以直接吧金額改成這個值，在測試商品時也可以讓總價格為這個數。2147483648/物品單價+1=物品數量
- 以上的做法目的，簡單的來說就是通過整數溢位來修改支付金額或者購買商品數量。
突破時間限制
一些網站中的限時活動設定了活動時間範圍，可以通過抓包嘗試更改時間引數為活動未限定範圍內的。
前端驗證
前端加密、後端解密校驗。比如在使用者登入時，通過抓包發現使用者密碼被加密傳輸了，可以利用一些解密工具進行破解，如：Burp解密或者一些線上解密網站。
暴力破解/撞庫
首先在沒有驗證碼或者驗證碼可以被繞過的情況下，嘗試5次或者10次賬號密碼登陸，檢測目標是否封禁賬戶，如果沒有封禁規則，可以不斷進行爆破。採用賬號密碼爆破，對於一些商城、應用、政府、學校採用撞庫方式判斷是否存在該賬號（需要準備各類字典：手機號撞庫、郵箱撞庫、姓名撞庫）。
密碼找回
- 通過郵箱找回密碼，存取連結重置密碼，輸入新密碼後提交抓包，雖然有token，但是依然可以直接修改使用者ID進而修改他人密碼
- 通過他人手機號找回密碼，抓包，將他人手機號替換為自己的手機號，獲取驗證碼，提交後修改密碼
- 通過自己手機號找回密碼，獲取驗證碼後抓包，將封包中的使用者ID改為他人賬號ID，提交後成功修改他人密碼
- 通過郵箱找回密碼，URL連結中修改使用者ID為他人，郵箱不變，之後通過連結可以將他人賬戶繫結為自己的郵箱，之後通過郵箱找回密碼
任意url跳轉
url跳轉漏洞也叫開發重定向漏洞，可以把使用者重定向到攻擊者自己構造的頁面去，簡單的說就是可以跳轉到任意指定的url。一般出現在驗證跳轉、sso登陸等位置。
伺服器端未對傳入的跳轉url變數進行檢查和控制，可能導致可惡意構造任意一個惡意地址，誘導使用者跳轉到惡意網站。
危害：
- 網站釣魚
- 配合CSRF操作危險請求
- 配合XSS執行JS盜取cookie
- 配合瀏覽器漏洞（CVE-2018-8174）
http://www.xxx.com?url=https://www.baidu.com
替換url引數後能夠跳轉到對應頁面，但是一些網站可能會對url跳轉做限制，可以嘗試繞過bypass
1.利用問號繞過限制,最終跳轉到京東頁面
url=https://www.baidu.com?www.jd.com
2.利用@繞過限制,最終跳轉到京東頁面
url=https://[email protected]
3.利用斜杆反斜槓繞過限制
4.利用#繞過限制
url=https://[email protected]
5.利用子域名繞過
6.利用畸形url繞過
7.利用跳轉IP繞過
支付邏輯漏洞
在支付環節中由於邏輯不嚴謹而產生的漏洞稱為支付漏洞。
測試思路
只要有引數，都可以修改，都有可能出現問題。
通常使用兩個賬號來對比測試，這樣可以更快發現可疑引數
訂單模組
- 下單之後修改商品價格
- 下單之後更改數量設為負數，產生正負邏輯
- 並行購買是否出現邏輯問題
- 商品為0，是否存在購買的可能
- 生成訂單時修改訂單金額
結算模組
- 優惠券重複利用
- 修改結算狀態
- 更改支付API或者支付模式
- 偽造成功結算請求
退貨模組
- 更改貨物狀態
- 更改退貨價格
收貨模組
- 繞過客戶直接確認收貨
邊界值問題
正常的邏輯是使用者購買商品，然後價格累加得到一個總價進行扣款。這個時候就會產生邏輯問題：如果說使用者購買的商品是負數了，那麼計算的總數就是負數。反過來錢給使用者
順序執行缺陷
正常的邏輯是a-b-c-d 迴圈漸進的進行流程操作。這個時候就會產生邏輯問題：可以直接從中繞過某一個過程進入到下一步操作。如果說有一項是支付的操作，那麼也就會產生支付繞過，如果說有一項是驗證機制，就會繞過驗證直接進入下一步。
金額直接傳輸導致篡改
直接對下單的金額進行修改值，這裡可以使用fd或者burp抓包
確定支付之後還可以加入購物車
把商品放入購物車點選下單支付，會跳轉到微信，支付寶等第三方支付平臺。這個時候還可以繼續在購物車中加入商品，支付結束之後，商家發放的商品是現在的購物車裡面的東西。
請求重放
購買成功之後，繼續重放請求，可以讓購買的商品一直增加。購買成功之後，會有一個銀行對商戶網站跳轉的過程，如果反覆進行操作，有機率會導致商品反覆購買和增加，但是不需要付更多的錢。
請求引數干擾
金錢做了簽名認證之後，修改後不通過，但是在裡面仍然會有一個引數對金額產生影響導致問題產生。
訂單替換
訂單替換髮生在支付之後的事件處理，同時向伺服器發起二次支付請求一個多一個少，支付金額少的，然後支付之後進行替換，告知伺服器訂單支付完成，並且過程可以反覆的回放。
欺詐
需要兩個收款人，一個是正常的商家，一個是偽造的商家
單位替換
產生在paypal類似的國際支付的場景。
使用者替換
在支付過程中發生使用者替換現象，首先登陸自己的賬戶，然後取得另外一個人的賬戶名等有效資訊，在業務流程中用對方的使用者名稱替換自己的使用者名稱，用對方的餘額購買完成後，再替換自己的賬戶名，這樣就形成別人的錢買自己的東西
強制攻擊
強制攻擊發生在暴力破解的情況下，如果一個商家運用一個自己的網店，接入第三方支付介面，由於設計上的不當導致商家與第三方支付約定的金鑰Key可以單獨被MD5加密，導致可以使用MD5碰撞技術對金鑰進行破解，攻擊者可以設計簡單的金鑰加密資訊使得MD5加密是可以用MD5碰撞技術進行暴力破解。
祕鑰洩漏
內建支付功能的app為了設計上的方便有可能會把Md5或者是RSA的私鑰洩漏導致攻擊者反編譯apk之後獲取金鑰資訊使得交易資訊可以被篡改。
13.函數修改：apk反編譯之後的函數修改，可能導致商家在最後一步向支付方提交訂單時未驗證資訊的準確性，仍然被篡改。
修復建議
- 生成資料簽名，對使用者金額和訂單簽名
- 敏感引數不要放在url中
- 伺服器端校驗/過濾使用者端提交的引數
- 在伺服器端計算金額的時候，一定要判斷是否為正數
- 支付過程中加一個伺服器生成的key，使用者校驗引數有沒有被篡改
- 用url傳遞相關引數，後端進行數位驗證
- 訂單金額和充值介面返回的資料進行校驗
- 提交訂單時後臺判斷單價是否與資料庫中相符，若不符則返回資料
- 支付時應從伺服器拉取資料，而不是直接讀取使用者端的值