關于 Web 風險點原理與利用：6. 邏輯風險點

一、分類：

1.1 越權訪問

**越權訪問（Authorization Bypass）**是指：攻擊者繞過了權限控制機制，訪問或操作了非其權限范圍內的資源或功能。

換句話說，系統該攔你沒攔，你就越權成功了。

1.1.1?越權訪問的分類

1）水平越權（Horizontal Privilege Escalation）

定義：攻擊者與目標用戶權限相同，但通過修改參數等方式，訪問或操作了其他用戶的數據或資源。

場景舉例：

A 用戶訪問了 B 用戶的訂單詳情
普通用戶讀取了其他普通用戶的私密信息

示意圖：

[用戶A] ———> 訪問 ——> /user/info?id=1002 ———> 返回B用戶信息

2）垂直越權（Vertical Privilege Escalation）

定義：攻擊者通過接口篡改、參數偽造等方式，執行本不該有權限的高權限功能。

典型場景：

普通用戶調用管理員接口
非客服用戶給他人退款
非審核人員操作訂單審批

示意圖：

[普通用戶] ———> POST /admin/deleteUser?id=123   被執行

1.1.2?越權訪問的成因

后端接口缺乏權限校驗
僅依賴前端邏輯控制（如按鈕灰掉）
認證機制不嚴密，如僅判斷 cookie、uid 參數
接口復用導致權限缺失
系統對 token 邏輯驗證不全面

1.1.3?典型案例詳解

案例 1：修改 ID 獲取他人數據（水平越權）

GET /user/orderDetail?id=1234
Cookie: uid=1001

攻擊者將 id 改為他人訂單 id，即可獲取他人訂單詳情。若后臺沒有校驗該訂單是否屬于當前登錄用戶，就存在風險點。

案例 2：調用管理員接口刪除用戶（垂直越權）

POST /admin/deleteUser
{"user_id": 1002
}

攻擊者雖然是普通用戶，但請求成功說明權限校驗失敗。

案例 3：修改 role 提升權限

POST /user/updateProfile
{"nickname": "Jack","role": "admin"
}

若 role 參數未被服務端強制過濾，可能導致權限提升。

1.1.4?風險點利用方式

分析接口結構
- 查看參數是否包含敏感字段（id、uid、role）
嘗試替換目標字段
- 替換為其他用戶 id 或敏感用戶（如 admin）的 id
構造非法請求
- 調用隱藏/管理員接口，看是否執行成功
使用工具輔助
- Burp Suite + Autorize 插件，對比多個身份的請求差異
- Param Miner 探測隱藏字段，如 X-User-Id

1.1.5?實戰測試技巧

使用兩個不同權限賬號對比測試

登錄用戶 A 抓包，復制請求
登錄用戶 B 執行相同請求
替換其中的參數（如 user_id、token）
如果能獲取數據/執行操作，就可能存在越權

攔截關鍵請求，測試：

修改參數：id、user_id、uid、role
修改 Cookie、Header 中的身份信息
訪問管理員/審核類接口：如 /admin/, /check, /deleteUser

借助插件

工具	功能
Burp Suite	請求修改、重復發送、抓包
Autorize	自動對比權限訪問
Param Miner	探測隱藏參數、字段

1.1.6?防御建議

后端統一做權限認證，不能僅依賴前端控制
接口中所有敏感操作都必須驗證用戶身份
涉及資源的接口，強制校驗所屬歸屬
- 例如驗證 user_id == session_user_id
角色控制細化（RBAC 機制）
避免讓客戶端控制敏感參數如 role、id、is_admin

1.1.7 小結

越權訪問 = 沒有驗證你是否有“資格”去訪問或操作某個東西。

常見思路就是：

換 id
換 cookie
調接口
模擬權限高的操作
看是否成功，是否有異常響應

=======================================

1.2 支付繞過

支付繞過風險點指攻擊者在不支付或支付極少費用的情況下，獲得了本應支付代價的服務或商品，這是典型的業務邏輯風險點，在電商、充值、會員系統中高發。

1.2.1?常見支付繞過方式

類型	描述	舉例
1. 參數篡改	修改價格、商品信息等參數	price 從 `99.99` 改為 `0.01`
2. 客戶端控制訂單狀態	支付狀態由客戶端控制	攻擊者直接將 `pay_status = 1`
3. 偽造支付回調	模擬支付平臺通知支付成功	構造第三方接口回調請求
4. 跳過支付環節	接口流程被分離或支付邏輯缺失	下單后直接訪問“支付成功頁”
5. 利用測試或開發接口	后臺接口未關閉或校驗缺失	`/api/debug/pay?id=123` 直接修改訂單狀態

1.2.2?風險點詳細分析與示例

1）參數篡改型（修改金額）

接口示例（提交訂單）：

POST /api/order/submit
{"product_id": "1001","price": "0.01","count": 1
}

分析：

如果服務端直接使用客戶端傳的 price 字段來創建訂單，而不驗證商品真實價格，攻擊者可以購買 99 元商品只花 1 分錢。

利用方式：

BurpSuite 抓包 -> 攔截提交訂單請求 -> 改 price

2）客戶端控制支付狀態

請求示例：

POST /api/order/updateStatus
{"order_id": "ORD12345","pay_status": "1"
}

問題：

如果后臺沒有驗證支付是否真的成功，而僅根據客戶端傳來的字段修改狀態，則可以偽造支付成功。

3）偽造第三方支付回調

支付平臺回調示例（支付寶/微信）：

POST /api/pay/callback
{"order_id": "ORD12345","amount": "99.99","status": "success"
}

問題：

如果服務端未驗證該請求是否來自支付寶/微信官方服務器（如 IP 白名單、簽名校驗），攻擊者就可以自己構造這個回調，讓訂單變成“已支付”。

4）跳過支付直接完成流程

業務邏輯流程：

下單 → 去支付 → 支付完成頁 → 發貨

攻擊方法：

不經過支付頁面，直接訪問支付完成頁 /order/success?order_id=123
如果服務端未核實訂單是否真的已支付，則可能直接發貨！

5）利用調試接口 / 白名單接口

典型情況：

GET /api/debug/pay?order_id=123

或者：

POST /internal/order/update
{"order_id": "123","status": "paid"
}

這類接口可能是測試接口、員工內部接口、預發布環境接口，若部署在正式線上系統未做權限控制，就能被攻擊者直接調用。

1.2.3?識別支付繞過風險點的實戰技巧

1）完整跟蹤訂單支付流程

提交訂單接口（是否接受 price 參數？）
支付前頁面（是否含有金額參數？）
支付回調接口（是否存在？能否偽造？）
修改訂單狀態的接口（客戶端是否能控制？）

2）攔截并篡改關鍵字段

使用 BurpSuite + Repeater/Intruder

修改 price, total_amount
修改 status, order_state, is_paid
刪除某些字段，看默認行為（例如支付狀態）

3）偽造支付平臺請求

構造 POST 請求偽造支付平臺回調：

POST /pay/callback
Host: www.target.com
Content-Type: application/json{"order_id": "123456","amount": "0.01","status": "success"
}

檢查：

是否驗證簽名？
是否驗證請求來源 IP？
是否驗證訂單金額與實際支付金額一致？

4）嘗試跳過支付頁面

在訂單未支付時直接訪問 /order/success
查看是否進入發貨或發碼流程

5）查看是否存在調試或測試接口

路徑典型關鍵詞：

/debug/
/testpay/
/mock/pay/callback
/internal/updateOrder

1.2.4?防御建議

服務端必須：

強制校驗商品價格/優惠
- price 不可由客戶端控制
- 服務端根據商品 ID 查詢數據庫價格為準
支付成功狀態只能通過第三方回調控制
- 客戶端不可控制支付狀態
支付回調必須驗證簽名 / 來源 IP
- 使用支付寶 / 微信等平臺提供的驗簽方式
訂單狀態更新應與支付流水綁定
- 一個訂單只能有一次支付成功標記
測試接口、調試接口上線前必須禁用
- 禁止任何接口控制訂單狀態，除非加簽權限認證

1.2.5?靶場練習

實際練習支付繞過技巧，推薦以下平臺：

靶場平臺	描述
DVWA	經典 Web 風險點靶場，可自行擴展業務邏輯
BWA	有支付邏輯可練習
自建小型電商平臺	自己寫簡單后端模擬支付流程更有價值

1.2.6 小結

支付繞過核心本質：支付流程的關鍵參數/狀態/驗證，被攻擊者控制或繞過了。

攻擊者只要能在不支付或支付很少的前提下成功下單/發貨/發碼，就是成功支付繞過。

=======================================

1.3 接口欺騙

接口欺騙（API Spoofing）指：攻擊者偽造本不屬于自己的請求或身份，欺騙服務端認為是合法調用，從而獲取高權限操作或敏感數據。

可以理解為：“你不是管理員，卻讓服務端以為你是管理員。”

1.3.1?常見場景分類

類型	描述	示例
1. 假冒身份請求接口	偽造身份字段，冒充其他用戶或管理員	修改 token、uid、role
2. 利用客戶端邏輯風險點	客戶端未做數據驗證或信任度高	客戶端傳遞 `isAdmin: true` 生效
3. 繞過簽名或驗簽機制	自己構造接口請求偽造參數	構造未加簽請求，服務端未校驗簽名
4. 利用前端隱藏接口	調用調試、內部、隱藏接口	/api/dev/、/debug/、/internal/**
5. 篡改接口參數	通過請求篡改參數	修改 `price`、`user_id`、`role`

1.3.2?接口欺騙常見攻擊方式

1）篡改身份字段進行偽裝

POST /api/user/getInfo
Headers:Authorization: Bearer xxx_token
Body:user_id: 1002

攻擊者修改 user_id 參數或 Token 字段，讓服務端誤以為你就是另一個用戶。

2）客戶端控制行為參數被信任

某些前端傳遞參數可能影響服務端邏輯：

{"user_id": "123","is_vip": true,"is_admin": true
}

如果后端使用這些參數直接影響權限判斷，攻擊者就能在客戶端傳入偽造的角色信息進行接口欺騙。

3）接口簽名機制缺失或弱校驗

接口中本應攜帶簽名字段驗證來源，但：

服務端未驗證簽名是否正確；
攻擊者可以直接繞過簽名機制，偽造請求；

POST /api/pay/callback
{"order_id": "123","amount": 99,"sign": "abc123" ← 簽名隨便寫
}

如果服務器未校驗 sign 字段或者使用弱簽名機制，就容易被偽造支付回調。

4）利用內部或調試接口（服務端暴露）

如 /api/debug/loginAsAdmin?id=1、/internal/user/setRole，本用于測試或管理后臺，但：

暴露在公網；
缺乏權限認證；

攻擊者只要構造請求就能偽造管理員身份。

5）調用 APP 內部接口模擬客戶端行為

通過逆向抓包 APP，可以獲得真實接口參數與加密方式。偽造 HTTP 請求模擬 App 行為：

POST /api/withdraw
{"amount": 1000,"device_id": "xxxxx","user_id": 123
}

如果簽名不驗證、沒有設備/行為綁定，攻擊者可以偽造任意請求。

1.3.3?實戰分析流程

1）抓包分析接口請求

使用 Burp Suite 或 Charles 抓取前端與服務端通信，重點觀察：

有無身份字段（uid、token）
是否攜帶簽名、校驗字段（sign、timestamp、nonce）
接口是否驗證請求來源（User-Agent、Referer）

2）修改參數試探權限

比如將 user_id=當前用戶 改為 user_id=其他人，或添加 is_admin=true、role=admin 試探是否有效。

3）偽造接口請求

使用 Postman、curl、Burp Repeater 構造類似請求，嘗試模擬客戶端請求：

curl -X POST http://target.com/api/admin/banUser -d "uid=1002"

觀察響應狀態是否成功。

4）查看是否存在調試 / 內部接口

訪問接口路徑如：

/debug/
/api/dev/
/admin_test/
/mock/
/swagger-ui.html 查看所有接口

5）APP 場景下接口欺騙思路

抓包分析接口字段
嘗試 Frida Hook 攔截 request 參數
偽造簽名函數返回值（如 sign 校驗返回 true）
偽造 WebView 接口 JSBridge 回調

1.3.4?防御建議

防御點	原則
?服務端做身份認證	所有敏感接口必須鑒權
?不信任客戶端傳參	客戶端傳遞 `role`、`is_admin` 一律丟棄
?接口請求需驗簽	使用 JWT 或 HMAC，防止偽造請求
?隱藏 / 內部接口要下線或加權限	不可暴露測試、調試接口到公網
?接口操作必須與登錄態強綁定	不能僅靠參數如 uid 識別身份

1.3.5?真實案例參考

某 APP 會員系統接口中傳遞 is_vip=true 參數，服務端未驗證，被人免費開通 VIP。
某支付系統第三方回調接口未驗簽，被攻擊者構造 POST 請求，直接將任意訂單標記為“支付成功”。
某 Web 平臺 /admin/setRole 接口無權限校驗，攻擊者直接 POST 改變用戶權限。

1.3.6 小結

接口欺騙 = 騙服務端相信你是合法身份，進而達成非法操作。

關鍵在于：

客戶端是否能控制關鍵參數；
服務端是否盲信請求內容；
接口調用是否做了權限校驗與簽名認證。

=======================================

1.4 任意用戶登錄/密碼重置

任意用戶登錄 / 密碼重置 是一種非常嚴重的邏輯風險點，攻擊者可以在不擁有目標用戶賬號密碼的前提下，直接登錄目標賬戶或重置目標密碼，獲得完全控制權。

本質：身份認證或驗證流程存在邏輯缺陷，導致攻擊者能冒充任意用戶登錄或控制其賬號。

風險點危害

任意用戶登錄：可以登錄任意賬號（包括管理員）
任意用戶密碼重置：可以修改任意用戶的密碼，之后永久控制該賬號
最終結果：賬戶劫持、數據泄露、權限濫用，甚至整個系統被攻陷

1.4.1?常見風險點場景分類

類型	說明	舉例
1. 驗證碼邏輯缺陷	手機/郵箱驗證碼未綁定用戶或校驗不嚴格	驗證碼對誰都有效
2. 重置鏈接可預測	重置鏈接 ID、Token 可爆破或固定	token=123456
3. 缺少身份校驗	改密碼時未校驗當前用戶是否有權限	只傳入 user_id 和新密碼
4. 中間驗證跳過	忽略驗證碼 / email 驗證	直接傳郵箱重置密碼
5. 參數可篡改	修改請求中的 UID/email 達到控制其他用戶	user_id=1 改為 user_id=2

1.4.2?典型風險點案例詳解

案例一：驗證碼邏輯缺陷 → 任意密碼重置

POST /api/send_sms_code

{"phone": "13300000001"
}

攻擊者發送驗證碼到 自己的手機，拿到驗證碼：123456

POST /api/reset_password

{"phone": "任意手機號","code": "123456","new_password": "hacker123"
}

如果服務端沒有將驗證碼綁定到手機，就會導致：

拿自己的驗證碼 → 重置別人密碼！

案例二：修改 UID 參數 → 任意密碼重置

POST /api/user/reset_passwordBody:user_id=2&new_pwd=123456

攻擊者將自己的 user_id=1 改成 2，成功修改別人密碼！

根因：服務端只信任客戶端傳入的 user_id，沒有校驗是否是當前登錄用戶。

案例三：郵件重置鏈接 token 可預測

重置鏈接：

https://example.com/reset?token=abc123

攻擊者發現 token 是 user_id + 時間戳的 Base64 編碼：

base64.b64decode("abc123") => "uid=1&ts=1729202100"

他直接構造 uid=2&ts=xxxx 生成 Base64，成功構造管理員的重置鏈接！

案例四：跳過驗證碼或郵箱驗證

有些系統：

獲取驗證碼后，驗證步驟被跳過（接口未調用）
可以直接 POST 請求重置密碼，不校驗驗證碼是否正確

攻擊流程：

發送驗證碼，不用輸入驗證碼
直接構造重置請求，成功改密碼

1.4.3?測試識別技巧

1）抓包觀察重置 / 登錄流程

是不是只依賴前端校驗（驗證碼校驗在前端做）？
服務端是否校驗 user_id 和登錄態關系？

2）篡改請求參數進行試探

嘗試把自己的 user_id 改為別人的；
嘗試使用別人的手機號 / 郵箱；
驗證碼只發一次，嘗試重置多個賬號；

3）測試驗證碼是否跟手機號/郵箱綁定

實驗方法：

發送驗證碼到 A 用戶
拿驗證碼去重置 B 用戶賬號
看看是否成功

4）構造偽造重置鏈接

檢查：

重置 token 是不是可預測（如 Base64、JWT）
是否存在 GET 接口 reset?token=xxx，嘗試暴力枚舉

1.4.4?防御建議

防御項	建議
?驗證碼必須綁定身份	手機/郵箱驗證碼只能作用于當前身份
?重置操作必須鑒權	修改密碼需校驗登錄態或驗證碼
?禁止用戶 ID 參數外部傳入	user_id 只能從 session 獲取
?重置鏈接必須一次性 + 強加密	token 必須不可預測（如 UUID + AES 加密）
?驗證碼使用一次即失效	驗證碼一用即銷毀，避免被復用

1.4.5?實戰 Frida + Burp 測試技巧

Burp Suite 抓包攔截密碼重置、驗證碼發送請求
Frida Hook Java 層構造函數，修改傳入的 UID 參數
模擬 Token 重置構造，嘗試訪問其他用戶鏈接
日志分析：看是否輸出錯誤 UID、token、郵箱，泄露線索

1.4.6 小結

任意用戶登錄/密碼重置 = 騙系統信你是別人，從而控制別人的賬號。

它屬于極高危的認證繞過類邏輯風險點，檢測時重點關注：

用戶身份傳遞是否安全？
驗證碼 / token 是否綁定用戶？
修改行為是否鑒權？

二、報錯信息泄露邏輯（調試接口、環境暴露）

報錯信息泄露邏輯風險點，是 Web/APP 安全中非常容易被忽視、但卻極具危害的風險點類型，攻擊者可以通過報錯信息獲取系統內部結構、路徑、數據庫、甚至管理員賬戶等信息，為后續滲透、提權、接口欺騙等操作提供強大支撐。

報錯信息泄露指的是服務端或前端在異常情況下，返回了開發調試時的信息，例如：

代碼堆棧信息（stack trace）
數據庫查詢語句錯誤
真實服務器路徑
環境變量
調試接口未關閉
日志輸出到頁面

2.1?報錯信息泄露的危害

泄露信息類型	危害
?數據庫結構 / SQL 報錯	利于 SQL 注入構造
?真實文件路徑	可構造路徑遍歷 / SSRF 等
?框架名稱和版本	可用來搜對應風險點
?異常堆棧 / 語言調用棧	泄露后端代碼結構、內部邏輯
?環境變量 / 連接信息	獲取密鑰、Token、IP、數據庫密碼
?未關閉調試接口	可遠程訪問調試頁面執行代碼（如 SpringBoot Actuator）

2.2?典型泄露類型舉例

1）PHP 報錯信息泄露

Warning: mysql_fetch_array(): supplied argument is not a valid MySQL result resource in /var/www/html/index.php on line 22

信息點：

使用的是 mysql_* 函數
文件路徑 /var/www/html/index.php
存在 SQL 報錯，可能存在 SQL 注入

2）Java 報錯堆棧信息（Spring）

org.springframework.dao.DataAccessException: PreparedStatementCallback; bad SQL grammar [SELECT * FROM user WHERE id = ?]; nested exception is java.sql.SQLSyntaxErrorException

信息點：

使用的是 Spring 框架
數據庫語句暴露
可能存在注入點

3）Python Django 報錯頁

訪問 /page?uid=xxx 時參數異常，返回：

Exception Type: KeyError
Exception Value: 'uid'
File "/var/www/mysite/app/views.py", line 42, in get_user

泄露信息：

Python 項目，使用 Django
源碼文件路徑暴露
具體報錯行暴露（可暴力遍歷觸發其他行）

4）Laravel 報錯頁面

Facade\Ignition\Exceptions\ViewException
Undefined variable $user (View: /var/www/app/resources/views/admin.blade.php)

信息點：

Laravel 框架
模板路徑
用戶變量未定義，可能可利用

5）未關閉調試接口（Node、Flask、Spring）

/actuator 接口返回所有應用信息
/debug?code= 參數可執行代碼
Flask 開啟調試模式后，頁面報錯可執行任意 Python 表達式

6）接口 JSON 報錯泄露

{"status": 500,"error": "SQLException","message": "SELECT * FROM admin WHERE id = 1 AND pwd = 'xxx' => SQL syntax error near 'xxx'"
}

后端返回了錯誤信息，說明 SQL 拼接方式不安全，可能 SQL 注入。

2.3?識別技巧：如何發現報錯信息泄露？

1）參數探測法

對 URL 或參數字段進行異常注入，觸發錯誤信息返回：

GET /api/user?id=1' -- 報錯？
GET /page?uid=aaa
POST /login -d "username=admin&password='"

2）請求非法路徑 / 方法

例如：

GET /admin.php
GET /favicon.ico.old
POST /api/login with GET 參數

看是否返回堆棧信息或路徑提示。

3）404 / 500 錯誤頁面分析

有些站點返回 500/403 錯誤會顯示完整棧追蹤
比如 Laravel、Flask 默認調試模式返回完整報錯頁

4）訪問調試接口

探測路徑：

/debug
/debug.php
/actuator
/swagger-ui.html
/__debug__/
/.ENV
/.git/

5）Burp 報錯自動化掃描

使用 Burp Scanner 開啟主動掃描
特別是針對返回包含 Exception, Traceback, error, Warning 的頁面

2.4?防御建議

防御措施	說明
?關閉調試模式	所有部署環境都必須關閉 DEBUG
?報錯信息屏蔽用戶可見部分	僅記錄日志，不向前端輸出
?正確使用異常處理機制	try-catch + 自定義錯誤響應
?開啟統一錯誤頁	對所有 500 報錯統一返回“系統異常”頁面
?掃描代碼和配置文件	檢查日志、路徑、接口暴露情況

2.5?實戰建議

嘗試用錯類型的參數觸發錯誤（如 int 改 string）
刪除或添加關鍵字段引發異常（如 POST 時刪掉 token 字段）
探測調試路徑、特殊接口
分析返回包中的關鍵詞：Exception、trace、Warning、line

2.6 總結

報錯信息泄露 = 系統把它最不該告訴你的秘密，直接告訴了你。

在實戰中，報錯信息常被用作：

信息收集
接口識別
SQL 注入輔助
XSS/CSRF 參數構造輔助
接口欺騙準備
登錄/權限繞過入口發現

三、風險點識別技巧：

3.1 斷點調試

斷點調試（Break Point Debugging）指的是在程序代碼運行過程中，人為插入“暫停點”，當執行到該處時，暫停程序運行，以便觀察 變量狀態、流程邏輯、函數調用、參數值 等，從而判斷代碼中是否存在邏輯問題或繞過點。

斷點調試核心目的：

觀察實際邏輯流程是否符合預期
定位關鍵邏輯函數（如加密、校驗、權限判斷）
修改變量/函數返回值，實現前端邏輯繞過
還原客戶端加密算法、參數生成邏輯
探測客戶端是否依賴前端校驗

3.1.1?使用工具分類

調試對象	常用工具	說明
Web 前端 JS	Chrome DevTools	斷點 JS、XHR、事件
移動端 APP	Frida + Objection、Xposed	動態 hook Java/Native 函數
Web 請求流	Burp Suite + JS 插件	修改并觀察行為
小程序	微信開發者工具 / Flipper	Hook 請求和函數調試

3.1.2?Web JS 調試實戰

場景一：跳過前端權限校驗

if (!user.isVip) {alert("請開通會員");return;
}

操作步驟（Chrome DevTools）：

打開網頁，按 F12 進入開發者工具
找到相關 JS 文件，搜索關鍵詞：isVip 或 alert
在判斷語句前加斷點
頁面刷新，斷點命中后，在控制臺執行：

user.isVip = true;

然后點擊“繼續”，邏輯被繞過

場景二：找出加密函數

token = encrypt(uid + timestamp)

通過斷點調試可以：

找出 encrypt() 函數的源碼位置
觀察它的參數，查看它用的加密方法（Base64/AES/MD5）
Hook 它返回的密文做還原分析

3.1.3?Frida 實戰（安卓端斷點）

以一個典型場景為例：登錄函數繞過

場景：APP 內部判斷密碼是否正確的 Java 函數

public boolean checkPassword(String inputPwd) {return inputPwd.equals("realpassword123");
}

Frida 動態 Hook 斷點：

Java.perform(function () {var LoginClass = Java.use("com.example.app.LoginActivity");LoginClass.checkPassword.implementation = function (pwd) {console.log("輸入密碼: " + pwd);return true; // 繞過密碼校驗};
});

效果：

不管輸入啥密碼，都會返回 true
可用于 任意賬號登錄風險點驗證

3.1.4?XHR / fetch 請求斷點調試

場景：找出請求中參數是怎么生成的

例如點擊登錄后，頁面通過 fetch() 發送如下請求：

POST /login
{"username": "admin","password": "xxx","token": "q92qxl3x9hd=="
}

不知道 token 怎么生成的。

操作流程：

F12 → Sources → 搜索關鍵詞：fetch、XMLHttpRequest
找到 token 拼接/賦值那行代碼，加斷點
觀察 token 的生成邏輯，可能是加密、base64 或時間戳
可用于 JS 參數還原 / 構造腳本

3.1.5?斷點調試的典型用途總結

場景	目的	技巧
權限判斷繞過	跳過會員/登錄/驗證限制	修改變量值 / 函數返回值
支付邏輯調試	找出支付金額字段、跳轉前驗證	修改金額 / 跳過檢查函數
參數加密分析	找到加密函數并還原算法	Hook encrypt() 輸入輸出
表單提交攔截	查看參數生成時間點	XHR/fetch 斷點觀察參數流
客戶端校驗邏輯	查看是否本地驗證密碼/token	Hook 比較函數返回值
條件分支覆蓋	跳過不利條件	手動設置變量讓其進入目標分支

3.1.6?實戰小技巧

技巧	說明
`debugger;` 插入代碼斷點	在 JS 任意處插入后頁面自動中斷
中斷所有異常點	DevTools → Pause on exceptions
觀察變量路徑	右鍵變量 → Add to Watch / Console
Burp + DevTools 聯合調試	抓包修改參數 + F12 跟蹤流程
Frida hook + 修改變量返回	真正干預函數返回

3.1.7 小結

斷點調試是在做“黑盒滲透”時打開“白盒視角”的鑰匙。

它能讓我們看到原本只有客戶端知道的“秘密”，并借此實現：

本地邏輯繞過
參數構造還原
安全機制破壞
模擬前端行為精確復現風險點

=======================================

3.2 參數篡改

參數篡改（Parameter Tampering）是指攻擊者在客戶端或請求過程中篡改 HTTP 請求中的參數，使其繞過后臺邏輯校驗、獲得非授權的數據或進行非法操作。

核心目標：

繞過權限校驗
偽造支付金額
提權/修改狀態
越權訪問他人數據

3.2.1?常見可被篡改的參數類型

參數類型	舉例	風險
用戶 ID	`uid=1001`	訪問他人資料（越權）
訂單金額	`amount=0.01`	支付繞過
權限等級	`role=admin`	提權
狀態標志	`is_vip=1`	免費享受會員功能
請求 token	`token=abc123`	token 騙過校驗接口
商品 ID	`product_id=999`	購買非上架商品

3.2.2?篡改位置分析（黑盒測試中重點觀察）

1）URL 查詢參數

GET /user/info?uid=1001

用于訪問他人賬戶、資料、訂單、評論等。

2）POST 表單參數

POST /order/create
Content-Type: application/x-www-form-urlencodedproduct_id=1001&amount=9999

改 amount=1 或 product_id=其他隱藏商品

3）JSON 參數

POST /api/buy
Content-Type: application/json{"uid": 123,"price": 0.01
}

篡改 JSON 參數繞過價格校驗。

4）Cookie / Header 參數

Cookie: uid=1; isAdmin=true;

有些系統在 Cookie 里存權限字段。可本地修改 Cookie 實現提權。

3.2.3?常見攻擊場景與實戰分析

場景一：越權訪問他人數據

目標接口：

GET /api/user/info?uid=123

你是 123，但嘗試改為 1：

GET /api/user/info?uid=1

如果服務端未驗證當前登錄者是否就是 uid=1，那就造成越權訪問風險點。

場景二：支付金額篡改

請求體原始內容：

POST /pay
price=99.00&order_id=9999

攻擊者嘗試改為：

price=0.01

后臺如果只用前端傳來的金額，而沒有二次查詢訂單真實金額，那就導致支付金額繞過。

場景三：非會員提權為 VIP

POST /setUserInfo
{"uid": 123, "vip": true}

或者某些系統允許這樣請求：

GET /updateUser?isVip=true

如果服務端不校驗權限，直接存儲了修改值，就可以導致非授權用戶變為 VIP。

場景四：跳過身份校驗 Token

接口：

POST /order/create
Authorization: Bearer 5e2f3xxx

攻擊者嘗試替換 token 為固定、弱 token，或構造他人賬號的 token，看是否可以下單到其他賬號上。

3.2.4?識別技巧

技巧	說明
抓包分析參數結構	Burp Suite 抓包，對參數逐個測試
修改請求參數重發	Burp Repeater / Postman / DevTools
參數爆破	Burp Intruder，爆破 UID、訂單號
觀察響應差異	返回內容中是否有權限不足、數據異常
構造未授權請求	登錄 A，調用 B 的數據接口

3.2.5?如何用 Burp Suite 實戰測試

步驟

打開目標網站，配合 Burp 抓包
找到用戶中心 / 訂單管理等功能點
修改 UID、order_id 等參數
重發請求，觀察是否能獲取他人數據

示例（重發請求）

原始請求：

GET /api/order?order_id=899

修改后重發：

GET /api/order?order_id=1

如返回管理員訂單，則存在越權。

3.2.6?加固建議

類型	加固方案
所有用戶參數	后端永遠不要相信前端傳來的 uid/權限級別
金額相關參數	后端必須根據訂單 ID 查詢真實價格
token / session	校驗 token 是否與當前用戶匹配
管理接口	限制權限，僅開放給管理員登錄角色
參數簽名機制	加密或簽名關鍵參數（如支付寶支付參數）

3.2.7 小結

參數篡改 = “攻擊者篡改請求中一切能動手的內容” → 看看系統會不會被騙。

它是最基礎、最高效的邏輯風險點探測方式
配合 Burp + 業務分析，能挖出大量越權/提權/支付繞過風險點
對開發者來說，永遠不要信任客戶端傳來的任何信息

=======================================

3.3 業務分析

**業務分析（Business Logic Analysis）**是指：站在攻擊者視角，理解系統功能設計和業務流程，然后尋找可以利用的邏輯缺陷。

簡單說，它不是去找某個函數有 bug，而是找整個業務邏輯中的風險點 —— “流程錯了”、“權限漏了”、“校驗弱了”。

業務分析很重要！

傳統風險點	業務邏輯風險點
XSS、SQL注入、命令注入	越權、支付繞過、任意登錄、刷優惠券、秒殺邏輯破壞
技術點容易學、自動化工具可查	只能靠人理解、無法自動檢測
常見于 CVE 和練習平臺	更常見于企業實戰、SRC 報告

如果掌握業務分析，就能做到別人掃描器做不到的風險點，例如：

非法訪問他人訂單
偽造 token 登錄
搶購邏輯提前下單
優惠券重復使用
虛擬幣重復提現

3.3.1?業務分析四步法

1>理解業務流程

要像“正常用戶”一樣，從注冊 → 登錄 → 下單 → 支付 → 收貨全流程走一遍。

方法：

模擬正常操作一遍
抓包分析接口路徑、參數變化
用 Postman/Burp 重放請求，理清流程

2>劃分角色邊界

思考：這個系統有哪些身份角色？

角色	能干什么
未登錄游客	瀏覽商品、注冊
普通用戶	下單、付款、查看訂單
商家	發布商品、查看訂單
管理員	修改數據、操作用戶

→ 重點：一切從“低權限能否干高權限事”的角度出發！

3>尋找可被操控的關鍵參數

重點觀察：

用戶 ID、訂單 ID、商品 ID
支付金額、token、角色字段
是否能從客戶端篡改這些值

4>結合流程找“風險點”

業務功能	分析思路
下單流程	能否下別人商品、金額可改？
賬號找回	是否校驗身份？驗證碼可重用？
優惠活動	搶購是否提前？優惠券能否復用？
虛擬充值	充值記錄能否偽造？回調能否重放？

3.3.2?幾個典型業務邏輯風險點案例（SRC常見）

案例一：支付金額繞過

流程：

用戶提交訂單，前端傳價格字段
攻擊者篡改 POST 參數中的 price=0.01
后臺沒有校驗價格是否合法
實際支付金額僅 0.01 元，構成風險點

案例二：任意用戶密碼重置

流程：

訪問重置頁面：/resetPassword?uid=123
只驗證了鏈接中的 uid，而未校驗身份或驗證碼
攻擊者替換 uid=1，實現修改管理員密碼

案例三：重復提現風險點

流程：

用戶提現 → 生成任務記錄
后臺異步通知發起轉賬
攻擊者抓包重放回調通知 → 提現多次到賬

案例四：訂單秒殺提前發起

流程：

秒殺商品應該 10:00 開放下單
攻擊者提前抓包接口（比如 POST /order）
發現參數未做時間限制 → 實現秒殺提前下單

3.3.3?輔助工具推薦

工具	用途
Burp Suite	抓包、重放、參數修改
Postman	構造流程請求
DevTools	查看請求參數、JS邏輯
Frida	Hook 客戶端函數、支付邏輯分析
風險點平臺 DVWA/靶場	練習流程分析能力