csrf特性
| 请求类型 | SameSite=Strict |
SameSite=Lax |
SameSite=None |
|---|---|---|---|
| 同站链接点击 (GET) | ✅ | ✅ | ✅ |
| 同站表单提交 (POST) | ✅ | ✅ | ✅ |
| 跨站链接点击 (GET) | ❌ | ✅ | ✅ |
| 跨站表单提交 (POST) | ❌ | ❌ | ✅ |
| 跨站 AJAX 请求 (fetch) | ❌ | ❌ | ✅ |
| 跨站图片加载 (GET) | ❌ | ❌ | ✅ |
Lax时跨站链接点击是可以携带cookie的,常见的csrf也多是这样。
可当某个功能想实现csrf时,需要不止一个请求时,该怎么办?如果是None模式下我们当然可以用fetch或img来实现多包,但SameSite=Lax时就真的无可奈何了吗。
一个机缘巧合下,我发现了个有趣的绕过方式。
故事开始的地方
某个下午,忙碌(摸鱼)了一天张三了刷起了视频。许是因为网速不好,在点了A视频后没立即跳转过去。正此时张三又看到了个更博眼球的B视频连忙点击。
于是页面跳转到了B视频那里。可后退时却发现没到主页而是回退到了A视频上。这立刻引起了张三的注意,难道说这两个请求都发出去了吗?
于是张三写下几行代码
1 | <a id="a1" href="https://blog.jiabail.xyz/xx?a=1" >x</a> |

还真的可以
应用
这让张三想起来之前挖到的一个账号接管,开发将获取code放在了点击确认之后,但把每一次请求绑定了cookie,又做了每一步的校验。因此虽然认证的两个包都可以被伪造,但用户连点两次的可能还是太小,太过鸡肋。
刚好用上这个技巧,一番操作之下,拿下高危

