CSRF(跨站请求伪造)

跨站请求伪造(CSRF)

跨站请求伪造(CSRF)，也被称为"一键攻击"或"会话挟持"，是一种利用网站对用户浏览器信任关系的安全漏洞。与XSS攻击不同，CSRF不是利用用户对网站的信任，而是利用网站对用户浏览器的信任

• 攻击本质：

CSRF是一种针对Web浏览器的"混淆代理"(confused deputy)攻击，具有以下典型特征：

1. 1. 1. 依赖用户身份：攻击针对依赖用户身份验证的网站
      2. 滥用信任关系：利用网站对已认证用户浏览器的信任
      3. 诱导请求发送：诱骗用户的浏览器向目标网站发送HTTP请求
      4. 产生副作用：这些请求会导致服务器状态变更

• 攻击特点

1. 1. 1. 针对基本web功能：CSRF攻击滥用的是web的基本工作机制
      2. 针对状态变更操作：只对能引起服务器状态变化的请求有效（修改密码，转账等）
      3. 攻击者不直接获益：因为攻击者收不到服务器响应，而是受害者收到

• 与其他攻击的区别

|----------|-----------|------------|
| 特性 | 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的作用

• • 在保持安全的前提下放宽同源限制
  • 让服务器明确声明允许哪些跨域请求

1. 绕过预检请求的方法如（navigator.sendBeacon()）
2. 其他潜在绕过方式
3. 表单+JSON的混合攻击

CSRFConfirmFlag1

靶场

这里说要从外部源触发表单，这里抓包改一下HOST就行

审计

这里主要是对host和referer两个头进行比较

先是提交请求，对比得到这是进入第四个分支随机生成csrf-get-succcess，并把它存到了userSessionData中，并在回显中显示

确认flag

就是把userSessionData中的csrf-get-succcess值取出与输入字符进行比较

ForgedReviews

靶场

这里还是把host改一下就行

审计

可以看到这里只需要满足validateReq 不为空且和weakAndtiCRSF匹配，这个值前端是已给出的，还有referer的值不为空时不能和host的域相等

CSRFFeedback

靶场

结合后面的审计主要有三个点

1. 将Content-Type:改成text/plain，纯文本
2. 将host和referer的域改不一样
3. 包含特定cookie，这里这题不用管，已经给了

绕过源码中的三次判断

审计

• 首先配置了objectMapper的各种严格反序列化选项
• 检查CSRF条件

1. 1. 请求包中包含特定的cookie
   2. 内容类型为纯文本（text/plain）

• 进一步验证Host和Referer头是否来自不同域

这三个条件

CSRFLogin

靶场

这里的意思就是让我们创建一个以csrf开头的新用户，代表攻击者的账户，原标签页代表受害者账户，这里就是模拟让受害者以攻击者的凭证登录（把username从受害者改成攻击者的）

审计

这里就是判断用户名是不是以csrf开头