今年1月，作者向Goole提交了一个关于reCAPTCHA验证码绕过的漏洞，该漏洞的绕过方法是需要web应用通过 reCAPTCHA 以一种不安全的方式来处理，然后发送到/recaptcha/api/siteverify的请求。当遇到这种情况是，攻击者都能绕过reCAPTCHA的安全验证机制。目前，谷歌从reCAPTCHA API的顶层接口上对这个漏洞进行了修复，且不需要对Web应用程序进行任何修改。本文将介绍如何通过HTTP参数污染绕过RECAPTCHA机制。

　　reCAPTCHA是Google提供的一项免费验证服务，可允许web应用开发者将验证码认证（CAPTCHA ）机制添加到他们的自主网站当中。reCAPTCHA是一项非常复杂的服务：会根据已存在的cookies来选择信任用户，或通过用户手动地去完成一些它提供的识别测试。接下来要介绍的是发现漏洞的情况。

　　当Web应用要测试用户时，，Google会提供一个图像集并使用Java代码在浏览器中显示，如下图：

　　当用户点击验证码CAPTCHA进行“验证”（Verify）时，就会触发一个指向网站的HTTP请求，该请求大致如下：

　　收到请求后，web应用程序需要向Google的reCAPTCHA API发送一个请求来验证用户的响应：

　　HTTP参数污染在客户端和服务器端之间几乎无处不在，相关的风险很大程度是取决于上下文，在某些特定的情况下，很可能会导致数据泄露。但大多数情况下是处于低风险的。

　　绕过reCAPTCHA认证需要web应用中存在HTTP参数污染，该项要求大大降低了Google对此漏洞报告的严重性。易受攻击的Web应用程序示例如下所示：

　　谷歌的reCAPTCHA API 始终使用请求中的第一个secret参数，并忽略第二个。严格来说，这不是一个reCAPTCHA API 本身存在的漏洞，但存在被利用的网络风险。

　　Web开发人员需要用自动化的方法来测试他们的应用程序，为此Google提供一种简单的方法在临时环境“禁用”reCAPTCHA验证。这可通过Google说明文档来参考。总之，如果要禁用reCAPTCHA验证，必须要使用编码网站和密钥：

　　如果web应用存在http参数污染漏洞，并且该url是通过在secret参数之前拼通过添加response参数来构建的，则攻击者可以绕过reCAPTCHA验证。请注意，我正在向易受攻击的Web应用程序发送特定响应，其中包含：

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

　　而Google决定在他们的REST API中修复该问题，作者认为这是明智的举措。虽然Google给出的解决方案是十分简单的。具体如下：如果/recaptcha/api/siteverify的HTTP请求包含两个相同的参数，就会返回一个错误的消息。

　　通过这种简单的方法，就可以保护易受HTTP参数污染攻击和reCAPTCHA绕过攻击的Web应用程序，并且不需要更新任何补丁。

　　第一，Web应用程序在reCAPTCHA url创建时存在HTTP参数污染漏洞：Github搜索显示，有60％集成有reCAPTCHA验证方式的Web开发架构会受到HTTP参数污染攻击。

　　第二：易受HTTP参数污染攻击的Web应用先要创建具有响应参数的URL，然后在创建secret参数，即：“response=…&secret=…”。这时候就会出现大多数应用使用的是“secret=…&response=…”的奇怪现象。因此作者猜测可能是因为Google文档和代码示例也是这种做法，所以很多人直接参考了。不然的话，该漏洞将会影响更多的网站。而GitHub搜索显示只有5％到10％的reCAPTCHA验证机制存符合这种情况。

　　因此，如果在实战中利用这一点怎么在谷歌翻墙，那么只有约3%使用reCAPTCHA的网站存在这个漏洞，这似乎还是比较乐观的数字概率，毕竟比其他漏洞的风险少了很多。

　　 作为开发者: 切勿使用字符串连接来创建查询字符串。使用字典存储键和值，然后进行url编码。