利用领先经纪平台中的CSRF漏洞

qife122
4 阅读6分钟

利用领先经纪平台中的CSRF漏洞

几个月前，我在一个拥有超过1400万活跃用户的领先经纪平台中发现了一个漏洞。这是一个CSRF（跨站请求伪造）问题。众所周知，CSRF的影响完全取决于攻击者可以触发的操作的关键性和敏感性。

当时，我正在随机观看一个YouTube视频，视频中有人演示了如何使用该经纪商的API来构建一个用于算法交易的自动买卖订单机器人。观看过程中，我对身份验证流程，特别是第三方应用程序如何连接到经纪商的平台并获得代表用户进行交易的权限，产生了浓厚的兴趣。就在这时，情况开始显得可疑。

是时候深入研究并启动“猎犬模式”了：

插图转存失败，建议直接上传图片文件

为了理解背景：这个经纪应用程序允许用户连接他们自己定制的应用程序或其他第三方应用程序。因此，这些应用程序可以代表用户下达交易订单。

预期流程：

插图转存失败，建议直接上传图片文件

表面上看，这个身份验证流程很简单，但一旦你从安全角度审视它，情况就不同了。该网站在几乎所有经过身份验证的POST请求上都实现了Anti-CSRF令牌和其他控制措施——但这些保护措施在第三方应用身份验证流程中完全不存在。

以下是该流程的工作原理：

  1. 第三方应用程序向经纪商的后端API发送一个包含其 application_id 的初始请求。
  2. 经纪商的后端生成一个 session_id 并将其返回给客户端，同时返回一个“允许/拒绝”的同意页面。
  3. 当用户点击允许时，客户端会向后端发送另一个请求，其中包含：
    • session_id
    • 指示允许/拒绝的参数
    • 用户的cookie
  4. 这个请求缺失了CSRF验证。

目标： 通过利用这个缺失的CSRF验证，将我自己的恶意第三方应用程序连接到受害者的账户。

为了测试，我使用从我自己的攻击者账户生成的 session_id 创建了一个简单的CSRF表单。我将这个表单发送到我的第二个账户（扮演受害者）并提交。

结果呢？ 我的恶意第三方应用程序在未经受害者任何同意的情况下，自动连接到了受害者的账户。 这证实了攻击者可以简单地发送一个CSRF链接或自动提交表单，如果受害者点击了它，攻击者的应用程序将获得完全授权，可以进行交易和其他敏感操作。

我向他们报告了这个问题，得到的严重性评级是： 他们的回应： 接受了问题，但将其标记为低严重性，因为生成的 session_id 在5分钟后过期。

因此，攻击需要：

  • 生成一个新的 session_id
  • 将其嵌入CSRF表单
  • 发送给受害者
  • 并希望受害者在5分钟内点击

那么，我们能否让漏洞利用更快、更容易、更具可扩展性？

目标更新： 让漏洞利用更快、更容易、完全可扩展。

如果受害者打开一个攻击者控制的网站，攻击者的第三方应用程序应该自动连接到受害者的账户——无需点击、无需手动交互，并且它应该对任何访问用户都有效，而不仅仅是一个。

要实现这一点，我们需要两样东西：

  1. 一个有效的 session_id
  2. 一种自动将其嵌入CSRF流程的方法

我的第一个想法很简单： 直接代表受害者发送请求以生成一个新的 session_id，获取它，然后自动提交CSRF流程。 但这行不通——因为向经纪商后端发送的请求被浏览器的同源策略（SOP） 阻止了。

插图转存失败，建议直接上传图片文件

因此，我创建了一个概念验证（PoC），它：

  1. 启动一个恶意服务器，监听路由 (/)。
  2. 当有人访问该路由时，服务器从服务器端（而不是受害者端）向经纪平台的合法登录端点发出后端请求，以获取生成的 session_id。
  3. 它捕获登录重定向响应，专门寻找会话ID。
  4. 一旦找到会话ID，服务器会自动构建一个隐藏的HTML表单，伪装成交易平台的“授权”步骤。
  5. 受害者的浏览器被欺骗，从而：
    • 加载此表单
    • 使用 JavaScript 自动提交它

这导致了一次跨站请求伪造（CSRF）攻击，该攻击：

  • 迫使受害者的浏览器在用户不知情或未同意的情况下，授权一个攻击者控制的应用程序。

通过这种设置，任何访问攻击者控制网站的新用户都会被自动利用，攻击者的第三方应用程序将在不需要任何交互的情况下，持续累积新的受害者账户。每一次页面加载都意味着又一个交易账户被攻陷。

影响

一旦恶意应用程序获得授权，攻击者可以：

  • 下达买卖订单，
  • 滥用用户资金，
  • 并可能引发大规模的财务损失。

例如，攻击者可以强制所有被攻陷的账户购买同一只股票，制造人为需求并操纵市场。如果有足够多的受感染账户，这将变得极其危险。

最终，在提供了完整可用的PoC后，严重性等级得到了提升。

他们如何修复了该漏洞

为了修复这个问题，经纪商增加了一个额外的安全检查：

  • 当后端生成 session_id 时，会返回一个唯一的令牌。
  • 该唯一令牌专门映射到发起身份验证流程的用户。
  • 在“允许”请求期间，此令牌必须匹配。

由于这种绑定关系，攻击者无法再预先生成一个 session_id 并在CSRF攻击中重用它。攻击者无法获知特定于受害者的令牌，因此恶意应用程序的自动链接不再可能实现。 CSD0tFqvECLokhw9aBeRqtXyRn0lX+xpHdlLhI/WOecAJbuabhGDzexX6HlErYgcV9KrBOYn6zUXLDaBwk3e9PQ04eMbh3+JhiGsfpEC8GTdAzXD1c1nw3M953/SmUSKPHMcswbLTw6cmyCnMXDIQA==

avatar
文章
阅读
粉丝