合规声明
本文所有内容仅用于网络安全合规学习、漏洞报告写作方法与授权范围内的合规研究。全文不含任何针对特定目标的攻击载荷、可执行利用代码或绕过代码。文中所有案例均为已授权范围内的经验总结，涉事方信息已做处理。
一、先说那三次驳回
我写漏洞报告写过三次被驳回，三次理由不一样。
第一次：厂商说，这不在我们收录范围内。
第二次：厂商说，这个问题我们早就知道了。
第三次最难受——审核员说：「你这里写的危害，是你的推测吗？」
★ 我当时才意识到，我那份报告里最有力的三段话，全是我编的。
不是编造事实。是我把「如果攻击者能走到这一步，就会造成什么」写得像「已经造成了什么」。
二、我原来是怎么写危害的
先说我犯的是什么错，因为它很常见。
我原来写危害是这样：
攻击者可以构造恶意请求，篡改任意用户的订单数据，
进而造成业务数据泄露和资金损失。
这句话读起来很有力。它有完整的因果链：从入口，到动作，到后果。
★ 但它整条链都是假设。
我实际验证过什么？只验证了「这个接口没有校验对象归属」。「篡改任意用户的订单」这一步我没做，「造成资金损失」这一步我连业务逻辑都没看。
审核员那句「这是你的推测吗」，问的就是这个。
危害链条上每一环，我都没走通，我却把它写成了已完成的事实。
三、★ 为什么这种写法反而会被驳回
我一开始以为审核员不认，是因为他们看不出我的技术含量。
完全反了。
后来有人跟我说了实话：审核员一天要看几百份报告，绝大多数都被秒拒。他们要的不是你多聪明，是你写的能不能直接拿去修。
一份写「可以造成资金损失」的报告，工程师看到之后的第一反应是：「这是真的吗？」
而我写不出证据，因为我没验过。
所以那份报告的价值，比一份老老实实写「我验证到这一步，后面的路径我推测存在，但没复现」的还低。
★ 后面那份工程师能直接开工：先按你说的确认一下归属校验的漏洞是不是真的。前一份他只能先去查是谁写的这份报告。
四、我改掉的习惯：把「已证实」和「推测」分开写
这是我这三次驳回换来的一条规矩，很土但管用：
★ 我现在写危害，只写三句：
第一句 我实际做了什么操作（带证据）
第二句 我看到了什么结果（带证据）
第三句 我认为可以往下走，但没验（明确标注这是推测）
举个改写前后的对照。
改写前（我原来那样写）
攻击者可通过修改 orderId 参数越权读取任意用户订单，
导致用户隐私信息泄露，危害等级高。
改写后（我现在这样写）
我用账号 A（我自己的）请求 /api/orders/10086，
该订单不属于账号 A。
接口返回了完整的订单内容：收货人姓名、手机号、地址、商品明细。
★ 已证实：接口缺少对象归属校验，A 能读到 B 的订单。
关于影响范围，我只抽了3 个订单号做了对照，均可读取，
未做全量遍历，因此「可读取全平台订单」这句是推测，不是实测。
我推测的影响是订单信息泄露。但我无法证明这会造成
资金损失——我看了下单流程，支付环节在另一个系统，
是否可利用我判断不了。
★ 你看，改完之后篇幅反而更长，但每一句都能被验证。
而最关键的是最后那句：「我判断不了」。
审核员看到这一句，反而会认你。因为你说的是「我知道我的边界在哪」，而不是「你按我说的修」。
五、★ 三条被驳回的理由，其实是一件事
我复盘那三次驳回，发现它们是同一件事的三个面。
驳回 1：不在收录范围内
→ 我没确认边界就开始测
驳回 2：已知的风险
→ 我没查历史提交，直接当新发现报
驳回 3：危害是推测
→ 我没走完危害链就开始写
★ 共同点是：我都在「确认工作已完成」之前就开始往下走。
测之前没看收录范围。报之前没查重复。写之前没验危害。
这三个动作，本质上都是同一个动作：往前推之前，先确认一下自己站在哪。
我后来把这三个动作固化成了一个前置清单，每份报告动手前先过一遍：
□ 这个目标在不在收录范围里（收录页面截图，不是凭印象）
□ 这个问题我报过吗、别人报过吗（查历史提交记录）
□ 我写的每一句危害，能指到哪张截图 / 哪次请求
指不到 → 删掉或者明确标注「这是推测」
□ 危害链上还有几环我没验（写清楚，比藏着好）
★ 最后一条是我被驳回三次才补上的。以前我认为「诚实标注推测」会削弱报告的分量，后来发现反过来——不标注才是削弱。
六、★ 顺便说一件我原本没打算说的事
写这篇之前我顺手搜了一下，发现我这套认知的外面已经有一整片。
搜到的英文材料里，最扎眼的一条是一组数据：某数据库项目在四天内被提交了六个 CVE，其中一个 CVSS 打到 9.8。后续有人把那几份报告对应的代码版本构建出来、打开内存检测工具跑了一遍 PoC，结果六个都没能复现，报告里引用的函数名有的压根不存在，引用的行号超出了文件总行数。
那批报告最后被标记为「不可复现，明确不是真实缺陷」。
★ 我看到这件事的时候在想：我那三次被驳回，跟这个是同一个毛病。
区别只是规模——我写的是一份报告，那边是一批。
而它们的共同点更扎心：一份报告要被人证伪，成本远高于它被写出来的成本。
所以在安全这个领域，「大概是这样」这句话的代价特别高。
七、如果只让我留一条
报告里每一句「能造成 XX」，你都要能回答「这张截图在哪」。
答不上来就删掉，或者老实写成「这一点我没有验证」。
★ 不是因为诚实能加分。是因为不诚实的那些，会让你本来能过的报告也一起被驳。
附：我这三份被驳回的问题，今天会怎么处理
我把它写出来，是因为我觉得这个部分比方法论更实在。
1.不在收录范围内
→ 这条我认。收录范围应该以官方页面的截图为准，
我当时是按「这个域名解析到他们的 IP」判断的
→ 教训：技术上属于你，不等于被授权测
2. 已知的风险
→ 这条我不认，但也不打算再报
→ 教训：查历史提交应该在动手测之前，不是被驳回之后
3. 危害是推测
→ 这条我完全认
→ 教训：危害链上没走通的环节，别用陈述句写
★ 第 3条我写完之后重做了一遍，审核这次过了。
不是因为技术变好了，是因为我把「我知道的」和「我猜的」分开了。
本文为个人授权范围内的漏洞报告写作复盘，涉及的案例均已获授权并做过信息处理，不含任何针对具体目标的技术细节。
