CSRF三种姿势绕过

何为CSRF？
- 即跨站请求伪造（Cross - Site Request Forgery）
攻击原理
- 用户自行登录网站A，并且本地生成了身份凭证（如cookies）
- 攻击者构建恶意网站B，若点击此网站，会自动发起请求（可能构建隐藏表单，也可能利用JS发起请求）
- 用户在没有退出网站A的情况下，并引导点击包含恶意网站的链接，此时恶意网站就会对用户所登录网站发起请求
- 网站A接受请求，由于个人身份凭证（cookies等）完成认证并没有过期，网站就会认为是合法请求，然后执行请求，从而到达攻击目的
姿势一（get传参）
- 进入靶场，本期重点不在爆破，于是省略爆破过程（详细过程请回顾往期作品），输入正确的口令完成登录，进入登录界面
- 点击修改个人信息，随便进行修改提交之后抓包查看
- 很明显了，这是简单的GET传参
- 那么我们是否只需要进行构造URL，当用户点击这个链接时，就可以完成神不知鬼不觉的攻击了？试试看呢！构造URL如下
  
  [!NOTE]
  
  http://10.148.98.158:8001/pikachu/vul/csrf/csrfget/csrf_get_edit.php?sex=girl&phonenum=111111&add=usa&email=lili%40pikachu.com&submit=submit
- 我们在一个新的TAB中输入下面链接回车，看是否可以修改成功
- 回车之后发现，电话号码已经成功被修改了
- 那么就有朋友要问了，同学同学，这个链接会不会太明显了，有没有更加隐蔽的方法？有的有的，朋友，有的，让它变得更隐蔽的方法还有很多，比如下面这个，我们使用在线短链接生成平台（本次使用蓝鸟短链接）
- 然后将生成的短链接进行访问，成功访问
姿势二（POST）
- 修改信息之后进行抓包查看
- 可以发现，这是一个POST传参的方法
- 那么专业的事还需要交给专业的人来做，咱直接用BP生成针对POST传参的POC（需要BP专业版）
- 对生产的POC，可以自由更改想要更改的地方，这里把原密码改为12138
- 然后点击下方的"test in browser",复制生成的链接
- 在新的页面打开，输入链接，回车，提交，关闭代理，发现更改成功
姿势三（token防护）
- 修改住址为aaa，提交后抓包
- 抓包发现，居然携带token，不是吧？人与人之间最基本的信任呢
- 首先我们可以尝试查看页面源代码，看看token的生成规律是否可以被推理出来，发现是调用函数生成的随机值，好吧，燃尽了
- 查看源码之后我们就可以知道，每一次请求服务端会随机生成token传给客户端，然后客户端每次请求都会加上一个随机token，如果验证成功，就可以修改，反之则不可以，那么每次服务器一定会在失败之后，在响应包中返回新产生的token值，查看响应包看是否正确
- 可以发现，响应包的token值与请求包的不同，那么，破案了！！！接下来我们需要下载攻击插件，进入"Extensions",下载如下插件
- 下载好之后进入重发模块，选择总是跟随重定向
- 然后进入刚刚下载的攻击扩展，进行配置
- 配置成功之后，进行重发就会发现只需要更改想更改的地方，其他的不用管就可以完成修改
- 最后放包之后回到登录页面，发现信息已被篡改，token成功绕过
防御方式
- 配置 SameSite Cookie 属性
  - 原理：Cookie 是浏览器和服务器维持登录状态关键数据，CSRF 攻击多从第三方站点发起。通过设置 Cookie 的SameSite属性，限制跨站请求时 Cookie 发送。Strict最严格，禁止第三方 Cookie；Lax较宽松，跨站点链接打开和第三方站点 Get 表单提交会携带 Cookie ，但第三方站点 Post 方法、通过img 、iframe等标签加载 URL 不携带。
  - 示例：设置Set - Cookie: sessionid=12345; expires=Fri, 31 Dec 9999 23:59:59 GMT; path=/; domain=.example.com; SameSite=Strict ，可严格限制跨站请求时 Cookie 发送，降低攻击风险。
- 验证请求来源
  - 原理：检查 HTTP 请求头中的Referer或Origin字段。Referer记录请求来源地址，服务器可判断是否来自合法站点；Origin只含域名信息，在重要场合（如 XMLHttpRequest、Fetch 发起跨站请求或 Post 方法发送请求）会带上。服务器优先判断Origin ，无则再判断Referer 。
  - 示例：用户从银行官网发起请求，Referer是银行官网地址；若从恶意网站发起，Referer是恶意网站地址，服务器可据此判断并拦截非法请求。但Referer不可靠，用户可限制发送或浏览器在某些情况（如 HTTPS 跳转到 HTTP ）不发送。
- 使用 CSRF 令牌（Token）
  - 原理：服务器为用户会话生成唯一随机字符串作为 CSRF 令牌，在浏览器向服务器发起请求时，将其植入返回页面（如隐藏表单域）。浏览器端发起请求需带上此令牌，服务器验证其合法性。第三方站点无法获取该令牌，请求无有效令牌或令牌不匹配，服务器会拒绝，阻断攻击。
  - 示例：用户登录银行网站，服务器生成令牌abcd1234，网页表单含<input type="hidden" name="csrf_token" value="abcd1234"> ，转账请求时需带上此令牌，无或错则转账请求被拒。
  - 当然，这里的token并不是明文传输，采用 HTTPS 协议传输 token，利用 SSL/TLS 加密，防止传输中被中间人截获或篡改。比如浏览器与服务器间通信，通过 HTTPS 确保 token 安全传输