1.在 POST 请求时验证 csrftoken,但在 get 请求时却绕过
将本是 post 方法的请求改为 get 并删除 csrf token，发包后能够正确回显，说明存在漏洞
使用 bp 的 csrf poc 生成 html 页面，发送给用户
2.令牌验证依赖令牌存在
直接将令牌参数删除也能正确响应
后端可能处理逻辑：1.通过 if 条件判断，if csrf_token 则进入比较，但是如果令牌为空，条件为假就不会进入比较，绕过验证
2.使用弱比较 if request_token == session_token: pass ,若默认 token 为空或在某些情况下置为空的话会绕过
3.令牌未单独绑定
服务器只验证令牌是不是后端发的，但没有对每一个会话进行单独绑定，攻击者利用自己的 令牌去假冒被攻击者来完成攻击
4.令牌与非对话 cookie 绑定
现在为每一个 csrftoken 都单独绑定了一个 cookie，但是绑定的 cookie 不是会话 cookie 而是单独的一个 csrfKey 的 cookie，后端可能只验证 csrfToken 与 csrfKey 之间是不是对应关系但并没有单独校验会话 cookie，利用自己账户的 csrfKey 和 token 替换掉受害者的达成攻击
5.cookie 可控绕过双重防御
需要提交的 token 和 cookie 中的值一样，因为同源策略攻击者无法通过恶意网站读取目标网站的 cookie 也就没办法伪造 token，但是如果网站中出现可控 cookie 的情况就可以通过修改 cookie 来伪造自己的 token
抓包网站的搜索功能，发现搜索的值出现在响应的 Set-Cookie 中，可能存在 http 头注入漏洞
生成 csrf poc ，将其中的 script 改为<img src=“https://YOUR-LAB-ID.web-security-academy.net/?search=test%0d%0aSet-Cookie:%20csrf=fake%3b%20SameSite=None” onerror=“document.forms[0].submit();”/>
确保先注入 cookie 再提交表单
test%0d%0aSet-Cookie:%20csrf=fake%3b%20SameSite=None 进行 http 头注入
6.仅根据 referer 头来防御 csrf
再 bp 生成的 html 中插入
当发生跳转时不会记录 referer 头部