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

近期，安全研究者Alex Birsanl对PayPal登录界面的身份验证机制进行分析，发现了其中一个隐藏的高危漏洞，可以通过请求其验证码质询服务端（reCAPTCHA challenge），在质询响应消息中获取PayPal受害者的注册邮箱和明文密码，危害严重，漏洞最终获得了PayPal官方$15,300的奖励。

漏洞前言

当我们在做漏洞测试时，相对于那些显而易见的功能应用来说，我们还会去关注那些未知资产或模糊端点的服务，有时候这种犄角旮旯服务产生的漏洞同样至关重要，影响关键。

在面对测试目标时，如果你是第一个关注它并对它开展测试评估的人，那么细致全面的检查无疑会发现一些安全问题，尤其是一些代码已经成型且处于持续运转的应用，若能在这种应用功能中发现安全漏洞，将会是非常重要非常危急，且收获颇丰的。本文中，作者就在PayPal用户经常用到的功能点 – 登录框架中发现了一个高危漏洞，我们一起来看看。

最初研究

我在研究PayPal的验证机制时，发现其auth验证页面的一个javascript脚本文件（recaptchav3.js）中，包含了一个CSRF token和一个会话ID（Session ID），如下：

这马上引起了我的注意，因为在有效javascript文件中存在的任何类型的会话数据，都有可能被攻击者以各种方式检索获取到。如用跨站脚本包含（cross-site script inclusion，XSSI)，攻击者可以用一个嵌入了HTML<script>的Web页面包含进恶意跨域脚本，然后通过该恶意跨域脚本绕过边界窃取用户存储在网站中的敏感信息。

由此，我进行了一个简单测试，测试发现我猜测的跨站脚本包含漏洞（XSSI）是确定存在的。尽管每个Request请求中都会有一个javascript混淆方法去随机化变量名，但其中敏感的用户token还是一样会响应出现在了之前我们预计的位置，如果额外加点料，完全能实现对其中敏感信息的检索提取。

然而，一个安全问题的好坏在于你能用它来实现怎样的安全威胁。因此，有了以上 _csrf 和 _sessionID的发现，我立即着手对它们进行分析，想搞清楚它们的具体用途和可利用之处。

深入分析

经过无数次对上述PayPal身份验证请求中的CSRF token值（_csrf ）的替换，之后，我认为用这个CSRF token不可能实现经典的跨站请求伪造攻击（CSRF），同样，替换_sessionID值也不能实现对受害者的冒充。

接下来，我回到了之前的recaptchav3.js中继续分析 _csrf 和 _sessionID的具体用途，之后，我顺藤摸瓜来到了PayPal主要安全机制之一的安全质询发起功能点的防暴力枚举处，虽然该功能用于大多数PayPal服务中，但我还是把关注点聚集到了PayPal的主登录框架中。

因为：如果经过数次的登录失败尝试，之后，在继续登录之前，PayPal会向用户发起一个验证码质询（reCAPTCHA challenge），以验证当前尝试登录的主体是否是人还是暴力枚举的Robot。然而，就是这样一个功能实现，却让我发现了其中隐藏的信息，让我有点吃惊。

如果PayPal一旦检测到可能的暴力登录尝试，那么，在下次登录尝试之前，PayPal登录界面会弹出一个Google验证码（Google Captcha）输入提示，如果最终该验证码由用户输入完成，那么就会向PayPal服务端/auth/validatecaptcha发起一下如下的HTTP POST请求：