IDOR复测别只盯着读取接口

第一次复测 IDOR，我的思路特别朴素：初测报的是「能读到别人的订单」，那复测就只测读。读不到了，报告里写一句「已修复」，收工。

后来才反应过来，这个动作只证明了一件事——那个读接口被堵住了。可对象级授权从来不是挂在某一个接口上的事。

写操作是最容易被跳过的一类。原因也不难理解：验证写、删、导出这些动作，心理门槛比读高太多。要额外确认授权、要考虑数据被改坏了怎么回滚、要担心触发告警。于是初测时大家默契地绕开，复测时继续绕开。可偏偏这些动作造成的影响比读大得多。一个能改别人对象的接口，风险跟「多看到一个字段」根本不是一个量级。

所以我现在复测的顺序会调整。先重放基线请求，确认合法用户对自己的对象还能正常访问——修 bug 修出功能故障的情况真不算少见。再重放跨账号的对照请求，重点看返回的到底是明确拒绝，还是返回成功但内容为空，又或者字段结构变了。只改返回值不改授权逻辑，这种「表面修复」挺常见。

然后是那些容易漏掉的动作。更新、删除、导出、批量操作、管理动作，只要初测的授权范围覆盖到，复测清单里就该各有一条最小用例。如果这次确实没有授权，也把「未验证」老实写进报告，而不是让它看起来像「已验证通过」——这两者的差别，看报告的人未必分得清，但出事时一定分得清。

我自己还踩过一个坑：看到对方把自增 ID 换成了随机标识，就默认修好了。标识变难猜只是提高了猜测成本，服务端的归属校验没做，标识从日志、分享链接或者别的接口漏出来，照样能越权。更麻烦的是，这类「修复」在复测时最容易蒙混过关，因为它确实让原先的复现步骤失效了。

复测的条件得跟初测对得上：同样的两个账号关系、同样的自建对象、同样的请求路径，连判断依据都该是同一套——响应里的归属字段、返回结构、错误信息有没有透露对象是否存在。条件一换，结论就失去可比性，写出来的「已修复」也没什么分量。

说到底，复测不是确认某一个洞被堵上了，而是确认对象级授权这件事，在服务端的读、写、删、导各条路径上都真的落地了。少测一条，报告上那句「已修复」就得打个折。