【Web安全】Portswigger 业务逻辑漏洞 Lab: Insufficient workflow validation 实验：工作流程验证不足

目录一.实验环境二.工作流程验证不足账户登录观察请求漏洞分析漏洞利用三.小结一.实验环境实验室工作流程验证不足 |网络安全学院https://portswigger.net/web-security/logic-flaws/examples/lab-logic-flaws-insufficient-workflow-validation二.工作流程验证不足账户登录观察请求首先登录账号添加皮夹克到购物车观察burpsuite请求没有什么很异常的地方。漏洞分析观察题目。它告诉我们事件顺序做出了错误的假设那我们先用自己的100购买一下随便一个商品付款这里我们仔细观察一下请求发现在付完款之后会出现两个请求一个checkout一个order-confirmed。order-confirmed是验证购买是否为真也就是说是否购买成功。但是这里并没有对买的物品数量和种类进行验证。那我们猜想是不是可以买一件皮夹克点击place order再发送一遍这个请求是否会完成购买。漏洞利用添加一个夹克到购物车点击购买出现余额不足提醒。我们再将刚刚的order-confirmed放入到repeater里面点击发送。发现购买成功。三.小结该实验室的漏洞源于应用程序对采购工作流的顺序和状态校验不足。系统错误地假设用户会严格按照“添加商品 → 前往结算 → 完成支付”的线性流程操作但实际并未对订单状态进行有效验证。攻击者可以先购买一件廉价商品以获取合法的订单确认请求GET /cart/order-confirmation?order-confirmationtrue随后将该商品从购物车移除替换为目标商品如价格超出账户余额的“Lightweight l33t leather jacket”最后在Burp Repeater中重放之前捕获的订单确认请求。由于服务端仅凭order-confirmationtrue参数即确认订单而未重新校验购物车内容与当前用户余额是否匹配导致订单在不扣除任何金额的情况下完成。为防范此类风险首先应在服务端对每个关键操作步骤进行严格的状态校验确保订单确认操作必须在前序“结算”步骤成功完成后才能执行杜绝直接跳转访问确认页面的可能其次订单的最终确认必须具有原子性——在确认环节应重新计算购物车总价并校验账户余额确保操作发生时所有业务规则仍然满足同时绝不能信任客户端提交的状态参数如order-confirmationtrue所有业务决策必须基于服务端当前的会话状态和数据库中的真实数据进行判断此外应对订单状态转换实施全面的日志记录与监控当发现订单确认请求与前置结算步骤缺失或时间顺序异常时及时告警最后在设计工作流时应遵循最小信任原则对每个独立操作均进行完整的权限与业务规则校验而非假设用户会按预期顺序执行。