JSON CSRF、Flash CSRF 与跨域场景下的 CSRF 变种分析

在 Web 安全领域，CSRF（跨站请求伪造）始终是一个经典且不断演进的攻击面。随着前后端分离架构的普及、富客户端技术的更迭以及跨域通信需求的增加，传统的 CSRF 防护策略——如仅依赖 Cookie 的 SameSite 属性或简单的 Referer 校验——在面对 JSON CSRF、Flash CSRF 以及各类跨域场景下的变种攻击时，往往显得力不从心。本文将深入剖析这几类 CSRF 变种的原理、利用条件与防御思路。

一、传统 CSRF 的局限性回顾

传统 CSRF 的核心在于：攻击者诱导已认证用户向目标站点发起非预期的状态变更请求，浏览器自动携带目标站点的 Cookie，服务器无法区分请求是否出自用户真实意愿。常规防御手段包括：

• CSRF Token：要求请求携带无法被攻击者预测的随机令牌。
• SameSite Cookie：限制跨站请求携带 Cookie。
• Referer/Origin 校验：检查请求来源是否合法。

然而，当请求体格式、客户端技术或跨域策略发生变化时，这些防御可能被绕过或失效。

二、JSON CSRF：Content-Type 的“盲区”

2.1 原理

现代 API 通常要求请求体为 application/json 格式。浏览器在发起跨域 fetch 或 XMLHttpRequest 时，若设置 Content-Type: application/json，会触发 CORS 预检请求（OPTIONS），服务器若未正确配置 CORS，则请求被阻止。因此，许多开发者认为 JSON 接口天然免疫 CSRF。

但攻击者可以利用以下技巧绕过：

1. 表单伪造 text/plain：HTML 表单的 enctype 可设为 text/plain，提交的请求体形如 {"key":"value","key2":"value2"}，虽然 Content-Type 为 text/plain，但若服务器端未严格校验 Content-Type，仍可能解析为 JSON。
2. Flash 的 application/json 支持：旧版 Flash 可通过 URLRequest 设置任意 Content-Type，且不受 CORS 限制（详见下文 Flash CSRF）。
3. 服务端解析宽松：部分框架（如旧版 Spring、Express 某些中间件）会自动尝试解析请求体为 JSON，无论 Content-Type 为何。

2.2 利用示例

假设目标接口 POST /api/updateEmail 接受 JSON 体 {"email":"new@example.com"}，且仅校验 Cookie。攻击者构造如下表单：

<form action="https://target.com/api/updateEmail" method="POST" enctype="text/plain">
  <input name='{"email":"attacker@evil.com","ignore":"' value='"}'>
</form>
<script>document.forms[0].submit();</script>

提交后请求体为 {"email":"attacker@evil.com","ignore":""}，若服务端解析成功，则攻击完成。

2.3 防御要点

• 严格校验 Content-Type，拒绝非 application/json 的请求。
• 使用 CSRF Token 并置于请求体或自定义头中（如 X-CSRF-Token），避免仅依赖 Cookie。
• 对 JSON 解析失败或字段异常进行日志与拦截。

三、Flash CSRF：被遗忘的跨域利器

3.1 原理

尽管 Adobe Flash 已于 2020 年底停止支持，但在一些遗留系统或特定内网环境中，Flash 仍是攻击者绕过同源策略的跳板。Flash 的 URLRequest 可设置任意 HTTP 方法、任意请求头（包括 Content-Type: application/json），并且可以携带浏览器 Cookie（若 crossdomain.xml 配置宽松或目标站点未正确限制）。

关键点在于：Flash 发起请求时，浏览器不会像 fetch 那样强制 CORS 预检，而是依赖 Flash 自身的跨域策略文件。若目标站点根目录下存在宽松的 crossdomain.xml（如 <allow-access-from domain="*" />），则任意域名的 Flash 文件均可向该站点发起请求并读取响应。

3.2 攻击场景

攻击者诱导用户访问恶意页面，页面中嵌入一个 SWF 文件。该 SWF 向目标站点发起 JSON 格式的 POST 请求，并携带用户 Cookie。由于 Flash 不受 CORS 限制，且可自定义 Content-Type，传统针对 JSON 接口的 CSRF 防御完全失效。

3.3 防御要点

• 严格限制 crossdomain.xml，避免使用通配符 *。
• 对敏感接口强制校验 CSRF Token 与 Origin 头。
• 及时淘汰依赖 Flash 的旧组件。

四、跨域场景下的 CSRF 变种

4.1 CORS 配置错误导致的 CSRF

若服务器将 Access-Control-Allow-Origin 反射为请求的 Origin，且 Access-Control-Allow-Credentials: true，则攻击者可从任意域发起带 Cookie 的跨域请求并读取响应。这本质上是 CSRF 与信息泄露的结合。

4.2 基于 window.open 与 postMessage 的变种

某些应用使用 postMessage 进行跨域通信，若未校验 event.origin，攻击者可通过恶意页面发送伪造消息，触发状态变更操作。

4.3 WebSocket CSRF

WebSocket 握手阶段会携带 Cookie，且不受同源策略限制。若服务器未校验 Origin 头，攻击者可利用恶意页面建立 WebSocket 连接，发送恶意指令。

4.4 防御统一思路

• 对所有状态变更请求强制 CSRF Token，且 Token 不应仅存于 Cookie。
• 严格校验 Origin 与 Referer，但不可作为唯一防线。
• 正确配置 CORS，避免反射 Origin 与通配符。
• 对 WebSocket 握手进行 Origin 校验。
• 使用 SameSite=Lax 或 Strict 作为基础加固。

五、安全加固建议汇总

六、结语

CSRF 并未因现代框架的普及而消亡，反而在 JSON、Flash、CORS、WebSocket 等场景下衍生出多种变种。安全从业者需跳出“Cookie + Token”的固定思维，从请求格式、客户端技术、跨域策略等多个维度审视攻击面。唯有纵深防御——结合 CSRF Token、Origin 校验、Content-Type 限制与安全配置——才能有效抵御这些不断演进的跨站请求伪造攻击。

未经允许不得转载：任鹏个人博客 » JSON CSRF、Flash CSRF 与跨域场景下的 CSRF 变种分析