使用CSS History Hack入侵CSRF令牌

更新:安全研究人员Sirdarckcat和Gareth非常友好,可以在此处共享基于纯CSS的CSRF令牌查找器的代码。这比下面的我的PoC更隐秘,我的PoC同时使用了JS和CSS。因此,即使您禁用了javascript并且您不再安全,它仍然可以正常工作 :(:( . 为了使PoC对客户端的响应速度更快,您需要使用import命令使用多个CSS样式表。我看到的这种基于纯CSS的方法的唯一问题是,大型键空间会涉及网络延迟,因为大型CSS样式表需要由浏览器下载.


我在考虑跨站点请求伪造的问题以及该行业当前使用的缓解策略。到目前为止,在我测试过的许多实际应用程序中,我看到使用附加的随机标记作为url的一部分。如果请求未能提供任何令牌或提供具有不正确值的令牌,则该请求将被拒绝。这样可以防止CSRF或任何跨域未授权功能的执行.

到目前为止,对于攻击者来说,使用服务器上的蛮力攻击来发现您的CSRF令牌被认为是不可行的.

原因是:

  1. 它产生 网络上的噪音很大并且很慢. 因此,很可能IDS或Web App防火墙会发现恶意行为并阻止您的IP。例如,长度为5个字符(以一个字符开头)的Base16 CSRF令牌将生成大约393,216个请求.
  2. 许多应用程序被编程为 使您的会话无效 它检测到超过一定数量的带有无效令牌值的请求后。例如。 30.

我将通过向您展示一种快速生成csrf令牌而不产生警报的技术来改变这种信念。这种技术是 客户端攻击, 因此几乎没有产生网络流量,因此,您的服务器和IDS / Web应用防火墙赢得了’根本没有注意到它。该攻击基于耶利米·格罗斯曼3年前发现的流行CSS History Hack。.

在此漏洞利用中,我们通过在浏览器历史记录中强行强制各种URL来发现csrf令牌。我们将尝试将不同的csrf令牌值嵌入到url中,并检查用户是否访问了该url。如果是,则用户很有可能在当前的活动会话中使用了相同的CSRF令牌,或者可能在上一个会话中使用了该令牌。一旦有了所有这些令牌的列表,我们就可以使用该小列表尝试在服务器上进行csrf攻击。当前,这种攻击对于长度为5个字符或更短的令牌是可行的。我在长度为5的base16字符串上进行了尝试,并且能够在不到2分钟的时间内强行破解整个密钥空间.

该攻击起作用的一些先决条件是

  1. 对于特定的用户会话,CSRF令牌保持不变。例如csrf token =哈希(session_id)或
  2. 接受以旧版形式为同一会话提交的CSRF令牌。很多情况下都是这样,因为它可以增强用户体验并允许使用前进和后退浏览器按钮.

概念证明 在这里可用.
在运行PoC之前,您需要更改url和csrftoken参数值.

要使用默认值进行测试,您需要先访问以下网址之一,例如.

  1. https://securethoughts.com/?param1=val1&csrftoken = b59fe [将b59fe更改为以字符开头(即大于a0000)的任何5位以16为基数的字符串]
  2. http://tinyurl.com/l2lwgd [这是301重定向到以前的网址].

注意: 在浏览器历史记录中存储http://www.securethoughts.com和https://securethoughts.com时会有所不同.

运行示例如下所示–

使用CSS历史记录黑客攻击CSRF令牌使用CSS历史记录黑客攻击CSRF令牌

为使这种攻击不可行,

服务器端解决方案(针对开发人员):

  • 使您的CSRF令牌足够长(8个或更多字符),以防止CLIENT SIDE攻击。不断提高的处理能力将使这种攻击对于更长的令牌也可行.
  • 将您的CSRF令牌存储为隐藏表单字段的一部分,而不是输入url.
  • 对于每个表单提交都使用不同的随机令牌,即使对于同一会话也不接受任何过时的令牌.

客户端解决方案(针对您的客户/用户):

  • 使用诸如SafeHistory之类的浏览器插件,该插件可防御基于访问链接的跟踪技术.
  • 在浏览器中使用私人浏览模式.

最后但并非最不重要的一点是,XSS消除了所有可能的CSRF保护。所以,先摆脱XSS.

我要感谢耶利米(Jeremiah)在这篇文章中提供的有见地的反馈。

Brayan Jackson Administrator
Sorry! The Author has not filled his profile.
follow me