跨站请求伪造(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开头