跨站请求伪造（CSRF）攻击的变异形式：基于XMLHttpRequest（XHR）的CSRF攻击详解

1. 知识描述
基于XMLHttpRequest（XHR）的CSRF攻击是传统CSRF攻击的一种变异形式，它利用现代Web应用中广泛使用的AJAX技术（通过XHR对象发起异步HTTP请求）来实施攻击。与传统的表单提交或图片标签触发CSRF不同，这种攻击通过恶意脚本控制受害者的浏览器，在用户不知情的情况下自动发送经过身份验证的XHR请求，从而执行敏感操作（如修改账户设置、发起转账等）。由于XHR默认会携带用户的Cookie等认证信息，且可以构造复杂的请求（如Content-Type为application/json），使得防御机制不完善的应用容易受到攻击。

2. 攻击原理与背景

• XHR工作机制：XHR是浏览器提供的JavaScript API，允许网页在不刷新页面的情况下与服务器交换数据。默认情况下，XHR请求会自动携带当前域的Cookie（包括会话Cookie）。
• 同源策略的限制：浏览器同源策略会限制跨域XHR请求，但攻击者可以通过以下方式绕过：
  • 攻击发生在同源页面内（例如用户访问了被攻击者控制的子域名或同一应用内的漏洞页面）。
  • 服务器错误配置了CORS策略，允许恶意源发起请求。
  • 使用简单请求（如GET/POST带特定Content-Type）或预检请求绕过。
• 攻击场景：用户登录了目标网站（如bank.com），会话Cookie有效。同时，用户访问了恶意网站，该网站通过JavaScript自动发送一个XHR请求到bank.com的敏感接口（如修改密码），浏览器自动附加Cookie，导致请求被服务器认可。

3. 攻击步骤详解
假设目标网站bank.com有一个修改邮箱的接口：
POST /change-email，要求JSON格式：{"email":"new@attacker.com"}，依赖Cookie进行身份验证。

步骤1：攻击者构造恶意页面
攻击者在恶意网站（evil.com）上托管以下HTML/JavaScript代码：

<script>
  // 创建XHR对象
  var xhr = new XMLHttpRequest();
  xhr.open("POST", "https://bank.com/change-email", true);
  xhr.setRequestHeader("Content-Type", "application/json"); // 设置JSON类型
  xhr.withCredentials = true; // 强制携带Cookie（包括跨域Cookie，需CORS允许）
  
  // 定义请求完成后的处理（可选，攻击可静默进行）
  xhr.onreadystatechange = function() {
    if (xhr.readyState === 4) {
      alert("攻击完成！服务器响应：" + xhr.responseText);
    }
  };
  
  // 发送恶意JSON数据
  xhr.send(JSON.stringify({email: "attacker@evil.com"}));
</script>

步骤2：诱导用户访问恶意页面
攻击者通过钓鱼邮件、社交工程或恶意广告，诱使用户在已登录bank.com的浏览器中访问evil.com页面。

步骤3：恶意脚本自动执行
用户浏览器加载evil.com页面时，脚本自动运行：

• 浏览器发送POST请求到https://bank.com/change-email。
• 由于用户已登录bank.com，请求自动附带上bank.com的会话Cookie。
• 如果bank.com的CORS配置允许evil.com源（例如设置为Access-Control-Allow-Origin: *），或请求为简单请求且服务器未验证Origin，请求将被服务器处理。
• 服务器验证Cookie有效，执行修改邮箱操作，用户账户被接管。

4. 与普通CSRF的区别

• 请求类型：传统CSRF多依赖<form>或<img>标签，只能发起GET或简单POST（application/x-www-form-urlencoded）。XHR CSRF可发送复杂Content-Type（如application/json），更贴近现代API设计。
• 隐蔽性：XHR请求可在后台静默完成，无需用户交互（如表单提交按钮）。
• 依赖条件：传统CSRF无需CORS；XHR CSRF常需CORS配置漏洞或同源环境。

5. 防御措施

• 使用CSRF Token：为每个会话生成随机Token，嵌入表单或请求头（如自定义头X-CSRF-Token），服务器验证Token有效性。XHR请求需显式添加Token（JavaScript可读，但同源策略限制恶意页面获取Token）。
• 检查请求头：验证Content-Type为预期值（如application/json），但需注意简单请求可能绕过。
• 严格CORS配置：避免使用Access-Control-Allow-Origin: *，精确设置允许的源，并限制Access-Control-Allow-Credentials的使用。
• SameSite Cookie属性：设置Cookie的SameSite=Strict或Lax，阻止跨域请求自动携带Cookie（但部分场景可能影响用户体验）。
• 自定义头验证：要求XHR请求包含自定义头（如X-Requested-With），因为浏览器默认不允许跨域添加自定义头，但需注意预检请求的影响。
• 二次验证：对敏感操作要求重新认证（如密码确认）或使用一次性令牌。

6. 进阶绕过与注意事项

• 如果应用仅检查CSRF Token存在于请求体或URL参数中，攻击者可能通过Flash或重定向漏洞注入Token。
• 当CORS配置为允许任意源且带凭证时，XHR CSRF可直接跨域实施。
• 结合XSS漏洞可完全绕过CSRF防护，因为XSS可窃取Token并伪造请求。

通过理解XHR CSRF的攻击原理，开发人员可针对性地加强防御，尤其在前后端分离的Web应用中，需确保API接口的CSRF防护与CORS策略正确配置。