PayPal验证码质询功能（reCAPTCHA Challenge）存在的用户密码泄露漏洞(2)

发起上述验证码质询（reCAPTCHA challenge）请求后，其后续的响应旨在将用户重新引入身份验证流程，为此，响应消息中包含了一个自动提交表单，其中存有用户最新登录请求中输入的所有数据，包括相关的电子邮件和纯文本密码（Plain Text Password）！！经解析后的HTML如下：

OMG，有了这些，攻击者可以通过社工或钓鱼方式，在正确时机范围内对受害者形成一些交互，就能获取上述的_csrf 和 _sessionID等token信息，有了这些token信息，再向/auth/validatecaptcha发起验证码安全质询，如果受害者登录成功，最终质询响应回来的信息中就会包含受害者的注册邮箱和明文密码信息。在真实攻击场景中，攻击者只需制作一个恶意页面（类似钓鱼页面），迷惑受害者点击访问，以模拟PayPal身份验证的反复尝试，去调用PayPal的验证码质询（Google Captcha），然后在其质询响应消息中即可实现对受害者PayPal登录密码的获取。

最后，我又回到对/auth/validatecaptcha的HTTP POST请求中，想看看jse和captcha两个参数的实际作用，分析发现：

jse根本没起到验证作用；

recaptcha是Google提供过来的验证码质询（reCAPTCHA challenge）token，它与特定的用户会话无关，无论人机验证，只要与其匹配的任何有效输入token，它都会接受。

漏洞利用

综上所述，除去Google的验证码质询解决方案以外，为了对以上漏洞进行成功利用，我把所有东西组合起来，制作了一个PoC验证。整个PoC验证包含两个步骤：

1、用跨站包含漏洞（XSSI）获取受害者会话中的_csrf 和 _sessionID等token信息，之后，利用这些token信息在受害者浏览器端发起针对PayPal身份验证服务端/auth/validatecaptcha的POST请求，形成暴力猜解登录尝试的模拟，以触发PayPal的验证码安全质询机制；

2、一旦受害者成功登录到PayPal之后，之前对/auth/validatecaptcha的请求响应消息中，将会包含受害者的注册邮箱和登录PayPal的明文密码。在我设计的PoC中，这些敏感信息会显示在页面中。整个PoC的最后步骤是去请求Google获取一个最新的reCAPTCHA token。