北京
这一步很安静，没有“发现零日漏洞”的戏剧性。它发生在我把授权范围的测试工具瞄准三个成熟开源项目之后——用黑盒方式重新发现了一个真实CVE级缺陷，一个藏在非显而易见攻击面上的缺陷。然后我选择不报告它，因为它已经是一个修复过的公开CVE。
没有漏洞利用，只有方法，以及几个公开的CVE编号。
我构建了一个授权范围的测试工具，由三部分构成。第一个部分是一个默认拒绝的出口范围锁，它会机械地拒绝所有未明确放行的流量。第二个部分是一个追加式账本，在数据层面强制执行人类签字机制——漏洞是否“确认”由人类把关，从来不由大语言模型决定。第三个部分是一套协调漏洞披露管线，它把可以自动化的步骤和必须保留给人来做的步骤切开。在这个基础之上，我用两个自己的账号进行自托管开源软件的黑盒测试，通过对比来寻找差异。没有攻击性侦察动作，没有未经授权的扫描，没有寻找受害者。只有一个我独自占用的自托管实验室，里面跑着合成数据。
我先从三个成熟目标的“水平越权主增删改查”攻击面开始系统性地攻击——两个任务管理器和一个无代码数据库，只问一个问题：“账号B能用ID读到账号A的对象吗？”结果是清一色的403，零发现。这不是失败，这才是正确的结果，因为正门恰恰是流行开源软件加固得最扎实的地方。真正重要的是能够诚实地记录下“这里什么都没有”。绿色不代表在工作；我每次都会前置一个A账号的对照组，用合法访问返回200加一个已知标记，所以这个“无发现”是在已经排除了误报的前提下得出的。正是这个前提，让后续的判断变得可信。
我的假设是这样的：真正的授权漏洞藏在那些不经过逐对象权限检查的代码路径里——聚合操作按分组查、关系扩展按关联记录或查找来查、派生读取走导出通知或订阅源、以及“预期内”共享机制里的泄露点。如果正门够硬，不要换目标，要换你瞄准的攻击面。
调整瞄准方向的第一轮就跑出了结果。针对一个无代码数据库的公开共享视图，一轮黑盒差异测试复现了两处过度暴露。第一处，视图中隐藏的一列通过聚合端点返回了它的原始值。第二处，来自未共享关联表的记录通过关系扩展端点被返回。决定性的线索是一个不一致之处：主行获取API严格强制执行了列隐藏，而辅助端点没有。“主路径执行了规则，辅路径没执行”——这不是装饰性发现，这是访问控制绕过的签名式特征。
然后我扔掉了我的发现。在喊出“零日漏洞”之前，我查了公开记录。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
