使用 MD5 进行一致性检查显然违反了CWE-327: Use of a Broken or Risky Cryptographic Algorithm。RFC-2387 提供的任何保护都因使用过时且不安全的算法而无效。

Rapid7 通过此建议降低了互联网的安全性。这个 BS“漏洞”是更无意义的噪音，淹没了真正的发现。Rapid7 对 RFC-2385 的盲目推荐使 HTTP 请求更难处理，从而使 Web 服务器更容易受到 DDoS 攻击。

我会向 Rapid7 投诉，并鼓励他们认真重新考虑这个 货物狂热的安全建议。仅仅因为它易于测试，并不意味着它是相关的。请 Rapid7 告诉您的客户这不是问题。

我的回答将是一个低调的版本：“他们建议我们使用为另一个用例设计的未加密的共享密钥身份验证方案。他们的建议是奇怪且无用的。没有 Web 浏览器能够生成所需的密钥每个 TCP 段的哈希值。”

毫无疑问，您在漏洞扫描器方面的经验远远超出了我的水平，而您对 TCP 复杂性的经验更是远超我。但也许我可以分享我与客户打交道的一般方法，他们查看漏洞扫描结果，看到项目旁边的黄色/橙色/红色图标，并做出非常关注的反应，却没有意识到那里没有真正的问题存在。

1. 解释说，虽然漏洞扫描程序有时在检测微妙但重要的问题方面表现出色，但有时它们对于发现根本没有任何实质性风险支持的问题也可能是绝对愚蠢的。

2. 解释为什么在这种情况下，这个项目根本没有实质性的额外安全风险。（注意：这整件事显然是假设不存在的，当然。）换句话说，解释为什么扫描仪是错误的，没有注意它。

3. 要么（a）解释你无论如何要如何纠正非问题，以便他们可以从扫描仪获得（表面上的）干净的健康单，或者（b）如果这不切实际，解释两者为什么这个问题实际上不能真正“解决”，以及他们如何记录（对于合规性的东西，他们的老板，无论谁/无论如何），在经过调查和思考之后，他们确信这个问题基本上只是一种误报。

听起来你可能有一个“但是......但是......昂贵的工具说那里有一个漏洞！” 客户。也许尝试一种策略来强调即使您可以以扫描仪希望的方式实现此校验和行为，这也会花费您大量时间（即他们的钱），甚至可能需要服务器停机时间。以我的经验，提及这些考虑因素通常足以让客户对生活在非脆弱性漏洞中产生新的接受感。反正我的两分钱。