利用某头部券商平台的CSRF漏洞：从发现到规模化攻击-平芜编程栈

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

作者：Akash Gupta
阅读时间：5分钟 · 发表于2025年11月27日

几个月前，我在一个拥有超过1400万活跃用户的头部券商平台中发现了一个漏洞。这是一个CSRF漏洞，正如你所知，CSRF的影响完全取决于攻击者能够触发的操作的关键性和敏感性。

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

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

（图片说明：来自Unsplash，作者ali hassan）

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

预期的流程：

表面上，认证流程看起来很简单，但从安全角度审视后，情况就变了。该网站在几乎所有已认证的POST请求上都实现了Anti-CSRF令牌和其他控制措施——但这些保护措施在第三方应用认证流程中完全不存在。

其工作流程如下：

这个请求缺少CSRF验证。

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

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

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

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

我向平台报告了此问题，他们评估的严重性是：
他们的回应是：接受了问题，但将其标记为低危，因为生成的session_id在5分钟后就会过期。

因此，攻击需要：

那么，我们能否让利用过程更快、更容易且更具扩展性呢？

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

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

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

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

因此，我创建了一个概念验证（POC），其原理如下：

启动一个恶意服务器，监听路由 (/)。
当有人访问该路由时，服务器（从服务器端而非受害者端）向券商平台的一个合法登录端点发起后端请求，以获取生成的session_id。
服务器捕获登录重定向响应，专门寻找session_id。
一旦找到session_id，服务器自动构建一个隐藏的HTML表单，伪装成交易平台的“授权”步骤。
受害者的浏览器被诱骗：
- 加载这个表单
- 使用JavaScript自动提交它
  这导致了一场跨站请求伪造攻击，迫使受害者的浏览器在用户不知情且未同意的情况下，授权一个由攻击者控制的应用程序。

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

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

最终，在提供了完整可用的POC后，漏洞的严重性等级被提升了。

他们如何修复了该漏洞
为了修复此问题，该券商增加了一个额外的安全检查：

当后端生成session_id时，会返回一个唯一的令牌。
这个唯一的令牌被专门映射到发起认证流程的用户。
在“允许”请求期间，此令牌必须匹配。
由于这种绑定关系，攻击者无法再预先生成session_id并在CSRF攻击中重复使用。攻击者无法获知特定于受害者的令牌，因此恶意应用程序的自动连接不再可能实现。
CSD0tFqvECLokhw9aBeRqtXyRn0lX+xpHdlLhI/WOecAJbuabhGDzexX6HlErYgcV9KrBOYn6zUXLDaBwk3e9PQ04eMbh3+JhiGsfpEC8GTdAzXD1c1nw3M953/SmUSKPHMcswbLTw6cmyCnMXDIQA==
更多精彩内容请关注我的个人公众号公众号（办公AI智能小助手）
对网络安全、黑客技术感兴趣的朋友可以关注我的安全公众号（网络安全技术点滴分享）