
几个月前,我在一个拥有超过1400万活跃用户的领先经纪平台中发现了一个漏洞。这是一个CSRF(跨站请求伪造)问题。众所周知,CSRF的影响完全取决于攻击者可以触发的操作的关键性和敏感性。
当时,我正在随机观看一个YouTube视频,视频中有人演示了如何使用该经纪商的API来构建一个用于算法交易的自动买卖订单机器人。观看过程中,我对身份验证流程,特别是第三方应用程序如何连接到经纪商的平台并获得代表用户进行交易的权限,产生了浓厚的兴趣。就在这时,情况开始显得可疑。
是时候深入研究并启动“猎犬模式”了:
为了理解背景:这个经纪应用程序允许用户连接他们自己定制的应用程序或其他第三方应用程序。因此,这些应用程序可以代表用户下达交易订单。
预期流程:
表面上看,这个身份验证流程很简单,但一旦你从安全角度审视它,情况就不同了。该网站在几乎所有经过身份验证的POST请求上都实现了Anti-CSRF令牌和其他控制措施——但这些保护措施在第三方应用身份验证流程中完全不存在。
以下是该流程的工作原理:
application_id 的初始请求。session_id 并将其返回给客户端,同时返回一个“允许/拒绝”的同意页面。session_id目标: 通过利用这个缺失的CSRF验证,将我自己的恶意第三方应用程序连接到受害者的账户。
为了测试,我使用从我自己的攻击者账户生成的 session_id 创建了一个简单的CSRF表单。我将这个表单发送到我的第二个账户(扮演受害者)并提交。
结果呢?
我的恶意第三方应用程序在未经受害者任何同意的情况下,自动连接到了受害者的账户。
这证实了攻击者可以简单地发送一个CSRF链接或自动提交表单,如果受害者点击了它,攻击者的应用程序将获得完全授权,可以进行交易和其他敏感操作。
我向他们报告了这个问题,得到的严重性评级是:
他们的回应: 接受了问题,但将其标记为低严重性,因为生成的 session_id 在5分钟后过期。
因此,攻击需要:
session_id那么,我们能否让漏洞利用更快、更容易、更具可扩展性?
目标更新: 让漏洞利用更快、更容易、完全可扩展。
如果受害者打开一个攻击者控制的网站,攻击者的第三方应用程序应该自动连接到受害者的账户——无需点击、无需手动交互,并且它应该对任何访问用户都有效,而不仅仅是一个。
要实现这一点,我们需要两样东西:
session_id我的第一个想法很简单:
直接代表受害者发送请求以生成一个新的 session_id**,获取它,然后自动提交CSRF流程。**
但这行不通——因为向经纪商后端发送的请求被浏览器的同源策略(SOP) 阻止了。
因此,我创建了一个概念验证(PoC),它:
/)。session_id。这导致了一次跨站请求伪造(CSRF)攻击,该攻击:
通过这种设置,任何访问攻击者控制网站的新用户都会被自动利用,攻击者的第三方应用程序将在不需要任何交互的情况下,持续累积新的受害者账户。每一次页面加载都意味着又一个交易账户被攻陷。
一旦恶意应用程序获得授权,攻击者可以:
例如,攻击者可以强制所有被攻陷的账户购买同一只股票,制造人为需求并操纵市场。如果有足够多的受感染账户,这将变得极其危险。
最终,在提供了完整可用的PoC后,严重性等级得到了提升。
为了修复这个问题,经纪商增加了一个额外的安全检查:
session_id 时,会返回一个唯一的令牌。由于这种绑定关系,攻击者无法再预先生成一个 session_id 并在CSRF攻击中重用它。攻击者无法获知特定于受害者的令牌,因此恶意应用程序的自动链接不再可能实现。
CSD0tFqvECLokhw9aBeRqtXyRn0lX+xpHdlLhI/WOecAJbuabhGDzexX6HlErYgcV9KrBOYn6zUXLDaBwk3e9PQ04eMbh3+JhiGsfpEC8GTdAzXD1c1nw3M953/SmUSKPHMcswbLTw6cmyCnMXDIQA==
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。