关于 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/靶场	练习流程分析能力

3.3.4 实战中该怎么做？

拿到一个网站或者 APP 后：

用正常流程注册一遍账号
抓包记录每个重要功能：下单、支付、找回密码
提取所有重要参数字段，尝试篡改 / 重放
尝试扮演低权限用户做高权限操作
想办法跳过某个流程步骤（比如跳过支付页面直接下单）
结合 JS 逆向或 Frida 分析客户端中是否存在可绕逻辑

3.3.5 小结

业务分析的本质：用攻击者的视角走一遍用户流程，寻找“不该发生但能发生的事”。

关于 Web 风险点原理与利用：6. 逻辑风险点

一、分类：

1.1 越权访问

1.1.1 越权访问的分类

1.1.2 越权访问的成因

1.1.3 典型案例详解

1.1.4 风险点利用方式

1.1.5 实战测试技巧

1.1.6 防御建议

1.1.7 小结

1.2 支付绕过

1.2.1 常见支付绕过方式

1.2.2 风险点详细分析与示例

1.2.3 识别支付绕过风险点的实战技巧

1.2.4 防御建议

1.2.5 靶场练习

1.2.6 小结

1.3 接口欺骗

1.3.1 常见场景分类

1.3.2 接口欺骗常见攻击方式

1.3.3 实战分析流程

1.3.4 防御建议

1.3.5 真实案例参考

1.3.6 小结

1.4 任意用户登录/密码重置

1.4.1 常见风险点场景分类

1.4.2 典型风险点案例详解

1.4.3 测试识别技巧

1.4.4 防御建议

1.4.5 实战 Frida + Burp 测试技巧

1.4.6 小结

二、报错信息泄露逻辑（调试接口、环境暴露）

2.1 报错信息泄露的危害

2.2 典型泄露类型举例

2.3 识别技巧：如何发现报错信息泄露？

2.4 防御建议

2.5 实战建议

2.6 总结

三、风险点识别技巧：

3.1 断点调试

3.1.1 使用工具分类

3.1.2 Web JS 调试实战

3.1.3 Frida 实战（安卓端断点）

3.1.4 XHR / fetch 请求断点调试

3.1.5 断点调试的典型用途总结

3.1.6 实战小技巧

3.1.7 小结

3.2 参数篡改

3.2.1 常见可被篡改的参数类型

3.2.2 篡改位置分析（黑盒测试中重点观察）

3.2.3 常见攻击场景与实战分析

3.2.4 识别技巧

3.2.5 如何用 Burp Suite 实战测试

3.2.6 加固建议

3.2.7 小结

3.3 业务分析

3.3.1 业务分析四步法

3.3.2 几个典型业务逻辑风险点案例（SRC常见）

3.3.3 辅助工具推荐

3.3.4 实战中该怎么做？

3.3.5 小结

相关资讯

热文排行

最新新闻

推荐新闻

热搜词