网安新人遇到WAF不用慌：我靠5类逻辑漏洞，1周凑够20个有效报告

刚入行做渗透测试时，我遇到的第一个 “拦路虎” 就是 WAF。那是个电商客户的测试项目，我带着刚学的 SQLMap、Xray 兴冲冲上场，结果扫描半天，终端里全是 “WAF 拦截”“请求被阻断” 的提示 —— 别说高危漏洞，连个低危的信息泄露都没扫出来。

看着身边同事陆续提交 “文件上传漏洞”“SQL 注入” 的报告，我对着 Burp 里红色的 403 响应码发呆。前辈老陈路过，看了眼我的屏幕说：“新人都爱盯着工具扫出来的漏洞，却忘了 WAF 拦不住‘业务逻辑’—— 那些藏在登录、下单、支付里的漏洞，才是凑数量、出成果的关键。”

那天下午，老陈带我测了客户的 “密码重置” 功能：抓包改了下 “手机号” 参数，居然能接收别人的验证码 —— 一个典型的逻辑漏洞，不仅没被 WAF 拦截，还被评为中危。也就是从那时起，我才明白：面对 WAF，网安新人不用死磕 “绕过技术”，把业务逻辑拆透，漏洞数量自然就来了。

一、先搞懂：为什么 WAF 拦不住逻辑漏洞？

在讲具体漏洞类型前，得先理清一个核心问题：WAF 的 “软肋” 在哪？其实 WAF 的本质是 “识别恶意特征”—— 比如 SQL 注入的' or 1=1#、XSS 的<script>标签，这些带有明显攻击痕迹的请求会被直接拦截。但逻辑漏洞不一样，它的请求全是 “合法的”：参数是业务里有的（比如user_id、price），请求方式是正常的（POST/GET），WAF 根本判断不出这是 “攻击”。

用一张图就能看明白两者的区别：

举个我遇到的例子：某电商的 “下单支付” 功能，我抓包把price=99改成price=0.001，请求里没有任何恶意字符，WAF 直接放行；但后端没校验 “订单金额是否与商品原价一致”，导致我用 1 分钱买了 100 元的商品 —— 这就是逻辑漏洞的 “隐蔽性”，也是新人凑漏洞数量的 “黄金赛道”。

二、新人易上手的 5 类逻辑漏洞：带实战案例 + 测试步骤

这 5 类逻辑漏洞是我从业 3 年总结的 “高产类型”，每类都有明确的测试方法，新人跟着做就能出成果。我会结合自己的实战案例，把 “怎么测、怎么确认、怎么写报告” 讲透，确保你看完就能用。

1. 水平越权：最易发现的 “入门级漏洞”，10 分钟测一个

漏洞原理：同权限用户之间能互相访问数据（比如你能看别人的订单、地址、聊天记录），本质是后端只校验了 “登录状态”，没校验 “数据归属权”。

案例1：某外卖平台测试时，登录自己的账号，抓包查看 “我的订单” 的请求：GET /api/order?user_id=12345 HTTP/1.1返回里有我的订单号、收货地址。试着把user_id=12345改成user_id=12346，再发请求 —— 居然返回了另一个用户的订单信息！更夸张的是，改到user_id=12300时，还看到了某明星的私人收货地址。

新人测试步骤（全程用 Burp，不用复杂工具）：

1. 找 “个人中心”“我的订单”“我的收藏” 这类带 “个人数据” 的功能，抓包记录请求里的用户标识（常见参数：user_id、uid、openid）；
2. 用 Repeater 模块，把用户标识改成其他数值（比如自己的 ID±1、100、1000），发送请求；
3. 对比返回结果：如果能看到不属于自己的数据（比如别人的手机号、订单号），漏洞成立；
4. 扩大范围：用 Intruder 模块批量跑user_id（字典用 1-10000 的数字），统计能越权查看的数量，算多个有效漏洞。

漏洞价值：多数平台判定为中危，单个漏洞能算 “有效报告”，批量跑能快速凑数量（我曾 1 小时测出 8 个水平越权）。

2. 支付逻辑漏洞：高价值 + 易复现，新人也能出高危

漏洞原理：支付环节的 “金额、订单状态、优惠规则” 没做后端校验，导致能 “少付钱、不付钱”，甚至 “付 1 元买 1000 元商品”，属于高价值漏洞。

实战案例2：某生鲜电商测试时，我选了 1 箱 198 元的水果，下单后抓包看支付请求：POST /api/pay HTTP/1.1``order_id=789&amount=198&pay_type=wechat我试着把amount=198改成amount=0.01，点击支付 —— 居然真的跳转到了 “支付 1 分钱” 的页面！支付成功后，订单状态显示 “已付款”，第二天还收到了水果。这个漏洞被评为高危，客户还额外给了 500 元奖金。

新人测试步骤：

1. 选 “实物商品”（避免虚拟商品难验证），加入购物车下单，到 “确认支付” 页面抓包；
2. 找支付相关参数：amount（金额）、discount（折扣）、total_price（总价），用 Repeater 改值（常见改法：改 0.01、改负数、改折扣为 9999）；
3. 验证结果：支付成功后，查看订单是否 “已付款”，商品是否能正常发货 / 使用（必须有实际验证，不然会被判定 “无效”）；
4. 延伸测试：除了改金额，还能试 “重复使用优惠券”（取消订单后优惠券没回收）、“多商品下单少付款”（比如买 2 件改 1 件的钱）。

漏洞价值：90% 以上判定为高危，单个漏洞顶 3 个中危，是 “凑数量 + 提成果” 的利器。

3. 密码重置漏洞：3 种常见场景，新人必测功能

漏洞原理：密码重置流程的 “身份校验” 有缺陷，比如能接收别人的验证码、跳过验证步骤，本质是后端没把 “验证码” 和 “用户账号” 绑定。

实战案例3（3 种常见场景）：

• 场景 1：验证码未绑定手机号。某社交 APP 重置密码时，抓包看到请求是POST /api/reset?phone=138xxxx1234&code=654321，我把phone=138xxxx1234改成同事的手机号139xxxx5678，用自己的验证码654321提交 —— 居然重置了同事的密码！
• 场景 2：验证码爆破。某金融 APP 的验证码是 4 位数字，且没限制尝试次数，我用 Burp Intruder 跑 0000-9999 的字典，5 分钟就爆破出了验证码；
• 场景 3：跳过验证步骤。某电商的密码重置分 3 步：填手机号→收验证码→改密码，我抓包发现第 3 步的请求里没有 “验证码校验结果”，直接删了code参数提交 —— 居然直接进入了改密码页面！

新人测试步骤：

1. 找 “忘记密码” 功能，完整走一遍流程，记录每一步的请求（重点看是否有phone、code、token这类参数）；
2. 测试 “参数篡改”：改phone为他人手机号，用自己的验证码提交；
3. 测试 “验证码爆破”：看验证码是否有长度限制、次数限制，用 Intruder 跑字典；
4. 测试 “步骤跳过”：删除请求里的code、verify_token等参数，看能否进入下一步。

漏洞价值：中高危为主，单个漏洞有效，且几乎所有平台都有 “密码重置” 功能，测试覆盖率 100%。

4. 业务流程漏洞：藏在 “细节里” 的漏洞，新人容易忽略

漏洞原理：业务流程设计有缺陷，比如 “注册后未审核就能登录”“取消订单后库存不恢复”，这类漏洞看似 “小”，但批量发现后能快速凑数量。

实战案例4：

• 案例 1：某企业 OA 系统，注册时需要 “企业邮箱验证”，但我用 “临时邮箱” 注册后，发现不用验证就能直接登录，还能查看其他未审核用户的信息（低危，算有效漏洞）；
• 案例 2：某电商的 “秒杀活动”，商品库存 100 件，我下单后取消，再下单 —— 发现库存没减少，反复操作 10 次，居然 “占了” 10 件库存，导致其他用户抢不到（中危）；
• 案例 3：某外卖平台，下单时选 “到店自提”，支付后取消订单，退款秒到账，但商家后台显示 “订单已完成”，可以重复多次 “下单 - 取消” 套取平台补贴（高危）。

新人测试步骤：

1. 拆解业务流程：比如 “注册→登录→下单→支付→取消”“发布商品→审核→上线”，把每个环节都列出来；
2. 找 “异常操作点”：比如注册后不验证、取消订单、重复提交、跳过审核；
3. 验证影响：比如取消订单看库存是否恢复，重复提交看是否有重复数据，记录每个有问题的环节。

漏洞价值：低中危为主，单个漏洞有效，且数量多（我曾在一个项目里测出 6 个业务流程漏洞），适合凑数量。

5. 会话管理漏洞：“不起眼但必存在”，新人易上手

漏洞原理：会话（Session）的 “有效期、唯一性、销毁机制” 有问题，比如登录后 Cookie 不失效、多设备登录不踢下线，导致别人能 “复用会话” 登录账号。

实战案例5：

• 案例 1：某购物 APP，登录后获取 Cookie（sessionid=abc123），退出账号后，用 Burp 重新发送带这个 Cookie 的请求 —— 居然还能访问 “我的订单”（中危）；
• 案例 2：某游戏平台，用账号 A 登录，获取token=def456，再用账号 B 登录，发现token格式一样，只是最后几位不同，用 Intruder 跑了 100 个token，居然登录了 3 个其他用户的账号（高危）。

新人测试步骤：

1. 登录账号，记录 Cookie 里的sessionid、token等会话参数；
2. 测试 “退出后会话是否失效”：退出账号后，用 Repeater 发送带旧 Cookie 的请求，看能否访问个人数据；
3. 测试 “会话唯一性”：多设备登录，看sessionid是否相同；改token的后几位，看能否登录其他账号；
4. 测试 “有效期”：登录后关闭浏览器，过 1 天再用旧 Cookie 请求，看是否还能访问。

漏洞价值：中危为主，单个有效，且所有需要登录的平台都有会话管理，测试成本低。

三、新人扫逻辑漏洞的 “实战方法论”：1 周凑 20 个有效报告

掌握了漏洞类型，还要有 “高效测试方法”，不然东测一个西测一个，效率很低。我总结的 “业务流程拆解法”，帮我多次在项目里 1 周凑够 20 个有效报告，新人可以直接套用。

1. 第一步：画 “业务流程图”，不遗漏任何功能

拿到测试目标后，先花 1 小时梳理所有业务功能，用思维导图画出流程，比如：

核心原则：每个功能都要测，尤其是 “涉及用户数据、资金、权限” 的功能（比如支付、订单、密码重置），漏洞概率最高。

2. 第二步：用 “Burp 抓包 + Repeater 改参”，不用复杂工具

新人不用学 SQLMap、Xray 这些工具的高级用法，用 Burp 的 3 个模块就够了：

• Proxy：抓包，记录所有业务请求；
• Repeater：改参数（如user_id、amount），验证漏洞；
• Intruder：批量测试（如爆破验证码、批量越权user_id）。

我的操作习惯：

1. 打开 Burp Proxy，浏览器登录测试账号；
2. 逐个点击业务功能，把所有请求都 “拦截→保存” 到 “History”；
3. 对每个请求，用 Repeater 改关键参数（先改user_id、amount、phone这些常见参数）；
4. 发现漏洞后，立刻截图（请求 + 返回结果），记录测试步骤。

3. 第三步：写 “清晰的漏洞报告”，确保每个漏洞都被认可

新人常犯的错是 “报告写得模糊”，导致漏洞被判定 “无效”。我总结的 “报告模板”，能让漏洞通过率提升 90%：

• 漏洞名称：明确类型 + 功能（如 “支付功能金额篡改漏洞”“订单查询水平越权漏洞”）；
• 测试步骤：分 1、2、3 步，写清楚 “怎么操作、改了哪个参数、出现什么结果”（比如 “1. 登录账号 A，抓包查看订单请求；2. 改 user_id=12345 为 12346；3. 返回显示用户 B 的订单信息”）；
• 危害说明：讲清楚漏洞的影响（如 “攻击者可查看任意用户订单，泄露手机号、地址等隐私信息”）；
• 修复建议：给具体方案（如 “后端校验 user_id 与当前登录用户的一致性，不一致则返回 403”）；
• 证据截图：包含 “请求参数”“返回结果”“实际效果”（比如支付 1 分钱的截图、越权查看的订单截图）。

四、新人避坑指南：3 个常见错误，别让漏洞 “白测”

1. 只测前端，不测后端：比如改了amount后，前端显示 “1 分钱”，但后端实际扣了 198 元 —— 这不算漏洞！一定要 “支付成功后查订单状态、查实际扣款金额”，确保后端真的有问题。
2. 不验证漏洞影响，直接提交：比如发现 “能改user_id看别人的订单，但订单里只有订单号，没有隐私信息”—— 这属于 “低危且影响极小”，可能不算有效漏洞。一定要确认漏洞有实际危害（如泄露隐私、造成损失）。
3. 批量测试不记录细节：用 Intruder 跑user_id时，发现 10 个能越权的，但只提交 1 个报告 —— 其实每个user_id对应的越权都算有效漏洞，要分别记录 “改了哪个 ID、看到了什么数据”，分开提交报告。

结语：WAF 不是 “拦路虎”，而是 “指路牌”

新人遇到 WAF 不用慌，反而应该高兴 ——WAF 帮你排除了 “常规漏洞” 的干扰，让你能专注于 “逻辑漏洞” 这个 “蓝海”。我刚入行时，就是靠逻辑漏洞从 “零报告” 做到 “项目漏洞数量第一”，甚至比老员工还多。

记住：逻辑漏洞的核心是 “拆业务、改参数、验结果”，不需要复杂的技术，只需要细心和耐心。下次遇到 WAF，就按 “画流程图→抓包改参→写报告” 的步骤来，不出 1 周，你也能凑够 20 个有效漏洞报告。

最后送新人一句话：网安行业不缺 “会用工具的人”，缺的是 “懂业务的人”—— 把业务逻辑拆透，你就是最能出成果的那一个。

网络安全学习资源分享:

给大家分享一份全套的网络安全学习资料，给那些想学习 网络安全的小伙伴们一点帮助！

对于从来没有接触过网络安全的同学，我们帮你准备了详细的学习成长路线图。可以说是最科学最系统的学习路线，大家跟着这个大的方向学习准没问题。

因篇幅有限，仅展示部分资料，朋友们如果有需要全套《网络安全入门+进阶学习资源包》，请看下方扫描即可前往获取