关于 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 实战测试

步骤

1. 打开目标网站，配合 Burp 抓包

2. 找到用户中心 / 订单管理等功能点

3. 修改 UID、order_id 等参数

4. 重发请求，观察是否能获取他人数据

示例（重发请求）

原始请求：

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 小结

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