运行 HTTP 的风险正在增加但可控

无论我们是否喜欢，HTTP 都是现代事实上的应用传输协议。 我们到处都使用它。 它与 IP 和 TCP 一样普遍存在，并且用途大致相同。 其唯一目标就是传输当今商业的数字黄金：数据。

无论数据是 JSON 还是 XML 还是 URL 编码的都无关紧要。 应用程序和设备使用 HTTP 与云端和数据中心本地的服务器和服务进行通信。

然而，与 IP 和 TCP 不同，HTTP 是一种基于文本的协议。 它具有高度灵活性，可以传输各种数据——从二进制到文本。 我们用它来传输数据、检索数据和收集数据。

攻击者可以随意使用它，因为如上所述，它是一种基于文本的协议，对于标头的扩展有相当宽松的规则，这些标头指定了从客户端期望服务器采取的操作（HTTP“方法”）到请求的资源（URI）到可以接受什么样的内容（“Accept”标头）的所有内容。 这些规则比较宽松，以实现可扩展性。

例如，引入X-Forwarded-For 标头是为了确保开发人员能够“看到”原始客户端 IP 地址。 在某些架构中——特别是中介充当完全代理的架构中——这些信息可能会丢失。 一些应用需要这些数据，因此开发人员（和网络供应商）通过引入自定义标头来扩展 HTTP 协议。 这是 HTTP 规范的一部分；它允许创新和引入新的行为和功能，而无需改变协议。 这是一件好事。

除非不是。

如果支持 HTTP 的服务器开发人员或负责保护依赖 HTTP 的应用的人员没有考虑到这种灵活性，那么这并不是一件好事。

以下是与 HTTP 相关的 CVE 的一个小样本，它们利用了 HTTP 标头中的漏洞：

老实说，通过已知的 CVE 搜索 HTTP 漏洞会返回一个过长的列表（并且包括各种各样的供应商和软件），我不会在这里重复。 其中很大一部分通常是通过滥用 HTTP 标头来触发的。

关于 Optionsbleed 的说明 

Optionsbleed 是最新出现的漏洞之一。 我之所以将它调出，是因为它存在于 Apache HTTP 本身中。 据 Netcraft 估计，目前“有超过 280 万台面向 Web 的计算机运行着Apache httpd的各种版本和衍生产品，占所有面向 Web 的计算机的 42.8%”，因此 Apache 中的漏洞会带来重大风险。 幸运的是，这个特定的漏洞是通过 HTTP 标头触发的，但也需要.htaccess文件中存在错误配置的Limits指令。 如果您有兴趣的话，Sophos 的这篇文章对复杂的技术细节进行了很好的概述。 TL;DR 的意思是，如果存在错误配置，攻击者可以通过 HTTP 方法标头利用 Apache 中的漏洞，并且（看起来）迫使服务器“泄露”属于其他人的数据。

现在，我已经说了这么多，所以我可以这样说：应用程序安全是一个堆栈。 该堆栈包括应用所依赖的平台（以及协议）。 像 HTTP。

我们需要更好地保护 HTTP 不被滥用来危害安全。 无论是数据泄露、DoS 还是远程访问都不是重点。 这些都是不好的影响。 我们需要更好地认识到 HTTP 是一个越来越受欢迎的攻击面。 基于文本的意味着客户端和 HTTP 服务之间的整个交互应该归类为用户输入。

这反过来又会鼓励采取包括消毒在内的安全策略 该输入。 是的，这意味着协议执行和清理上游（在到达潜在的易受攻击的 HTTP 服务器之前）。

这意味着Web应用防火墙或可编程代理应该位于任何面向公众的 HTTP 服务之前，并积极参与清理传入的 HTTP 请求。

其原因在于 Web 平台处理 HTTP 标头的方式，也就是说，在开发人员看到请求之前。 因此，我们不能把平台级漏洞归咎于开发人员和不安全的编码实践。

当然，修补是最终的解决方案。 假设您 (1) 在第一天就听说了该漏洞，(2) 在第一天就发布了补丁，并且 (3) 您愿意将可能未经测试的补丁部署到生产系统中。

你需要修补，不要误会我的意思，但是在披露、发现、可用性和应用之间存在差距。 这个漏洞就存在风险；这个风险就是一个很容易被利用的漏洞会被用来对付你。

倒数第二个解决方案是确保有一个系统（平台），您可以在其上部署即时补救解决方案，例如脚本或基于签名的扫描，以防止在准备修补时受到攻击。

清理入站数据和强制协议正确性应该是任何公司安全政策的重要组成部分。

HTTP 的风险越来越大，但如果您记住应用程序安全是一个堆栈，然后在该堆栈的每一层实施保护，那么它也是可控的。