利用漏洞攻击网站

2017年，利用漏洞一位安全研究员在Twitter上发了一条推文，攻击配图是网站某电商网站的商品页面，价格显示为-1元。利用漏洞他下单了。攻击订单通过了。网站这件事后来被写进多个安全会议的利用漏洞PPT里，成为逻辑漏洞的攻击经典案例。

漏洞这东西，网站不是利用漏洞只有二进制溢出、SQL注入那种听起来很"黑客"的攻击才算。大部分真实攻击，网站靠的利用漏洞是对业务逻辑的理解，而不是攻击对底层代码的爆破。

漏洞从哪来

写代码的网站人假设用户会按预期操作。比如一个修改密码的接口，开发者想的是：用户输入旧密码，验证通过，输入新密码，提交。但攻击者想的是：如果我把请求里的用户ID改成别人的呢？如果我省略旧密码字段呢？如果我直接调用最后一步的接口呢？

这些假设的崩塌，就是漏洞的诞生。它不需要你懂汇编，只需要你比开发者多想一步。

我见过一个案例。某平台找回密码功能，第一步验证手机号，第二步验证短信验证码，第三步重置密码。三步各自独立，服务端在第三步没有校验前两步的token是否属于同一个会话。攻击者可以拿自己的手机号通过第一步，拿别人的验证码通过第二步——只要他能收到那个验证码。当然他收不到，但如果验证码是四位数字且没有尝试次数限制呢？

这就是逻辑漏洞的典型面貌：每个环节单独看都没问题，串起来就出事了。

攻击者的视角

一个有意思的现象：很多漏洞的发现者并非安全专家，而是普通用户。他们只是"手滑"了，或者出于好奇改了改参数，然后发现网站的反应不对劲。

攻击者做的事情其实很朴素。打开浏览器的开发者工具，看每个请求的参数。把数字加一，把用户ID换成别人的，把价格改成0.01，把数量改成负数。观察返回结果。如果返回了别人的数据，或者订单金额变了，那就是一个洞。

有个朋友做过一次授权测试。目标是一个后台管理系统。他登录自己的低权限账号，抓包，把请求里的role字段从"user"改成"admin"，重放。页面刷新后，他看到了管理员菜单。整个过程不到两分钟。没有工具，没有脚本，只有一个改包的动作。

防御为什么难

逻辑漏洞没法靠WAF（Web应用防火墙）挡住。WAF看的是请求特征，而逻辑漏洞的请求长得和正常请求一模一样。一个把价格改成0.01的请求，在WAF眼里和把价格改成99.99的请求没有区别。

防御只能靠代码层面的严谨。每个接口都要做权限校验，每个参数都要做边界检查，每个状态转换都要验证前置条件。问题是，这些检查写起来枯燥，测试起来麻烦，而且不影响功能上线。产品经理催进度的时候，第一个被砍的就是这些"看不见"的代码。

更麻烦的是，业务逻辑本身在变。今天加一个优惠券功能，明天改一下积分规则。每次变更都可能引入新的逻辑漏洞。安全团队不可能审查每一行代码。

一些真实数据

OWASP（开放式Web应用程序安全项目）把"失效的访问控制"列为2021年Web应用安全风险的第一位。这个类别里大部分就是逻辑漏洞。某漏洞平台2022年的报告中，逻辑漏洞占提交总量的37%，仅次于信息泄露。

这些数字说明一件事：逻辑漏洞不是边缘问题，它是主流问题。

但修复率呢？我观察到的现象是，逻辑漏洞的修复周期普遍比技术漏洞长。SQL注入可能一个补丁就解决了，逻辑漏洞需要改业务流程、加校验、重新测试。有时候开发团队甚至不认为这是个漏洞——"用户怎么会想到改这个参数呢？"

他们会的。总有人会。

写代码的人该想什么

每次写接口的时候，问自己三个问题：这个请求是谁发的？他有没有权限做这件事？他传的参数如果是我意料之外的值会怎样？

这三个问题不需要安全背景就能回答。需要的是习惯。

一个我认识的后端开发者，他在每个接口的入口处都加了一行日志，记录当前用户ID和请求的用户ID。如果两者不一致且当前用户不是管理员，直接拒绝。这行代码他写了三年，拦住了至少四次越权尝试。不是因为他聪明，是因为他被坑过一次。

被坑过就会记住了。可惜的是，很多人还没被坑过。