网站存在逻辑漏洞整改报告

上周三凌晨两点，网站安全组例行扫描时发现商城订单接口有个诡异现象：用户A的存逻购物车能通过修改URL参数直接读取用户B的收货地址。这不是辑漏什么高深攻击，就是洞整个典型的水平越权——前端传了userId，后端没做二次校验。改报告我盯着Burp Suite里的网站响应包看了五分钟，地址、存逻电话、辑漏姓名全明文返回。洞整那一刻后背发凉，改报告这功能上线快半年了。网站

漏洞定位很快。存逻`/api/v1/order/address?辑漏userId=123` 这个接口，鉴权只查了token有效性，洞整没比对token绑定的改报告用户ID和请求参数里的userId。代码里注释还写着“临时方案，后续优化”。临时了六个月。测试环境复现时，我用自己账号改了同事的ID，他的家庭住址直接弹在屏幕上。同事脸都绿了。

修复方案其实不复杂。后端加一层拦截器，从token解出当前用户ID，强制覆盖任何请求参数里的userId字段。前端传什么都无所谓，后端只认token。同时把接口返回的地址信息做了脱敏，非本人查询只返回省市区，详细门牌隐藏。改动量不到八十行代码，但影响面覆盖了订单、购物车、个人中心三个模块。

真正麻烦的是数据追溯。漏洞存在期间，日志里没有记录谁查了谁的地址。我们翻了近三个月的访问日志，发现有几个异常IP在凌晨频繁调用该接口，每次userId都不同。虽然不能确定是恶意爬取，但风险已经存在。最终决定对受影响用户发站内信提醒，并强制所有用户重新登录一次，刷新token绑定关系。

整改过程中还挖出一个连带问题。用户中心有个“最近浏览”功能，同样没做越权校验。用户能通过构造请求看到别人浏览过的商品列表。这个功能是运营后来加的，开发直接复制了旧代码，连漏洞一起复制了。两个漏洞同源，都是因为早期架构里“信任前端传参”的坏习惯。这次一并修了，统一走网关层做参数清洗。

上线前我们做了三轮回归测试。第一轮用自动化脚本跑越权用例，覆盖所有带userId的接口。第二轮人工抽查，模拟普通用户、商家、管理员三种角色交叉访问。第三轮找安全团队做渗透，他们用了半小时就找到了一个新的边缘接口——退款详情页没校验订单归属。又补了一刀。上线后监控了四十八小时，没有异常告警。

事后复盘，根因不在技术，在流程。代码评审时没人关注鉴权逻辑，测试用例只覆盖了正常流程，安全扫描工具没配置越权检测规则。现在改了规矩：所有涉及用户数据的接口，必须显式声明权限模型，评审时安全组有一票否决权。另外把越权检测加进了CI流水线，每次提交自动跑一遍。工具是开源的，配置花了半天，比出事后通宵强。

个人判断，这类逻辑漏洞比SQL注入更普遍，因为它不依赖技术深度，只依赖开发者的疏忽。一个参数没校验，就能把整个用户数据库暴露出去。修复成本极低，但发现成本极高——要不是那次凌晨扫描，可能到现在还挂着。安全这事，永远别信“临时方案”，要么别上，要么上完立刻补。