文章总结： 本文系统解析JSON接口的十二类实战攻击手法，涵盖反序列化、JSONP、XXE、XSS、注入、CSRF及JSON劫持等，并提供红队测试Checklist与防御要点，强调Content-Type白名单、参数化查询及反序列化加固等关键措施，对Web安全测试具有实操参考价值。 综合评分： 88 文章分类： WEB安全,红队,渗透测试,漏洞分析
JSON攻击全解：从反序列化到CSRF的十二类实战手法
原创
Red Hunter Red Hunter
黑白之道
2026年10月2日 08:50 韩国
在小说阅读器读本章
去阅读
在公众号小说中沉浸阅读
导语：JSON在REST API（基于HTTP协议设计的接口规范）和AJAX应用里几乎是默认数据格式。但用得广不代表它安全——服务端解析不严、客户端eval不加过滤、Content-Type（HTTP头部字段，标识请求体的数据格式）随手切——这十二类JSON实战攻击，红队每天都在用。
一、JSON 的攻击面在哪
JSON（JavaScript Object Notation，JS对象标记）本身只是数据载体，攻击面集中在两端：服务端反序列化（不安全的库直接构造对象）和客户端解析（eval 这种”原始”调用方式）。常见踩点场景：
- 服务端把用户传入的 JSON 数据未经任何过滤直接写入响应流或文件
- 客户端用
eval()把 JSON 字符串当代码执行 - Content-Type 没做白名单，攻击者可以把
application/json改成application/xml，触发完全不同的解析器
只要 JSON 链路里有一环”裸奔”，下面 12 类攻击至少能跑通一半。
二、十二类 JSON 实战攻击
2.1 JSON 反序列化
最经典也最致命的一类。Jackson（Java生态的JSON处理库）、fastjson、Python pickle 这些库如果开了 enableDefaultTyping 或者允许 @type 字段，攻击者就能传入任意类名，触发 Gadget Chain（一连串反射调用链）拿 RCE（远程代码执行）。详细利用链可以参考 blackhat 这份论文：
https://www.blackhat.com/docs/us-17/thursday/us-17-Munoz-Friday-The-13th-JSON-Attacks-wp.pdf
2.2 JSONP（JSON Padding，JSON填充）
通过 callback 参数让服务器返回可执行的 JS（JavaScript脚本），跨域读取用户数据。Day-8 已经详细拆过，包括 Referer 绕过、CSP（Content-Security-Policy，内容安全策略）配置等手法，这里不重复。
2.3 暴力破解类
针对登录、密码重置、验证码接口跑字典。JSON 接口和传统 Web 没区别，重点盯接口限流（Rate Limiting）、账户锁定策略（Lockout Policy）、失败响应差异这三点。
2.4 XXE（XML External Entity，XML外部实体注入）
最容易被忽略的一招。JSON 接口后端如果同时支持 XML 解析，攻击者只需要把 Content-Type: application/json 改成 application/xml，再塞一段 XML 就能触发 XXE，读文件、SSRF（服务端请求伪造）甚至 RCE。
利用步骤：
- 抓一个 JSON 请求
- 改
Content-Type: application/xml - 插入 XML 实体 payload（外部实体引用，用于读取本地文件或触发SSRF）
- 看响应有没有回显文件内容
- Burp 有 Content Type Convertor 插件可以一键切换
2.5 XSS（Cross-Site Scripting，跨站脚本攻击）
JSON 接口本身不会触发 XSS，但如果前端把响应数据直接拼到 DOM（文档对象模型，即浏览器内部的页面元素树）里渲染，存储型或反射型 XSS 就来了。Fuzz 字典里塞 "><img src=x onerror=alert(1)> 这种 payload 测一轮。
2.6 注入类
和传统 Web 一样，SQL 注入（SQLi）、命令注入（CMDi）这些老朋友照样有效。比如登录接口：
{"username":"admin' OR '1'='1","password":"x"}
只要后端是字符串拼接而不是参数化查询，必中。判别诀窍：响应里的报错信息、时间差异、布尔盲注（通过页面真假两种响应反推数据库内容）差异。
2.7 文件包含 / 本地文件读取
后端如果有”读文件”这种功能，并且 path 参数没做白名单，可以直接打穿：
// 原始请求
{"user":"admin","path":"/admin.html"}
// 攻击 payload
{"user":"admin","path":"../../../../../../../../../../../etc/passwd"}
2.8 访问控制 / 逻辑漏洞
BAC（Broken Access Control，失效的访问控制）——用普通用户身份改 ID 看别人的订单、改 email 把别人的账户绑到自己邮箱下。这类问题更多是开发逻辑的锅，跟 JSON 本身没关系，但每个 JSON 接口都得过一遍。
2.9 CSRF（Cross-Site Request Forgery，跨站请求伪造）
JSON 接口默认不带 CSRF Token，所以默认就是 CSRF 易感。HTML 表单可以通过 enctype="application/json" 触发（部分浏览器支持），但更现实的打法是用 XSS 配合 fetch 直接发请求。
典型 Payload：
<form action="https://target/site/getuserinfo" method="POST"
enctype="application/json">
<input name='{"id":"1","email":"[email protected]"}' type='hidden'>
<input type="submit">
</form>
2.10 JSON Hijacking（JSON劫持）
JSONP 的”孪生兄弟”，利用 <script> 标签加载跨域 JSON 响应，通过覆盖原生 JS 对象（比如 Object.prototype 的 __defineSetter__）在数据被解析时窃取。现代浏览器已修复——但在 IE 老版本、内网环境、Hybrid App 里还能用。
2.11 其他常见漏洞
Mass Assignment（批量赋值，覆盖不应被外部修改的字段）、Open Redirect（开放重定向，跳转到任意URL）、Parameter Tampering（参数篡改）、Response Manipulation（响应篡改）、Session 缺陷——JSON 接口一个都跑不掉。
2.12 进阶攻击
论文 ExploitingJSON 里提的几个冷门但有意思的攻击：
- String Defracturing：利用字符串拆分绕过 WAF（Web应用防火墙）的关键字匹配
- Malicious Hashing：构造哈希冲突拖慢服务
- Fused Proxy Attack：JSON↔XML 类型切换做协议跳跃
- JSON-XML Banner Grabbing：通过响应差异识别后端栈
三、红队测试 Checklist
打 JSON 接口时，按这个顺序过一遍，效率最高：
- 抓包改 Content-Type —— application/json ↔ application/xml，看后端解析器
- 注入
<>和引号 —— 触发 XSS 和注入类问题 - 路径参数遍历 —— 看有没有本地文件读取
- 测 IDOR（Insecure Direct Object Reference，不安全直接对象引用） —— 改 user_id / order_id 越权
- Fuzz callback 参数 —— JSONP / Hijacking 链路
- 看报错 —— 反序列化类的报错信息最值钱，能直接定位类名
四、防御要点
- 服务端反序列化关掉 DefaultTyping，或加
@JsonIgnoreType黑名单 - Content-Type 严格白名单（只接受
application/json） - 全链路参数化查询，禁字符串拼接
- 接口加 Rate Limiting + 锁定策略
- 关键操作加 CSRF Token / SameSite Cookie
- 前端渲染 JSON 数据必须 HTML 转义
JSON 不是银弹。攻击面换了一种姿势，攻击者照打不误。
原文出处：learn365 Day-9 JSON Attacks 参考论文：The 13th JSON Attacks
👇 点击阅读原文，访问我的网站
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：黑白之道 Red Hunter Red Hunter《JSON攻击全解：从反序列化到CSRF的十二类实战手法》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论