内容摘要：Web攻防之业务安全实战指南 某电商平台双十一当天，黑产团伙用撞库得来的账号批量下单，把价值300万的优惠券套现。安全团队事后排查发现，攻击者根本没碰什么高深漏洞——他们只是把登录接口的验证码识别绕过

Web攻防之业务安全实战指南

某电商平台双十一当天，业务黑产团伙用撞库得来的安全账号批量下单，把价值300万的实战优惠券套现。安全团队事后排查发现，指南攻击者根本没碰什么高深漏洞——他们只是业务把登录接口的验证码识别绕过了，然后用代理池轮换IP，安全模拟正常用户行为。实战这个案例说明，指南业务安全的业务本质不是防黑客，是安全防“正常人”用非常规手段薅羊毛。

业务逻辑漏洞往往藏在最不起眼的实战地方。比如密码找回功能，指南很多开发图省事，业务把验证码直接放在响应包里返回。安全我见过某银行APP就这么干，实战攻击者抓包就能看到短信验证码，改个密码跟玩似的。还有个典型场景是越权访问——你登录A账号，把请求里的userID参数改成B的，就能看到B的订单、地址甚至支付记录。这种漏洞用扫描器扫不出来，全靠人工测。

最头疼的是“并发漏洞”。比如某积分商城，兑换商品时先检查积分够不够，再扣减积分。攻击者用脚本同时发20个请求，全部通过检查，最后只扣了一次积分。这问题出在数据库事务没做好，但排查起来要翻代码、看日志，比修个SQL注入麻烦十倍。我建议安全测试时专门写个并发脚本，对着所有涉及金额、积分、库存的接口轰一遍，准能炸出几个雷。

还有个反直觉的点——验证码不是越复杂越好。图形验证码搞得太扭曲，用户输错三次就骂娘，转化率掉得厉害。但简单了又防不住打码平台，几分钱一张全自动识别。折中方案是用滑块验证，配合行为轨迹分析，识别鼠标拖动速度、停顿位置，能挡掉90%的机器脚本。不过这招对模拟真人操作的攻击者没用，他们用Selenium加随机轨迹，照样能过。

说个我踩过的坑。某次测试一个优惠券系统，发现券码是纯数字自增的，从100001开始。我直接写脚本从100001遍历到1000000，把未使用的券全扫出来了。这漏洞低级到令人发指，但就是能上线，因为开发觉得“没人会这么无聊”。你看，业务安全最大的敌人不是技术高低，是“想当然”——总觉得没人会对自家业务动歪脑筋。

最后说点实际的防护手段。第一，所有涉及资金、权限的操作必须加二次校验，哪怕只是弹个二次确认框。第二，接口要设计幂等性，同一个请求重复提交只生效一次，这能防住大部分并发攻击。第三，做实时风控，监控单位时间内的操作频次、IP分布、设备指纹，异常行为直接触发人工审核。别指望一个WAF全搞定，业务安全是攻防双方在规则边缘的博弈，你得比攻击者更懂业务本身。