HTTP参数污染漏洞绕过reCAPTCHA认证

HTTP参数污染

HTTP参数污染 "HTTP参数污染")几乎无处不在：从客户端到服务器端，不过，该漏洞的危害性却很大程度上取决于漏洞所在的上下文——在某些特定情况下，它可能导致危害巨大的数据泄露问题，但在大多数情况下，它只是一个低危漏洞。

reCAPTCHA绕过漏洞的前提条件，是相应的Web应用程序中存在HTTP参数污染问题。正是由于这个限制条件，导致Google严重低估了该漏洞的危害程度。

这里有一个包含reCAPTCHA绕过漏洞的Web应用程序示例：

其中，字符串连接用于构建url变量。

需要注意的是，如果向其发送这两个HTTP请求的话，会得到相同的响应：

reCAPTCHA API总是使用请求中的第一个secret参数，并忽略第二个secret参数。虽然这不是一个漏洞，但是，却可以被攻击者所利用。

Web开发人员需要以自动化的方式测试自己的应用程序，为此，Google提供了一种简单的方法来帮助开发人员在staging环境中“禁用”reCAPTCHA验证。这在谷歌的文档中有详细的记录和说明，简单来说，若想禁用reCAPTCHA验证，需要以硬编码的方式为site和secret参数指定如下所示的取值：

漏洞利用方法

现在，我们已经掌握了所有的要素，下面来看一看漏洞利用方法:

如果该应用程序存在HTTP参数污染漏洞，并且URL是通过在参数secret之前添加response参数得到的，那么，攻击者就可以绕过reCAPTCHA验证。

请注意，我们需要为含有该绕过漏洞的Web应用程序发送一个精心构造的response参数，其中包含：

当满足攻击条件时，web应用程序会向reCAPTCHA API发送以下HTTP请求:

请注意，该请求包含两个secret参数，第一个是由攻击者控制的（由于易受攻击的Web应用程序中含有HTTP参数污染漏洞），第二个是由应用程序本身控制的。鉴于reCAPTCHA API总是使用第一个secret参数，所以，该请求的响应总是：

因为上面的响应是由Web应用程序处理的，所以，攻击者将被授予相应的访问权限。

通过上游修复漏洞

实际上，Google是在其REST API中修复这个安全问题的，并且我认为这是一个非常明智的举措。其实，Google的修复方法很简单：如果/request/passpt/api/siteverify的HTTP请求包含两个具有相同名称的参数，则返回错误。

通过这种修复方式，我们无需给含有HTTP参数污染和reCAPTCHA绕过漏洞的应用程序打任何补丁，就能提供相应的安全保护：真是太棒了！

可利用性

要在Web应用程序中利用该漏洞，需要具备两个严苛的条件。首先，应用程序在构造reCAPTCHA url过程中存在HTTP参数污染漏洞：Github搜索显示，在集成了reCAPTCHA的Web应用程序中，约有60％的程序满足该要求。

其次，包含漏洞的Web应用程序需要先创建带有response参数的URL，然后再创建带有secret参数的URL，即“response=…&secret=…”。奇怪的是，几乎所有的应用程序都使用“response=…&secret=…”这种格式的URL。据我猜测，可能是由于Google的文档和代码示例就是这样做的，而其他人则直接复制了这种格式。 Google在这方面还是很幸运的——如果他们反过来这样做的话，这个漏洞会影响到更多的网站。GitHub搜索显示，只有5％到10％的reCAPTCHA实现方式符合这一要求。

因此，如果我想在野外利用这一漏洞的话，只有约3％的采用reCAPTCHA的网站会受到影响：这并不算太糟糕，因为与其他漏洞相比，这个占比还是很小的。

小结

对于开发人员：切勿使用字符串连接来创建查询字符串，而应该使用字典来存储键和值，然后对其进行URL编码。

对于应用安全专家：HTTP参数污染漏洞是你的制胜法宝。