如果你是一名开发者最近在调试API接口时是不是经常遇到这样的场景前端传过来的JSON数据后端解析后直接拼接到了SQL语句里或者直接eval执行了你心里可能隐隐觉得这不太安全但又说不清具体风险在哪更不知道攻击者会怎么利用。这就是JSON注入。它不像SQL注入那样广为人知但危害同样巨大而且由于现代Web应用大量使用JSON进行数据交换它正变得越来越普遍。很多人以为用了JSON.parse就万事大吉实际上如果解析后的数据被“信任”并用于不安全的上文如数据库查询、系统命令、代码执行漏洞就产生了。本文不会堆砌晦涩的理论。我们将从一个渗透测试者使用Kali Linux和一名防御者后端开发者的双重视角用最直白的语言和可操作的案例带你彻底搞懂JSON注入。你会明白它到底是什么不是解析JSON出错而是数据被“误用”。攻击者怎么利用它我们将用Kali Linux下的工具模拟一次完整的攻击链。你该如何防御从代码层面给出具体、可落地的解决方案。无论你是想提升系统安全性的开发者还是对安全测试感兴趣的学习者这篇文章都能让你获得即学即用的知识。我们现在开始。1. 这篇文章真正要解决的问题为什么你的“安全”JSON接口依然危险很多开发者对输入安全的认知还停留在“防SQL注入”和“防XSS”上。当接口采用JSON格式通信时大家容易产生一种错觉JSON是结构化数据比原始的POST表单更安全更何况我们用了框架自带的RequestBody或json_decode。危险恰恰隐藏在这种“安全感”背后。JSON注入的核心问题不在于JSON格式本身而在于应用程序如何处理解析后的JSON数据。想象这样一个流程前端发送{username: admin, action: getProfile}后端用JSON.parse或RequestBody成功解析为对象。后端代码直接将username的值未经充分校验拼接到了数据库查询语句中String sql SELECT * FROM users WHERE username parsedJson.username ;如果攻击者发送的是{username: admin OR 11, action: getProfile}呢解析后username的值是admin OR 11拼接进SQL就会造成经典的SQL注入。攻击载荷是藏在合法的JSON结构里的。所以本文要解决的第一个关键认知是JSON注入是一种“上下文注入”漏洞。漏洞发生的上下文可能是SQL上下文JSON数据值被拼接到SQL查询中。OS命令上下文JSON数据值被传递给Runtime.exec()或system()等函数。代码执行上下文JSON数据值被用于动态脚本执行如JavaScript的eval、PHP的assert。NoSQL查询上下文JSON数据值被直接用于构建MongoDB、Elasticsearch的查询对象。路径遍历上下文JSON数据值被用于文件路径拼接。作为开发者你需要识别出代码中所有“解析JSON - 使用数据”的链条并判断使用环境是否安全。作为安全测试者你需要知道如何构造隐藏在JSON中的攻击载荷并利用工具高效测试。接下来我们将从攻击和防御两个角度彻底拆解这个问题。2. 基础概念与核心原理什么是JSON注入让我们抛开教科书定义用两句话讲清楚JSON注入JSON Injection是指攻击者通过向应用程序提交恶意构造的JSON数据利用应用程序对JSON数据的错误处理方式在目标系统上执行非预期操作的一种攻击手段。它的原理基于一个简单的逻辑链条信任边界模糊应用程序认为“既然数据是合法的JSON格式且通过了框架解析那么其内容就是可信的”。这是一个致命的错误假设。上下文混淆开发者没有区分“数据格式正确”和“数据内容安全”。JSON解析器只检查语法不检查语义。缺乏输出编码/校验解析后的数据被直接用于拼接字符串构造SQL、命令、代码等而没有根据目标上下文进行转义或严格校验。为了更清晰地理解它与其他注入漏洞的关系请看下表漏洞类型攻击载体注入点上下文核心问题SQL注入HTTP参数如?id1、表单字段SQL查询语句用户输入被直接拼接到SQL命令中命令注入HTTP参数、表单字段、系统变量操作系统命令如bash、cmd用户输入被直接拼接到系统命令中JSON注入HTTP请求体JSON格式SQL、命令、代码、NoSQL查询等JSON解析后的数据值被直接拼接到危险上下文中XSSHTTP参数、表单字段、数据库存储HTML、JavaScript上下文用户输入被直接输出到浏览器页面且未转义关键区别JSON注入的“包装”是JSON格式。攻击者需要将传统的攻击载荷如 OR 11嵌入到JSON字符串的值中。对于防御者来说传统的WAF或输入过滤器如果只检查原始字符串可能因为JSON的引号、转义符而绕过检测。3. 环境准备搭建一个存在JSON注入漏洞的靶场要理解攻击最好的方式是亲手实践。我们将使用Kali Linux和一款经典的漏洞练习平台DVWADamn Vulnerable Web Application来搭建测试环境。3.1 Kali Linux 基础准备Kali Linux是渗透测试和安全研究的首选系统预装了海量工具。如果你还没有Kali可以通过以下方式获取虚拟机安装从 Kali官网 下载ISO镜像在VMware或VirtualBox中安装。这是最推荐的方式隔离性好。Docker容器docker pull kalilinux/kali-rolling快速获取一个Kali环境。云实例在AWS、Azure或GCP上创建实例并安装Kali。确保你的Kali系统能正常联网并更新软件源sudo apt update sudo apt upgrade -y3.2 安装并配置DVWADVWA是一个故意设计存在漏洞的PHP/MySQL应用非常适合学习。安装LAMP栈DVWA需要Web服务器和数据库。sudo apt install -y apache2 mariadb-server php php-mysql libapache2-mod-php php-gd下载DVWAcd /var/www/html sudo git clone https://github.com/digininja/DVWA.git sudo chown -R www-data:www-data DVWA/配置数据库sudo mysql -u root # 在MySQL提示符下执行 CREATE DATABASE dvwa; CREATE USER dvwalocalhost IDENTIFIED BY pssw0rd; GRANT ALL PRIVILEGES ON dvwa.* TO dvwalocalhost; FLUSH PRIVILEGES; EXIT;配置DVWAcd /var/www/html/DVWA/config sudo cp config.inc.php.dist config.inc.php sudo nano config.inc.php修改以下关键配置$_DVWA[ db_server ] 127.0.0.1; $_DVWA[ db_database ] dvwa; $_DVWA[ db_user ] dvwa; $_DVWA[ db_password ] pssw0rd; $_DVWA[ default_security_level ] low; // 将安全级别设为“低”方便演示重启服务并访问sudo systemctl restart apache2在Kali的浏览器中访问http://localhost/DVWA/setup.php。点击页面底部的“Create / Reset Database”按钮初始化数据库。完成后使用默认账号admin/password登录。至此一个包含多种漏洞包括我们等下要利用的的测试环境就准备好了。4. 核心攻击流程拆解以JSON到SQL注入为例DVWA的“SQL Injection”关卡通常接收GET参数?id1。为了演示JSON注入我们需要稍微修改一下它的代码模拟一个接收JSON参数的API接口。这能让我们更贴近真实场景。4.1 构造一个易受攻击的JSON API端点在DVWA目录下创建一个新文件sudo nano /var/www/html/DVWA/vulnerabilities/json_sqli/注意实际路径可能需要你手动创建json_sqli目录。更简单的方法是我们直接修改一个现有文件。这里为了概念清晰我们描述逻辑你可以用以下PHP代码创建一个测试文件test_json.php放在DVWA根目录下。?php // test_json.php - 一个存在JSON注入漏洞的示例端点 header(Content-Type: application/json); // 模拟从请求体获取JSON数据 $json_input file_get_contents(php://input); $data json_decode($json_input, true); if (!$data) { echo json_encode([error Invalid JSON]); exit; } $user_id $data[id] ?? 1; // 危险直接从JSON中取id未做任何过滤 // 危险直接拼接SQL查询 $sql SELECT first_name, last_name FROM users WHERE user_id $user_id; // 连接数据库并执行查询此处省略具体连接代码假设已连接 // $result mysqli_query($link, $sql); // ... 处理结果并输出JSON ... // 为了演示我们只回显构造的SQL语句 echo json_encode([ received_id $user_id, generated_sql $sql, warning This endpoint is vulnerable! ]); ?这段代码的致命问题json_decode能成功解析{id: 1}也能解析{id: 1 OR 11}。后者会导致SQL语句被篡改。4.2 使用Kali工具进行渗透测试在真实测试中我们不会手动修改源码而是使用工具扫描和探测。这里我们使用Kali自带的Burp Suite和sqlmap来演示。场景假设我们发现一个API端点http://target.com/api/user/profile接受JSON格式的POST请求参数是{userId: 12345}。步骤一使用Burp Suite拦截与重放在Kali中启动Burp SuiteCommunity版即可。配置浏览器代理如Firefox为127.0.0.1:8080并安装Burp的CA证书。在浏览器中访问目标应用并提交一个正常的JSON请求。Burp会拦截到这个请求。将请求发送到Burp的Repeater模块方便我们修改和重放。在Repeater中将请求体修改为潜在的恶意载荷{userId: 12345 AND 12}或者尝试闭合JSON字符串并注释掉后续内容{userId: \ OR 11;-- }观察响应。如果响应与正常请求不同如返回了所有用户数据或报错说明可能存在注入点。步骤二使用sqlmap进行自动化注入测试sqlmap是自动化SQL注入检测和利用的神器。它可以处理JSON格式的注入点。将Burp拦截到的请求保存到一个文件如request.txt。请求应包含完整的HTTP头。在终端中使用sqlmapsqlmap -r request.txt --level3 --risk2 --batch-r request.txt从文件加载HTTP请求。--level3提高测试等级增加对User-Agent、Referer等头的测试。--risk2提高风险等级尝试更危险的负载。--batch以非交互模式运行自动选择默认选项。sqlmap会自动识别JSON参数如JSON id并对其进行一系列注入测试。如果存在漏洞它会给出数据库类型、版本、甚至直接dump数据。关键技巧如果参数在JSON中sqlmap可能需要指定参数前缀。可以使用--data和--param-delsqlmap -u http://target.com/api/user/profile --data{userId:*} --param-del* --batch这里*标记了注入点。通过这个流程你就能看到一个看似“安全”的JSON API是如何被传统注入工具轻易攻破的。攻击者不需要理解你的业务逻辑工具会自动完成探测和利用。5. 不仅仅是SQL其他类型的JSON注入示例JSON数据可以被误用到各种危险上下文中。以下是几个常见场景的代码示例5.1 命令注入Node.js示例// 危险代码 const express require(express); const { exec } require(child_process); const app express(); app.use(express.json()); app.post(/api/ping, (req, res) { const host req.body.host; // 直接从JSON中获取 // 致命漏洞用户输入直接进入命令 exec(ping -c 4 ${host}, (error, stdout, stderr) { res.send({ output: stdout }); }); });攻击载荷{host: 8.8.8.8; cat /etc/passwd}。这会执行ping命令后继续执行cat /etc/passwd。5.2 NoSQL注入MongoDB示例// 危险代码使用Mongoose app.post(/api/login, async (req, res) { const { username, password } req.body; // 直接将用户输入传入查询对象 const user await User.findOne({ username: username, password: password // 假设密码是明文存储这本身也是问题 }); if (user) { res.json({ success: true }); } else { res.json({ success: false }); } });攻击载荷{username: admin, password: {$ne: null}}。MongoDB会将其解析为查询条件password ! null这很可能为真从而绕过密码验证。5.3 代码注入PHP示例// 危险代码 $data json_decode(file_get_contents(php://input), true); $functionName $data[callback]; // 致命漏洞用户控制的字符串被直接用于函数调用 if (function_exists($functionName)) { $result $functionName(); echo json_encode($result); }攻击载荷{callback: system, args: rm -rf /}。虽然这个例子需要args也被传递但它说明了直接使用未经验证的函数名是极度危险的。6. 防御策略从开发源头堵住漏洞理解了攻击原理防御就有了清晰的方向。核心原则是永远不要信任用户输入无论它是什么格式。6.1 输入验证与白名单这是第一道也是最有效的防线。验证数据内容而不仅仅是格式。类型检查确保id是整数username是特定格式的字符串。范围/长度检查数字是否在合理范围内字符串长度是否有限制白名单验证对于枚举值如状态、类型只接受预定义的几个值。// Java Spring Boot 示例 - 使用注解进行验证 public class UserRequest { Min(1) // id必须大于0 private Integer id; Pattern(regexp ^[a-zA-Z0-9_]{3,20}$) // 用户名格式白名单 private String username; // getters and setters } PostMapping(/api/user) public ResponseEntity? updateUser(Valid RequestBody UserRequest request) { // 如果验证失败会抛出MethodArgumentNotValidException // 业务逻辑... }6.2 参数化查询应对SQL注入绝对不要拼接SQL字符串。使用预编译语句Prepared Statements或ORM框架的参数化查询。# Python Flask SQLAlchemy 示例 - 安全做法 from flask import request, jsonify from models import User from database import db_session app.route(/api/user/int:user_id, methods[GET]) def get_user(user_id): # 从路径获取已确保是int # 使用ORM自动参数化 user User.query.filter_by(iduser_id).first() # 或者使用原始SQL但也要参数化 # from sqlalchemy import text # stmt text(SELECT * FROM users WHERE id :id) # result db_session.execute(stmt, {id: user_id}) return jsonify(user.to_dict())6.3 安全的NoSQL查询避免直接将用户输入传递给查询构造器。使用框架提供的安全方法。// Node.js Mongoose 安全示例 app.post(/api/login, async (req, res) { const { username, password } req.body; // 先查找用户 const user await User.findOne({ username: username }); // 然后使用安全的比较函数如bcrypt验证密码 if (user await bcrypt.compare(password, user.passwordHash)) { res.json({ success: true }); } else { res.json({ success: false }); } });6.4 避免动态代码执行永远不要用eval()、setTimeout(userInput)、Function(userInput)或反序列化未经验证的数据如PHP的unserialize()。 如果需要动态调用请使用映射到白名单的方式const ALLOWED_CALLBACKS { getData: getDataFunction, calculate: calculateFunction }; const funcName req.body.callback; const func ALLOWED_CALLBACKS[funcName]; if (func) { func(); } else { throw new Error(Invalid callback); }6.5 输出编码与上下文感知如果必须将用户输入输出到其他上下文如生成动态HTML、JavaScript必须进行编码。HTML上下文使用HTML实体编码如变成lt;。JavaScript上下文使用JavaScript字符串编码。系统命令上下文避免直接拼接。如果必须使用严格的参数化方式如将参数作为数组传递给execFile。# Python subprocess 安全示例 import subprocess import shlex host request.json[host] # 假设已经过白名单验证如只允许IP地址 # 错误subprocess.run(fping -c 4 {host}, shellTrue) # 正确使用参数列表避免shell subprocess.run([ping, -c, 4, host], checkTrue)6.6 使用安全的JSON解析配置有些JSON解析库有“特性”可能导致问题。例如在PHP中json_decode($str, true)的第二个参数true表示返回数组这通常比返回对象更安全避免属性注入。在JavaScript中使用JSON.parse()而不是eval()。7. 常见问题与排查思路在实际开发和测试中你会遇到各种具体问题。下表汇总了典型场景问题现象可能原因排查方式解决方案工具如sqlmap无法检测到JSON注入点1. 注入点不在JSON中。2. 请求头Content-Type不是application/json。3. 工具有bug或版本旧。4. 存在WAF拦截了探测请求。1. 用Burp手动测试确认参数位置。2. 检查请求头是否正确。3. 更新工具到最新版。4. 尝试使用--tamper脚本绕过WAF。1. 确保sqlmap命令正确使用-r或--data指定了JSON数据。2. 手动在Burp中构造简单载荷如测试。后端代码使用了参数化查询但测试仍报告漏洞1. 报告可能是误报如静态扫描工具。2. 参数化使用不正确如拼接了表名、列名。3. 存在其他非SQL的注入点如命令、NoSQL。1. 人工审计代码确认SQL拼接点。2. 检查ORM查询中是否使用了字符串插值。3. 全面检查所有使用JSON数据的地方。1. 修复错误的参数化用法。2. 对表名、列名等使用白名单校验。JSON解析失败导致服务报错1. 客户端发送了畸形的JSON如缺少引号。2. 字符编码问题。3. 数据量过大。1. 查看服务端错误日志。2. 在代码中捕获JSON.parse或json_decode的异常。1. 实现健壮的解析对异常请求返回400错误。2. 对请求体大小做限制。防御代码已编写但不确定是否全覆盖1. 代码审查遗漏了某些接口。2. 第三方库或中间件引入了新的数据处理路径。1. 使用SAST静态应用安全测试工具扫描代码。2. 进行彻底的渗透测试特别是针对API接口。1. 建立代码安全审查流程。2. 将安全测试纳入CI/CD流水线。8. 最佳实践与工程建议将安全融入开发流程而不仅仅是事后补救。安全左移在需求设计和编码阶段就考虑安全。制定API安全规范明确所有输入的验证规则。使用安全的框架和库现代Web框架如Spring Security、Django、Laravel都提供了强大的输入验证和防护机制。优先使用它们而不是自己造轮子。依赖项安全定期使用npm audit、pip-audit、OWASP Dependency-Check等工具检查项目依赖的第三方库是否存在已知漏洞。自动化安全测试SAST在代码提交阶段使用SonarQube、Fortify、Checkmarx等工具进行静态分析。DAST在测试环境使用OWASP ZAP、Burp Suite Professional进行动态扫描。IAST在运行阶段使用交互式扫描工具。深度防御不要只依赖一层防护。结合输入验证、参数化查询、输出编码、最小权限原则和WAF。日志与监控记录所有失败的验证尝试、异常的输入模式。设置告警以便在遭受攻击时能快速响应。定期安全培训让开发团队了解最新的攻击手法和防御技术。JSON注入这类漏洞根源往往是开发者的安全意识不足。9. 总结与后续学习方向JSON注入的本质是“数据格式安全”不等于“数据内容安全”。它提醒我们在微服务和API驱动的架构下接口安全需要格外的关注。通过本文你应该已经掌握了攻击视角如何使用Kali Linux下的工具Burp Suite, sqlmap来探测和利用JSON注入漏洞。防御视角如何通过输入验证、参数化查询、避免危险函数等编码实践从根本上杜绝此类漏洞。要真正巩固这些知识建议你动手实验按照第3、4节的步骤在DVWA或自己搭建的简单应用上亲手完成一次从环境搭建到漏洞利用的完整过程。代码审计检查你正在维护的项目搜索JSON.parse、json_decode、RequestBody、express.json()等关键字然后跟踪这些数据的使用路径看是否存在危险的拼接操作。拓展学习了解相关的漏洞类型如XXEXML外部实体注入、反序列化漏洞、模板注入SSTI。它们与JSON注入有相似的逻辑——“解析”“误用”。关注工具更新安全工具和攻击技术都在不断进化。定期关注sqlmap、Burp Suite、OWASP ZAP等工具的更新日志和新特性。安全是一个持续的过程而非一劳永逸的状态。希望这篇文章能成为你构建更安全Web应用的一块坚实基石。建议收藏本文并在下次代码评审或设计API时将其作为一份实用的安全检查清单。