密码学系列之:csrf跨站点请求伪造

CSRF（Cross-site request forgery，跨站点请求伪造）是一种利用已授权用户信任的恶意攻击，通过诱导用户提交非自愿的Web请求，导致服务器执行未经授权的操作。 以下是关于CSRF的详细解析：

• 核心机制：攻击者利用用户浏览器自动携带目标站点Cookie的特性，在用户不知情时伪造请求。例如：

  用户登录目标网站（如银行）后，浏览器保存了会话Cookie。

  攻击者诱导用户访问恶意页面（如嵌入恶意链接的邮件），浏览器自动携带Cookie向目标网站发送请求。

  目标网站误认为请求来自合法用户，执行恶意操作（如转账、修改密码）。

• 常见手段：

  特制图像标签：<img src="恶意URL"> 自动触发GET请求。

  隐藏表单：通过JavaScript自动提交表单。

  XMLHttpRequests：在后台发送跨域请求（受同源策略限制，但可通过CORS绕过）。

• 2006年Netflix漏洞：攻击者可修改受害者账户的收货地址，盗取商品。
• 2008年YouTube攻击：攻击者几乎可执行任意用户操作（如删除视频、修改账号）。
• 2018年路由器攻击：通过CSRF修改DNS设置，劫持网络流量。

1. 目标网站未验证Referer头：若网站仅允许同源请求，CSRF无法生效。
2. 存在可利用的表单或URL：攻击者需找到执行敏感操作的接口（如转账、修改密码）。
3. 参数可预测：若操作需秘密值（如验证码、唯一ID），攻击可能失败。
4. 用户诱导成功：受害者需在登录状态下访问恶意页面。
5. 无法获取响应：攻击者无法看到操作结果，连续操作可能中断。

• 原理：在表单中嵌入随机Token，服务器验证Token的唯一性和随机性。<input type="hidden" name="csrfmiddlewaretoken" value="随机值" />
• 优点：兼容性强，仅依赖HTML。
• 缺点：增加程序复杂度，多标签页可能引发可用性问题（可用会话级Token缓解）。

• 原理：

  服务器设置SameSite=Lax或Secure的Cookie，禁止跨域访问。

  客户端JavaScript读取Cookie值，添加到自定义请求头（如X-CSRFToken）。

  服务器验证请求头与Cookie的一致性。

• 适用场景：AJAX交互为主的Web应用（如Django、AngularJS）。
• 注意：需确保同源策略，防止JavaScript被篡改。

• 原理：

  服务器设置CSRF Token为Cookie。

  表单中嵌入相同Token的隐藏字段。

  服务器验证Cookie与表单字段是否匹配。

• 优势：无需服务器存储Token，减轻负担。
• 限制：依赖同源策略防止攻击者读取Cookie。

• 原理：服务器设置Cookie时添加SameSite=Strict或Lax，限制跨站请求携带Cookie。

  Strict：完全禁止跨站请求携带Cookie。

  Lax：允许部分安全请求（如GET导航）携带Cookie。

• 要求：浏览器需支持该属性，且Cookie需设置Secure标志。

• 浏览器扩展：如CsFire（Firefox）通过删除跨站请求的身份信息减少风险。
• 默认拒绝策略：如RequestPolicy或uMatrix，但可能影响正常功能。

• GET请求：易被利用（如IMG标签自动加载），应避免用于修改数据。
• POST请求：需结合STP或Token防护，防止表单伪造。
• PUT/DELETE等：依赖同源策略和CORS，若服务器允许Access-Control-Allow-Origin: *，则防护失效。

CSRF攻击的核心是信任用户浏览器的自动行为，防范需从以下角度入手：

1. 验证请求来源：检查Referer头或使用SameSite Cookie。
2. 绑定用户身份与请求：通过Token或自定义头确保请求合法性。
3. 限制敏感操作：对转账、修改密码等操作增加二次验证（如短信验证码）。
4. 遵循安全规范：避免使用GET修改数据，正确配置CORS和Cookie属性。

通过组合上述技术，可显著降低CSRF攻击风险，保障用户数据安全。