逻辑漏洞 不靠”代码执行”，而是利用业务规则设计上的疏漏：该校验的没校验、该隔离的没隔离。它常常比 SQLi、RCE 更难用自动化工具扫出来，却极其致命——因为攻击者是在”合法功能”里做不合法的事。
以下仅在授权靶场（如 pikachu、逻辑漏洞专项靶场）练习；对他人系统利用属违法。
为什么逻辑漏洞难防
工具能扫出”这个参数有注入”，但扫不出”这个下单流程少了一个校验”。逻辑漏洞藏在业务流程里：改价格、改 ID、改顺序、删步骤，就能白嫖或越权。它考验的是测试者的”换位思考”——把自己当产品经理，挑流程的漏。
越权：看/改不该你看的数据
垂直越权：普通用户干了管理员的事。比如后台地址 /admin/deleteUser?id=1，程序只在前端隐藏了入口，但没在后端校验”当前用户是不是管理员”。普通用户直接敲这个 URL 就删了用户。
水平越权：同权限用户看了别人的数据。比如 /user/info?uid=1001，你把自己的 uid 改成 1002，就能看别人的资料、订单、余额。
根因：后端只认”参数”，不认”当前登录用户有没有权限操作这个对象”。正确做法是：从会话取当前用户 ID，查数据时强制带上 WHERE owner=当前用户，而不是信任前端传的 uid。
支付/订单逻辑
- 改价格：下单时抓包把
price=100改成price=1，若后端不重新核价就按 1 元成交； - 改数量：
quantity=-1让总价变负，反而给用户加余额； - 重复提交：没做幂等，点多次”支付”生成多个订单或重复发货；
- 优惠券叠加：本来互斥的券被重复用，或一张券用 N 次；
- 步序绕过：正常流程”选商品→填地址→支付”，攻击者跳过支付直接访问”完成页”，订单变已支付。
防御：价格/数量以服务端为准重新计算；关键操作做幂等；优惠券用一次即废；支付状态由支付网关回调确认，不信任前端。
未授权访问
一些内部接口、管理页面、API 没做认证或鉴权，直接可访问：
/api/user/list返回所有用户，无需登录；- Swagger/Actuator 调试接口暴露在外网；
- 备份目录
www.zip可下载。
防御：所有敏感接口统一走鉴权中间件；调试接口内网隔离、生产关闭。
弱口令与爆破
- 管理员用
admin/123456、空口令； - 没做登录失败锁定、没验证码，可被爆破；
- 用户名可枚举（输错提示”用户不存在”）。
防御：强制强口令策略、登录失败锁定/限流、验证码、双因素认证、统一模糊报错（“用户名或密码错误”）。
验证码绕过
- 验证码前端校验或不刷新（同一验证码能用多次）；
- 验证码答案回显在前端（藏在 HTML/JS 里）；- 验证码可预测（如
1234固定）； - 验证码接口与登录接口分离，可跳过验证码直接登录。
防御：验证码服务端生成和校验、一次性、绑定会话、不可预测。
任意文件下载与目录穿越
下载功能 ?file=report.pdf，若直接拼路径，攻击者用 ../../ 逃出目录读 /etc/passwd 或源码：
?file=../../../../etc/passwd防御：白名单限定文件名、用 ID 映射真实路径、过滤 ../、限制目录、用 basename。
其他常见逻辑坑
- 短信/邮件轰炸：没限制发送频率，可被刷接口；
- 密码找回逻辑：凭用户名直接发重置链接、重置链接可预测/不过期、修改密码不校验旧密码；
- 并发竞态：抢购/转账在高并发下重复扣减（用事务+锁）；
- 条件竞争改状态：如先查后改之间被插入恶意操作。
怎么测逻辑漏洞
- 画流程图：把每个功能的正常步骤画出来；
- 找”信任前端”的地方：价格、权限、状态是不是后端重算/重校验；
- 改参数试越权：换 uid、换角色标识、跳步骤；
- 重放/并发：同一请求发多次、并发发；
- 看报错：异常提示是否泄露过多信息。
逻辑测试靠”脑子”多于”工具”，是渗透里最见功力的部分。
更多实战案例：并发下的超卖与重复
电商下单接口若先查库存再扣减：if(stock>0){ stock--; }，两个请求同时到达，都读到库存为 1，都通过判断，结果库存变负、超卖。修复要用数据库原子操作或加锁：UPDATE goods SET stock=stock-1 WHERE stock>0。支付场景更危险：用户同时点两次支付，若没做幂等（同一笔订单只处理一次），可能扣两次钱。测试时用并发工具同时发多个请求，看是否出现超卖、重复扣款、重复发券。
更多实战案例：改参数薅羊毛与越权
抽奖接口若用前端传 count=1 表示抽一次，攻击者在请求里改 count=100 一次抽一百次；签到接口若只在前端记”今天签过”，攻击者改日期参数或重放请求反复签到领奖励。越权类逻辑漏洞：修改请求里的用户标识、订单号、金额，看系统是否盲目信任客户端传的值而不校验”这个人到底有没有权限操作这个对象”。
更多实战案例：流程绕过与条件竞争
找回密码流程：验证短信→重置密码。若第二步没绑定第一步的会话，攻击者跳过短信验证直接调重置接口改别人密码。条件竞争：抢购、领券、注册优惠码，在临界时刻并发请求抢到超额资源。这类漏洞往往没有报错、没有注入，纯粹是”业务逻辑没想全”，扫描器发现不了，必须人脑顺着业务流程去想”如果我是攻击者会怎么走捷径”。
常见坑
- 只信前端传的值：金额、数量、用户标识绝不能信客户端，必须服务端算和校验。
- 忽略并发：单测没问题，并发一上就超卖，要用压测/并发工具验证。
- 流程步骤不绑定会话：任一步可跳过就成大漏洞。
- 把逻辑漏洞当功能问题：它常表现为”能薅羊毛”，本质是安全风险。
进阶：修复思路
核心原则：关键决策在服务端做，且对每次操作校验权限与边界。金额服务端算、库存用原子扣减、操作加幂等 token 防重放、流程间用服务端状态机绑定、对异常频率做限流风控。测试时把”业务流”当攻击面，用”如果我是用户，怎么钻空子”的视角去走查。
小测验
- 问题1：超卖怎么修？答案：用数据库原子更新或加锁，如 WHERE stock>0 再扣减。
- 问题2：支付重复扣款怎么防？答案：做幂等，同一订单只处理一次。
- 问题3：逻辑漏洞为什么扫描器难发现？答案：它无报错无注入，靠业务流程钻空子，需人脑走查。
更多实战案例：验证码与短信轰炸
短信验证码接口若没做频率限制和图形验证码，攻击者可写脚本循环请求，给同一手机号狂发短信（消耗企业额度、骚扰用户），或批量刷验证码尝试撞库。测试：对同一手机号连续请求十次，看是否还能发、是否有图形码拦截。修复：图形验证码 + 同一号码每分钟限次 + 同一 IP 限次 + 签名校验。这类属于”资源滥用”类逻辑漏洞，影响体验和成本。
更多实战案例：越权中的 IDOR
IDOR（不安全的直接对象引用）是越权最常见形式：接口用 ?order_id=1001 取订单，攻击者把 id 改成 1002 看别人订单；用 ?file_id=5 下载，改成 6 下到别人文件。根因是”用客户端传的标识直接查数据，没校验这条数据属于当前用户”。测试时用两个账号，互相改对方的 id 试访问。修复：所有数据访问都加”当前用户=数据所有者”的校验，或基于会话隐式确定用户而非信任参数。
常见坑（再补充）
- 只信前端传的值：金额、数量、用户标识绝不能信客户端，必须服务端算和校验。
- 忽略并发：单测没问题，并发一上就超卖，要用压测/并发工具验证。
- 流程步骤不绑定会话：任一步可跳过就成大漏洞。
- 把逻辑漏洞当功能问题：它常表现为能薅羊毛，本质是安全风险。
进阶（再补充）：修复思路
核心：关键决策在服务端做，且对每次操作校验权限与边界。金额服务端算、库存原子扣减、操作加幂等 token 防重放、流程间用服务端状态机绑定、异常频率做限流风控。测试时把”业务流”当攻击面，用”如果我是用户怎么钻空子”的视角走查。逻辑漏洞无通用补丁，靠逐业务梳理。
小测验（再补充）
- 问题1：超卖怎么修？答案：用数据库原子更新或加锁，如 WHERE stock>0 再扣减。
- 问题2：IDOR 是什么？答案：用客户端标识直接查数据却没校验归属，导致越权。
- 问题3：逻辑漏洞为什么扫描器难发现？答案：无报错无注入，靠业务流程钻空子，需人脑走查。
这一篇你该记住的
逻辑漏洞利用业务规则疏漏，在合法功能里做非法事，难被自动化扫描。典型：水平/垂直越权（后端没校验当前用户权限）、支付改价/改数量/跳步、未授权访问、弱口令爆破、验证码绕过、任意文件下载（目录穿越）。测试靠画流程图、找”信任前端”处、改参数/重放/并发。防御核心是：服务端重算重校验、统一鉴权、幂等、强口令+限流。
逻辑漏洞是”业务层的错”。下一篇 JWT 渗透 聚焦一个具体认证机制：那张”签过名的令牌”若能被绕过或伪造，你就能伪装成任意用户。