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

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

Akash Gupta

5 分钟阅读 · 2025年11月27日

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

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

是时候深入挖掘并开启猎犬模式了：

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

预期的流程：

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

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

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

这个请求缺乏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==