利用头部券商平台的CSRF漏洞实现自动化攻击

利用头部券商平台中的CSRF漏洞

Akash Gupta 关注

阅读时间：5分钟 · 发布时间：2025年11月27日

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

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

是时候深入挖掘并激活“猎犬”模式了：

（图片说明：Unsplash上ali hassan的照片，此处用于说明背景。）

首先说明背景：该券商应用程序允许用户连接他们自己定制的应用程序或其他第三方应用程序。因此，这些应用程序可以代表用户下交易订单。

预期流程：

从表面上看，身份验证流程很简单，但一旦从安全角度审视它，情况就开始发生变化。该网站几乎在所有需要身份验证的POST请求上都实现了反CSRF令牌和其他控制措施——但在第三方应用身份验证流程中，这些防护完全不存在。

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

1. 第三方应用程序将其 application_id 发送至券商的后端API。
2. 券商的后端生成一个 session_id，并将其连同“允许/拒绝”同意页面返回给客户端。
3. 当用户点击 “允许” 时，客户端会向后台发送另一个请求，其中包含：
   • session_id
   • 表示允许/拒绝的参数
   • 用户的 cookies
   • 此请求缺少CSRF验证。

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

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

结果？

我的恶意第三方应用程序 自动 连接到了受害者的账户，而受害者并未给出任何同意。

这证实了攻击者只需发送一个CSRF链接或自动提交表单，如果受害者点击了它，攻击者的应用程序就能获得进行交易和其他敏感操作的完全授权。

我向平台报告了此漏洞，他们给出的严重性是：

他们的回复是： 承认了该问题，但将其标记为低危，因为生成的 session_id 在5分钟后就会过期。

因此，攻击需要：

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

那么，我们能否使攻击更快捷、更容易且更具扩展性呢？

（作者引导订阅部分略）

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

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

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

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

我的第一个想法很简单：代表受害者发送请求以生成一个新的 session_id**，获取它，然后自动提交CSRF流程。**

但这行不通——因为发往券商后端API的请求被浏览器的同源策略 阻止了。

因此，我创建了一个概念验证：

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

这导致了一场跨站请求伪造攻击，该攻击：

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

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

影响

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

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

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

最终，在提交了完整可用的概念验证后，该漏洞的严重等级被提升了。

他们如何修复该漏洞

为了修复此问题，该券商增加了一项安全检查：

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

由于这种绑定关系，攻击者无法再预生成一个 session_id 并在CSRF攻击中重复使用。攻击者无法得知与受害者绑定的特定令牌，因此恶意应用程序的自动连接也就不再可能。

CSD0tFqvECLokhw9aBeRqtXyRn0lX+xpHdlLhI/WOecAJbuabhGDzexX6HlErYgcV9KrBOYn6zUXLDaBwk3e9PQ04eMbh3+JhiGsfpEC8GTdAzXD1c1nw3M953/SmUSKPHMcswbLTw6cmyCnMXDIQA==