漏洞公告团结互助，让我们共同进步！

当前位置：主页 > 技术资讯 > 网络安全 > 漏洞公告 >

我们的优势： 10年相关行业经验，专业设计师量身定制设计师一对一服务模式，上百家客户案例！企业保证，正规流程，正规合作 7*24小时在线服务，售后无忧

PayPal登录界面高危漏洞:分析身份验证机制，通过请求验证码质询服务端（reCAPTCHA challenge），获取注册邮箱和明文密码

文章来源：重庆网络安全围观次数：

分享到:

摘要：PayPal登录界面高危漏洞:分析身份验证机制，通过请求验证码质询服务端（reCAPTCHA challenge），获取PayPal注册邮箱和明文密码。

面对测试目标，如果您是第一个关注它并进行测试评估的人，那么详细而全面的检查无疑会发现一些安全问题，尤其是已经形成并持续运行的某些代码。能够找到此应用程序功能中的安全漏洞至关重要。在本文中发现了PayPal用户经常使用的登录框架中的高风险漏洞。让我们来看看。

在研究PayPal的身份验证机制时发现auth身份验证页面上的JavaScript脚本文件（recaptchav3.js）包含CSRF token和会话ID（Session ID），如下所示：

这立即引起了注意，因为攻击者可以通过各种方式检索有效javascript文件中存在的任何类型的会话数据。例如，使用跨站点脚本包含（XSSI），攻击者可以使用嵌入HTML <script>的网页包含恶意跨域脚本，然后使用此恶意跨域脚本绕过边界进行窃取用户存储网站上的敏感信息。

由此进行了一个简单的测试，测试发现跨站点脚本漏洞（XSSI）确实存在。尽管每个请求中都会有一个JavaScript模糊处理方法来随机化变量名称，但是敏感的用户token仍将出现在我们之前期望的位置。如果添加额外的材料，则可以完全实现敏感信息的检索提取。

但是，安全问题的好坏取决于可以实施哪种安全威胁。因此，利用上面的_csrf和_sessionID发现，开始分析它们，试图找出它们的特定用途以及可以在何处使用。

深入分析

在上述PayPal身份验证请求中多次替换CSRFtoken值（_csrf）之后，无法使用此CSRF令牌实施经典的跨站点请求伪造攻击（CSRF）。同样，替换_sessionID值也无法模拟受害者。

接下来回到上一个recaptchav3.js继续分析_csrf和_sessionID的特定用法。之后来到PayPal主要安全机制之一的安全挑战发起功能点的防暴力枚举处。大多数PayPal服务都使用了功能，但是仍然将注意力集中在PayPal的主要登录框架上。

因为：在几次尝试登录失败之后，PayPal会向用户发出验证码质询reCAPTCHA challenge，然后继续登录以验证当前尝试登录的对象是人类还是暴力枚举的机器人。但是，这种功能实现通过发现其中的隐藏信息而使我感到惊讶。

如果PayPal检测到可能的暴力登录尝试，则在下一次登录尝试之前，PayPal登录界面将弹出Google Captcha输入提示。如果最终由用户输入验证码，它将被发送到PayPal。服务器/ auth / validatecaptcha启动以下HTTP POST请求：

可以看出，请求正文包含我们熟悉的_csrf和_sessionID。此外，还有两个具有较大值的参数jse和captcha。

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

这样，攻击者可以在适当的时候通过社交工作者或网络钓鱼方法与受害者形成某种交互，并可以获得上述令牌信息，例如_csrf和_sessionID。使用这些令牌信息，auth / validatecaptcha会发起验证码安全性挑战。如果受害者成功登录，则最终质询响应中返回的信息将包括受害者的注册电子邮件地址和明文密码信息。在真实的攻击场景中，攻击者只需制作一个恶意页面（类似于网络钓鱼页面），以使受害者单击访问，即可模拟PayPal身份验证的重复尝试，并致电PayPal的验证码挑战（Google Captcha），然后质询响应消息可用于获取受害者的PayPal登录密码。

最后，回到对/ auth / validatecaptcha的HTTP POST请求。查看两个参数jse和captcha的实际效果，发现：

jse根本不扮演验证角色；

recaptcha是Google提供的reCAPTCHA验证码质询。它与特定的用户会话无关。无论人机验证如何，它都会接受与其匹配的任何有效输入令牌。

利用

总而言之，除了Google的验证码挑战解决方案之外，为了成功利用上述漏洞，将所有内容结合起来进行了PoC验证。整个PoC验证包括两个步骤：

1.使用跨站点包含漏洞（XSSI）在受害者的会话中获取令牌信息，例如_csrf和_sessionID，然后使用这些令牌信息在受害者的浏览器上启动用于PayPal身份验证服务器/ auth / validatecaptcha的POST。要求模拟暴力破解猜测登录尝试，以触发PayPal的验证码安全性质询机制；

2.一旦受害者成功登录到PayPal，上一个到/ auth / validcaptcha的请求响应消息将包含受害者的注册电子邮件和用于登录PayPal的明文密码。设计的PoC中，此敏感信息显示在页面上。整个PoC的最后一步是要求Google获得新的reCAPTCHA token。