CSRF(跨站请求伪造)
跨站请求伪造(CSRF)
跨站请求伪造(CSRF)，也被称为"一键攻击"或"会话挟持"，是一种利用网站对用户浏览器信任关系的安全漏洞。与XSS攻击不同，CSRF不是利用用户对网站的信任，而是利用网站对用户浏览器的信任
攻击本质：
CSRF是一种针对Web浏览器的"混淆代理"(confused deputy)攻击，具有以下典型特征：
依赖用户身份：攻击针对依赖用户身份验证的网站
滥用信任关系：利用网站对已认证用户浏览器的信任
诱导请求发送：诱骗用户的浏览器向目标网站发送HTTP请求
产生副作用：这些请求会导致服务器状态变更
攻击特点
针对基本web功能：CSRF攻击滥用的是web的基本工作机制
针对状态变更操作：只对能引起服务器状态变化的请求有效（修改密码，转账等）
攻击者不直接获益：因为攻击者收不到服务器响应，而是受害者收到
与其他攻击的区别
特性 | CSRF | XSS |
攻击目标 | 网站对浏览器的信任 | 用户对网站的信任 |
攻击方式 | 诱导发送请求 | 注入恶意脚本 |
结果影响 | 服务器状态变更 | 客户端数据窃取/操纵 |
看不懂但webgoat提到了先记下来
Angular的默认CSRF防护机制
Angular 是一个由 Google 维护的开源 前端 Web 应用框架，用于构建动态的单页应用程序 (SPA)。
工作原理
Angular默认有一个拦截器(interceptor)，会从一个名为XSRF-TOKEN的cookie中读取令牌
然后将这个令牌值设置到HTTP头X-XSRF-TOKEN中
因为只有运行在你域名下的代码才能读取这个cookie，后端可以确认请求来自你的客户端应用而非攻击者
后端设置要求
后端服务器需要在cookie中设置这个令牌
这个cookie不能标记为HttpOnly，因为Angular需要通过JavaScript读取它
每个请求中，Angular会将令牌放入X-XSRF-TOKEN头
服务器验证cookie和头中的令牌是否匹配
重要安全注意事项
不要重用会话cookie作为CSRF令牌
会话cookie应始终标记为HttpOnly(防止XSS攻击读取)
CSRF cookie则不应标记为HttpOnly(因为需要JS读取)
自定义头部的局限性
另一种防御方式是给每个请求都添加自定义头部
只有在所有与服务器的交互都通过JavaScript进行时才有效
服务器只需检查这个头是否存在，不存在则拒绝请求
但注意：
这种方法也会被绕过（例如通过Adobe Reader PDF的客户端请求注入等方式）
所以不应完全依赖此方式
仅限JSON API且禁用CORS时的CSRF风险
CORS (Cross-Origin Resource Sharing) 是一种基于HTTP头的安全机制，它允许Web应用服务器指定哪些外部源(域名、协议或端口)可以访问自己的资源。
CORS的作用
在保持安全的前提下放宽同源限制
让服务器明确声明允许哪些跨域请求
绕过预检请求的方法如（navigator.sendBeacon()）
其他潜在绕过方式
表单+JSON的混合攻击
CSRFConfirmFlag1
靶场
这里说要从外部源触发表单，这里抓包改一下HOST就行
审计
这里主要是对host和referer两个头进行比较
先是提交请求，对比得到这是进入第四个分支随机生成csrf-get-succcess，并把它存到了userSessionData中，并在回显中显示
确认flag
就是把userSessionData中的csrf-get-succcess值取出与输入字符进行比较
ForgedReviews
靶场
这里还是把host改一下就行
审计
可以看到这里只需要满足validateReq 不为空且和weakAndtiCRSF匹配，这个值前端是已给出的，还有referer的值不为空时不能和host的域相等
CSRFFeedback
靶场
结合后面的审计主要有三个点
将Content-Type:改成text/plain，纯文本
将host和referer的域改不一样
包含特定cookie，这里这题不用管，已经给了
绕过源码中的三次判断
审计
首先配置了objectMapper的各种严格反序列化选项
检查CSRF条件
请求包中包含特定的cookie
内容类型为纯文本（text/plain）
进一步验证Host和Referer头是否来自不同域
这三个条件
CSRFLogin
靶场
这里的意思就是让我们创建一个以csrf开头的新用户，代表攻击者的账户，原标签页代表受害者账户，这里就是模拟让受害者以攻击者的凭证登录（把username从受害者改成攻击者的）
审计
这里就是判断用户名是不是以csrf开头