在测试报告中复现漏洞

过去几个月中，我三次被客户要求重新测试先前的发现，以验证漏洞是否已成功修复。其中一份报告出自我手，另外两份则由其他测试人员完成。

对于我自己的报告，我已完全不记得测试细节。阅读报告提供了一些线索，但幸运的是，我在客户文件夹中留下了完全设置好的测试工具，可直接用于漏洞验证。另外两份报告中，有一个涉及我从未听说过的漏洞，甚至在Google上也找不到相关信息。最终我联系到原始测试人员，发现只需一个简单工具和一行命令行脚本即可完成复验。最后一个问题是我已知的，但报告提供了出色的复现指南，即使不了解该漏洞的人也能逐步操作。

这引发了我的思考：客户收到报告后做了什么？他们成功复现问题了吗？甚至理解问题了吗？如果这些客户没有免费复验选项，他们是否会实施建议的修复措施（其中一份报告根本没有修复建议），然后假设按照说明操作就完美解决了问题？考虑到修复人员很难分配时间实施修复，我怀疑他们中很少有人会主动寻找测试方法并准备相应工具。

如何改进？显而易见的答案是包含完整的漏洞复现步骤。这对于基本XSS漏洞很有效——只需提供注入字符串和输入位置说明——但对于更冷僻的漏洞（如主机接受ICMP重定向或弱SSL密码套件）则远远不够。

冷门漏洞通常由Nessus等工具检测到。坦白说，作为测试人员，我们通常不知道如何手动测试它们，只是采信Nessus的结果。这在低级漏洞上尤其常见：正常测试中没有时间手动验证，也不值得业余时间深入研究。如果客户有漏洞扫描器，可以建议他们重新运行直到问题消失，但据我经验，拥有扫描器的客户很少。这意味着我们必须找到简单复现方法，尽可能减少对标准IT部门没有的工具的依赖。

以弱SSL密码套件为例，这对测试人员很容易验证：自动化扫描器会检测并列出启用项，或者使用Qualys SSL Labs网站专门测试SSL问题。但我们不能只告诉客户运行自动化扫描器，有多少雇主会因报告中包含竞争对手网站链接而责备测试人员？是否有易于安装的Windows工具完成此测试？也许有，但我从未费心寻找，因为不需要。

我希望在此给出完美答案，提供无需动手即可测试报告中所有内容的脚本，但事实并非如此。我刚开始思考这个问题，解决方案很少。对于常见漏洞，我将编写测试指南并添加到问题库中。部分需要编写脚本提供给修复人员，并在可能时公开。对于冷门漏洞，我将逐个处理。但潜在问题是：一旦报告中包含部分漏洞的复现步骤，没有步骤的漏洞会显得突出，专注的修复人员为验证所有问题已解决，会回来索要缺失步骤。这意味着如果未在测试分配时段记录所有内容，我将不得不为其他客户工作时编写这些步骤，更严重的是，可能无法访问所需漏洞系统来设计步骤。如果我必须构建一个易受ICMP重定向攻击的系统来编写手动验证步骤，工作量将巨大，而对于无法获取的软件中的漏洞，这根本不可能。

我很想知道其他人如何处理这个问题，以及有多少人在报告中包含此类信息。我将在Pauls Security Weekly邮件列表发起讨论，如果您尚未加入，请参与并发表评论。如果获得良好反馈，我将根据讨论内容撰写后续文章。