原创漏洞证明申报条件

原创漏洞证明（以下简称“PoC”）能不能被认定为有效申报，原创核心就一条：你的漏洞证明文件得让审核员闭着眼都能复现漏洞。别急着写长篇大论，证明先把这条刻脑子里。申报

我见过太多人栽在“演示视频”上。条件录了五分钟，原创鼠标晃来晃去，漏洞中间还切了屏去开计算器。证明审核员没耐心看，申报他只会按你提交的条件步骤文档一步步敲。步骤文档写三行，原创视频里点十下，漏洞这漏洞就算白报了。证明真正好用的申报PoC，文档里每个点击都有坐标，条件每个输入框都有前置条件，甚至要精确到“在Chrome 87版本，非隐身模式下，先登录普通用户账号，再访问/console路径”。

再说技术门槛。别以为弹个alert框就算数。现在CNVD和CNNVD的审核标准早提高了，单纯反射型XSS且无敏感操作交互的，基本会被打回。你得证明漏洞能造成实际危害——比如窃取管理员Cookie、篡改数据库内容、或者越权读取他人隐私文件。举个例子，我去年报过一个SQL注入，参数是数字型，报上去被驳回，理由是“该参数无法控制返回内容”。后来我加了个时间盲注的延时对比，并附上两次请求的响应时间差截图，才通过。

还有个容易忽略的坑：版本和环境的匹配。你拿某CMS 1.0版测出的漏洞，官方早修复了，但你申报时没写清楚版本号，审核员拿最新版一测，没反应，直接判定无效。正确做法是，在PoC里明确写出“受影响版本为1.0-1.2.3，在1.2.4版本中，由于增加了filter_var函数，该注入点已被封堵”。这种细节，比你在漏洞描述里吹十句“影响严重”都管用。

文件格式也别太随意。有人直接丢个txt文件，里面贴一段Python代码，连缩进都是乱的。审核员每天看几十份申报，他真没工夫帮你调试。我建议用PDF或Markdown，代码块高亮，请求包和响应包分开展示，关键位置用红框标出。你要是能把Burp Suite的原始请求包原样贴出来，再配上手工构造的恶意payload，那基本就稳了。

最后说点得罪人的话——别拿公开漏洞库的现成东西改个参数就提交。审核员手里都有漏洞库的索引，你抄来的CVE-2023-xxxxx，他扫一眼URL特征就能认出来。原创性不是说你非得挖个0day，而是你得证明你对这个漏洞有独立理解。哪怕同一个漏洞点，你换个新的利用链，或者发现了原PoC没覆盖的绕过方式，这都算原创。我有个朋友，就靠把某框架的SSRF漏洞从GET请求改成POST multipart方式触发，成功申报了原创证书——漏洞本身是旧的，但利用手法是新的，这就够了。

申报材料写完后，自己当一次审核员，按你的文档从零开始复现。卡壳超过两分钟，就回去改文档。要是你本人按文档操作都走不通，那审核员那边大概率也是直接打回。记住，漏洞证明的目标不是展示你多聪明，而是让一个完全不了解你代码的人，能无脑复现出结果。