当SameSite属性为默认值Lax时，绕过它并获得一个CSRF

本篇文章由ChaMd5安全团队翻译小组投稿

SameSite Cookies 是每个人都在谈论的新 cookie 属性，可用于防止 SOP 的绕过和 CSRF 攻击。但首先让我们看看它到底是什么。

SameSite 是一个 cookie 属性，可以告诉浏览器应该何时在跨源请求中发送特定的 cookie，它的值有 3 种类型：

• SameSite None?将在所有跨源请求中发送 cookie，将被视为普通（旧）Cookie 。
• SameSite Lax?仅在顶部窗口导航（例如<a>标签、window.open()）中的GET请求中发送 cookie 。
• SameSite Strict?仅当用户在URL栏中键入网站并按Enter时，才会发送 cookie 。

想了解更多，请参考：https://web.dev/samesite-cookies-explained/

从现在的 Chrome 79 开始，没有设置 SameSite 的默认 cookie 将被视为?Nonecookie，但这种情况很快就会改变 —— 从2月4日发布的 Chrome 80 开始。

没有 SameSite 属性的 cookie 将被视为?Lax，这意味着 cookie 仅在顶部窗口导航和 GET 请求中发送。这可能是解决许多 POST CSRF 攻击的好方法。

但是，这些 cookie 还有一个被叫做 LAX+POST 的特殊点，来自 Chrome ：

Chrome 将会为不在2分钟内设置 SameSite 属性的 cookie 设置抛出一个异常。尽管正常的?SameSite=Lax Cookie?要求顶级跨站点请求具有安全的（例如 GET ）HTTP 方法，但此类 cookie 也将与非幂等（例如 POST ）顶级跨站点请求一起发送。

这意味着，如果在 2 分钟内设置或更改了 cookie，浏览器将在 POST 请求中发送该 cookie ，并将其视为None（仅顶部窗口导航），但在 2 分钟后，它将变为?Lax。

这用于不破坏 Web 和登录流程，但也给我们带来了新的攻击面，它允许我们通过默认的方式绕过 SameSite Lax 并获得 CSRF 。根据策略，如果 Cookie 的生成时间不超过 2 分钟，那么该 Cookie 在实际应用中将如何被滥用？

1. 有些网站可能会不时更改会话(session) cookie?，那么我们所需要的只是打开一个指向该网站的新窗口，当用户的 session 被一个新的替换，然后我们就会获得一个 CSRF 漏洞。
2. Cookie 会话将在一段时间后到期，并且用户需要获得新的会话：

攻击者将打开一个指向登录页面的新窗口 受害者将登录到该站点并获得新的会话 然后，攻击者可以执行 CSRF 攻击，因为刚刚设置了 cookie（不超过 2 分钟）

1. 大多数应用程序的注销(登出/logout)功能是使用 GET 请求，并且在顶部窗口中发送GET请求将发送带有Lax属性值的cookie，这意味着我们将有注销(登出/logout) CSRF ，它将使 cookie 得以删除或更改。

攻击者将打开一个新窗口，该窗口指向注销页面 受害者打开注销页面，其cookie将被更改或删除 攻击者将打开一个新窗口，指向登录页面，用户登录 攻击者可以执行CSRF攻击

1. 让用户再次登录网站效率不高，并且需要大量交互，但是我们有一个救星（Oauth），当今大多数网站都有使用其他提供商的第二种方法登录选项，因此如果我们有注销(登出/logout) CSRF 和 Oauth 登录，那么我们可以以较少的交互绕过默认的SameSite Lax。

攻击者将打开一个新窗口，该窗口指向注销页面 受害者打开注销页面，他的会话将被删除 攻击者将打开一个指向Oauth登录页面的新窗口（example.com/login/oauth/facebook） 受害者将自动重新登录到应用程序，并将设置一个新会话 攻击者可以执行 CSRF 攻击，因为 cookie 不超过2分钟

1. 由于某些原因，某些应用程序可能具有获取新会话的选项，然后我们需要以某种方式让受害者单击该（新会话）按钮，或者如果网站使用某些 REST API，我们可以打开一个指向（example.com/user/new_session）的新窗口，然后获得 CSRF 。

LAX+POST( 2 分钟) 是临时性的操作，将来会被删除，这具体取决于开发人员何时将其登录会话流更改为SameSite None，或使用另一种方法进行跨域请求，另一种情况是将时间减少到10秒（ 这样仍然可以滥用）。

不久前，我根据这种行为提出了一个小挑战（challenge）。

https://twitter.com/RenwaX23/status/1213944633425838080

它具有3个主要功能：

登录将cookie设置为 (session=username)?注销将cookie设置为 (session=)?设置会将 POST 请求发送到 settings.php 以更改用户名 (session=new username)，如果 POST 请求中不存在会话 cookie ，则文件将抛出 CSRF 错误。

该挑战基于第三个场景，应用程序使用 GET 请求注销功能，我们需要做的是向 logout.html 发送请求，该请求将 cookie 更改为 (session=) ，然后浏览器将知道 cookie 已更改， 2 分钟的特性将生效，因此对于 2 分钟内的其他请求，会话 cookie 将被发送。

由于 Chrome 的新特性，我们无法使用跨域请求更改 Cookie 。

https://renwax23.github.io/X/csrf-samesite/solution.html

Solution source code

需要用户单击交互才能打开新窗口。

挑战的源代码：https://github.com/RenwaX23/X/tree/master/csrf-samesite

总而言之，SameSite是一种出色的浏览器特性，可以阻止广泛的客户端攻击，但并不是能够依赖的防弹技术，这种临时的 Lax + POST 将是一种绕过那些没有任何 SameSite 属性发送 cookie 的新方法，并且可能会很快被删除。

(SameSite 更新)[https://sites.google.com/a/chromium.org/dev/updates/same-site?pli=1]

感谢

Renwa:https://twitter.com/RenwaX23

原文地址：https://medium.com/@renwa/bypass-samesite-cookies-default-to-lax-and-get-csrf-343ba09b9f2b

如有错误，敬请指正。

关注公众号：拾黑（shiheibook）了解更多

[广告]赞助链接：

四季很好，只要有你，文娱排行榜：https://www.yaopaiming.com/
让资讯触达的更精准有趣：https://www.0xu.cn/