当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/