在渗透测试和安全研究领域，JSON注入是一个常被提及但容易被误解的漏洞。很多初学者将其与SQL注入混淆，或者认为它只存在于老旧系统中。实际上，随着RESTful API和前后端分离架构的普及，JSON注入的风险不减反增。本文将彻底拆解JSON注入的原理，并用最直白的语言和可实操的Kali Linux环境，带你从零理解、复现并防御这种漏洞。无论你是刚接触Web安全的新手，还是想巩固知识体系的开发者，都能通过本文构建一套完整的认知和实践框架。
1. 背景与核心概念：JSON注入到底是什么？
在深入技术细节之前，我们首先要厘清一个关键问题：JSON注入究竟是什么，以及它为什么危险？
简单来说，JSON注入是一种针对应用程序处理JSON（JavaScript Object Notation）数据时的攻击手段。当应用程序在接收、解析或使用JSON数据时，如果未对用户输入进行严格的验证、过滤或转义，攻击者就有可能注入恶意的JSON结构或代码片段，从而破坏应用程序的逻辑、窃取数据或执行非预期的操作。
很多人会问：“这和SQL注入有什么区别？” 这是一个非常好的问题。两者的核心区别在于攻击的目标和影响层面：
- SQL注入：攻击目标是数据库。通过注入恶意的SQL代码，攻击者可以操纵数据库查询，实现数据窃取、篡改甚至删除。
- JSON注入：攻击目标通常是应用程序逻辑或客户端浏览器。它可能影响的是数据解析器、业务逻辑判断，或者在极端情况下，通过JSONP（JSON with Padding）等机制导致客户端脚本执行（XSS）。
JSON注入的常见场景包括：
- API参数污染：向API接口的JSON body或参数中注入额外的键值对，试图覆盖原有参数、提升权限或触发逻辑错误。
- 数据解析器攻击：利用目标系统使用的JSON解析库（如
eval()、JSON.parse的某些不安全用法）的漏洞，注入非法字符或结构，导致解析器崩溃或行为异常。 - 客户端模板注入：在现代前端框架（如Vue.js, React, Angular）中，如果直接将未净化的JSON数据绑定到模板，可能造成客户端脚本执行。
- NoSQL注入：当应用程序使用MongoDB等NoSQL数据库，并且查询条件由前端JSON直接构建时，注入特定的操作符（如
$ne,$gt）可能绕过认证或查询到非授权数据。
理解JSON注入，关键在于认识到**“数据”与“代码”的边界是模糊的**。当应用程序将用户输入的“数据”不加甄别地当作“代码”（或代码结构的一部分）来执行或解析时，漏洞就产生了。
2. 环境准备与版本说明
为了实战复现和理解JSON注入，我们需要一个可控的环境。Kali Linux是渗透测试的标准系统，内置了大量安全工具。我们将使用它来搭建靶场和进行攻击演示。
核心环境说明：
- 操作系统：Kali Linux 2024.x 或更高版本。本文命令在Kali 2024.4上测试通过，但核心思路适用于多数Linux发行版。
- Web服务器：Apache2。用于托管我们简单的漏洞演示页面。
- 编程语言：PHP。因其易于快速搭建含漏洞的Web应用，且JSON处理逻辑清晰。同时会用到Python3来编写攻击脚本。
- 浏览器与工具：Firefox（自带开发者工具）、
curl命令行工具、Burp Suite Community Edition（用于拦截和修改请求，可选）。
版本兼容性提示：本文重点在于原理和方法的传授，所有代码示例均注重逻辑而非特定版本。只要你的环境能运行Apache、PHP和Python，即可跟随操作。无需纠结于完全一致的版本号。
环境搭建步骤：
2.1 更新系统并安装必要软件
首先，打开终端，更新软件包列表并安装Apache和PHP。
sudo apt update && sudo apt upgrade -y sudo apt install apache2 php libapache2-mod-php -y安装完成后，启动Apache服务并设置为开机自启。
sudo systemctl start apache2 sudo systemctl enable apache2验证安装，在浏览器访问http://localhost，应能看到Apache的默认页面。
2.2 创建漏洞演示项目目录
我们在Apache的Web根目录下创建一个专属文件夹。
sudo mkdir /var/www/html/json_injection_demo sudo chown -R $USER:$USER /var/www/html/json_injection_demo cd /var/www/html/json_injection_demo现在，我们的工作环境就准备好了。接下来，我们将在这里创建含有JSON注入漏洞的代码文件。
3. 核心原理与漏洞场景拆解
要利用漏洞，必须先理解其产生的根源。我们从几个典型的漏洞场景入手，用代码说话。
3.1 场景一：不安全的eval()或json_decode用法（PHP）
这是最经典的漏洞模式。应用程序使用eval()函数来处理包含JSON的字符串，或者错误地使用了json_decode。
漏洞代码示例 (vulnerable1.php):
<?php // vulnerable1.php - 不安全的JSON处理 header('Content-Type: application/json'); // 模拟从客户端接收的JSON字符串 $input_json = isset($_POST['data']) ? $_POST['data'] : '{"name":"guest","role":"user"}'; // 危险操作：试图将JSON字符串转换为关联数组，但逻辑有严重缺陷 // 开发者本想用 json_decode，但错误地或因为历史原因使用了 eval // 注意：这是一个刻意构造的极端例子，用于演示原理。现实中可能是间接导致的。 if (isset($_GET['use_bad_logic']) && $_GET['use_bad_logic'] == '1') { // 错误示例：拼接字符串后eval (绝对禁止在生产中使用！) $data_str = "\$data = " . $input_json . ";"; @eval($data_str); // 高危！用户输入的 $input_json 被直接执行。 echo json_encode($data); } else { // 正确示例：使用 json_decode $data = json_decode($input_json, true); // true 表示返回关联数组 if ($data === null) { echo json_encode(['error' => 'Invalid JSON']); } else { // 但这里依然没有对$data的内容进行验证！ echo json_encode(['message' => 'Hello, ' . $data['name'], 'role' => $data['role']]); } } ?>漏洞分析：当use_bad_logic=1时，代码将用户输入的$_POST[‘data’]直接拼接进一个PHP赋值语句，然后交给eval()执行。如果攻击者提交的data参数不是合法的JSON对象，而是一段PHP代码，例如：
"; phpinfo(); //拼接后的字符串变为$data = “; phpinfo(); //”;，eval()就会执行phpinfo()函数，导致服务器信息泄露。即使不使用eval，如果后续业务逻辑严重依赖json_decode解析后的数组键值，且未做验证，也可能产生逻辑漏洞。
3.2 场景二：客户端JavaScript的JSON.parse与动态执行
前端JavaScript同样存在风险。
漏洞代码示例 (vulnerable2.html):
<!DOCTYPE html> <html> <head> <title>不安全的JSON解析示例</title> </head> <body> <h2>用户信息加载器</h2> <div id="output">等待加载数据...</div> <script> // 模拟从某个不安全的API获取的JSON数据 // 假设这个JSON字符串可能被攻击者控制或污染 const maliciousJsonString = `{"user": "alice", "data": "<img src=x onerror='alert(\"XSS via JSON!\")'>"}`; try { const userObj = JSON.parse(maliciousJsonString); // 危险操作：直接将对象属性插入HTML，未做任何转义 document.getElementById('output').innerHTML = ` <p>用户名: ${userObj.user}</p> <p>附加数据: ${userObj.data}</p> `; } catch (e) { document.getElementById('output').textContent = '解析JSON失败: ' + e.message; } </script> </body> </html>漏洞分析：这个例子中，JSON.parse本身是安全的，它只会解析合法的JSON字符串。漏洞点在于后续操作。我们将解析后对象userObj的属性data，通过模板字符串直接插入到了innerHTML中。如果data的值包含HTML/JavaScript代码（如``），浏览器就会将其作为HTML解析并执行其中的onerror事件，从而触发跨站脚本攻击（XSS）。这可以看作是一种通过JSON数据传递的“存储型XSS”变种。
3.3 场景三：NoSQL注入（以MongoDB为例）
在Node.js + MongoDB的架构中，如果查询语句直接由客户端JSON构建，极易发生注入。
漏洞代码示例 (Node.js逻辑):
// 危险的登录逻辑 app.post('/login', (req, res) => { const user = req.body.user; const pass = req.body.pass; // 直接使用用户输入构建查询对象 const query = { username: user, password: pass }; // 执行数据库查询 db.users.findOne(query, (err, user) => { if (user) { res.send('登录成功！'); } else { res.send('用户名或密码错误！'); } }); });漏洞分析：攻击者可以通过Burp Suite等工具拦截登录请求，将POST body从标准的JSON格式{“user”: “admin”, “pass”: “123456”}修改为：
{ "user": "admin", "pass": {"$ne": null} }在MongoDB中，$ne是“不等于”的操作符。上述查询条件意味着“查找用户名是admin，且密码不等于null的文档”。只要admin用户的密码字段不为空，这个查询就会返回结果，从而让攻击者在不知道密码的情况下以admin身份登录。这就是一个典型的NoSQL注入。
4. 完整实战案例：搭建、攻击与演示
现在，我们将创建一个完整的、包含上述多种漏洞的简易靶场，并在Kali Linux上发起模拟攻击。
4.1 创建靶场文件
在之前创建的/var/www/html/json_injection_demo目录下，创建以下文件：
1. 服务端漏洞文件 (server_vuln.php):
<?php // server_vuln.php header('Content-Type: application/json'); $raw_input = file_get_contents('php://input'); $data = json_decode($raw_input, true); if (!$data) { echo json_encode(['error' => 'Invalid JSON received']); exit; } // 场景1：逻辑漏洞 - 通过注入额外的JSON键值对来改变程序行为 $expected_role = 'user'; if (isset($data['role_override'])) { // 本应是内部变量，但被暴露和覆盖 $expected_role = $data['role_override']; } // 模拟用户数据库查询（极简版） $users = [ 'alice' => ['password' => 'alice123', 'role' => 'user'], 'bob' => ['password' => 'bob456', 'role' => 'user'], 'admin' => ['password' => 'admin789', 'role' => 'admin'] ]; $username = $data['username'] ?? ''; $password = $data['password'] ?? ''; $auth_success = false; $user_role = ''; if (isset($users[$username]) && $users[$username]['password'] === $password) { $auth_success = true; $user_role = $users[$username]['role']; } // 场景2：不安全的输出 - 直接将用户控制的数据拼接入响应JSON $response = [ 'success' => $auth_success, 'message' => $auth_success ? "Welcome, $username!" : "Login failed.", 'detected_role' => $user_role, 'expected_role_for_check' => $expected_role, 'is_admin' => ($user_role === 'admin') ? true : false, // 高危：将未经处理的用户输入直接嵌入响应 'debug_info' => $data['debug_note'] ?? 'No debug note provided.' ]; echo json_encode($response); ?>2. 前端测试页面 (test_client.html):
<!DOCTYPE html> <html> <head> <title>JSON注入测试客户端</title> <script src="https://code.jquery.com/jquery-3.6.0.min.js"></script> <style>body { font-family: sans-serif; margin: 40px; } pre { background: #eee; padding: 10px; }</style> </head> <body> <h2>JSON注入测试面板</h2> <div> <h3>正常登录</h3> <input type="text" id="user" placeholder="用户名" value="alice"><br> <input type="text" id="pass" placeholder="密码" value="alice123"><br> <button onclick="normalLogin()">正常登录</button> </div> <hr> <div> <h3>注入攻击测试</h3> <p>修改以下JSON，然后点击“注入攻击”。</p> <textarea id="jsonPayload" rows="10" cols="80"> { "username": "alice", "password": "alice123", "role_override": "admin", "debug_note": "<script>alert('XSS可能发生在这里')</script>" } </textarea><br> <button onclick="injectionAttack()">注入攻击</button> </div> <hr> <h3>服务器响应：</h3> <pre id="response">响应将显示在这里...</pre> <script> function normalLogin() { const payload = { username: $('#user').val(), password: $('#pass').val() }; sendRequest(payload); } function injectionAttack() { let payload; try { payload = JSON.parse($('#jsonPayload').val()); } catch(e) { alert('无效的JSON: ' + e.message); return; } sendRequest(payload); } function sendRequest(payload) { $('#response').text('发送请求中...'); $.ajax({ url: 'server_vuln.php', type: 'POST', data: JSON.stringify(payload), contentType: 'application/json', dataType: 'json', success: function(resp) { $('#response').text(JSON.stringify(resp, null, 2)); // 危险：如果响应中的debug_info含有脚本，且我们用它来操作DOM，可能触发XSS // 例如：$('#someDiv').html(resp.debug_info); }, error: function(xhr, status, error) { $('#response').text('请求失败: ' + error); } }); } </script> </body> </html>4.2 启动服务并访问
确保Apache正在运行。在Kali的浏览器中访问：
http://localhost/json_injection_demo/test_client.html4.3 发起模拟攻击
- 正常登录：点击“正常登录”按钮，观察响应。你会看到
success: true，但is_admin: false，因为alice的角色是user。 - 注入攻击：
- 在文本框中，我们已经预置了一个攻击载荷。注意看，我们在JSON中添加了两个原本不应该由客户端提交的字段：
”role_override”: “admin”：尝试覆盖服务端用于比较的角色变量。”debug_note”: “<script>alert(‘XSS’)</script>“：尝试注入一个HTML/JS片段到响应中。
- 点击“注入攻击”按钮。
- 在文本框中，我们已经预置了一个攻击载荷。注意看，我们在JSON中添加了两个原本不应该由客户端提交的字段：
- 分析结果：
- 查看服务器响应。你会发现
expected_role_for_check字段的值变成了”admin”，这说明我们成功地从客户端覆盖了服务端的一个内部逻辑变量。 is_admin字段仍然是false，因为数据库里alice的角色没变。但这个例子清晰地展示了通过添加额外JSON字段干扰服务端逻辑的攻击路径。debug_info字段完整地返回了我们注入的脚本字符串。如果前端有另一个功能不慎将debug_info的内容用innerHTML或jQuery.html()插入页面，那么``就会被执行，造成XSS。
- 查看服务器响应。你会发现
4.4 使用curl进行命令行攻击
Kali的强大之处在于命令行工具。我们离开浏览器，用curl来模拟更真实的攻击。
测试正常请求：
curl -X POST http://localhost/json_injection_demo/server_vuln.php \ -H "Content-Type: application/json" \ -d '{"username":"bob","password":"bob456"}'预期返回成功的JSON。
进行NoSQL风格注入（逻辑绕过）：假设我们的PHP后端逻辑有缺陷，使用了松散的比较（==而非===），并且密码检查逻辑是直接比较字符串。我们可以尝试注入一个非字符串类型。
curl -X POST http://localhost/json_injection_demo/server_vuln.php \ -H "Content-Type: application/json" \ -d '{"username":"admin","password":{"$ne":"wrongpass"}}'虽然我们的PHP示例没有模拟MongoDB查询，但这个请求会向服务器发送一个复杂的password字段（一个对象）。如果服务器端的密码比较代码没有做严格的类型检查（例如用了==），可能会产生非预期的行为，比如类型转换导致比较结果为真。这演示了通过改变JSON数据类型进行攻击的思路。
进行数据污染攻击：
curl -X POST http://localhost/json_injection_demo/server_vuln.php \ -H "Content-Type: application/json" \ -d '{"username":"alice","password":"alice123","role_override":"super_admin","debug_note":"\"});}//恶意代码"}'这个载荷在debug_note中包含了闭合符号”});}，如果服务器端在生成响应时是直接将JSON字符串拼接起来，这些字符可能导致响应JSON结构被破坏，甚至闭合了原有的JSON对象，为后续的脚本注入创造机会。
通过以上实战，你应该对JSON注入的几种常见形式有了直观的感受：添加非法字段、污染数据内容、改变数据类型。
5. 常见问题与排查思路
在开发和测试过程中，如何发现和定位JSON注入漏洞？下表总结了一些常见现象和排查方向。
| 问题现象 | 可能原因 | 排查思路与解决方案 |
|---|---|---|
| API接口接受JSON输入后，返回了非预期的数据或错误信息。 | 服务端未过滤JSON中的额外字段，这些字段干扰了内部逻辑。 | 1. 审查API处理代码，确认是否只提取了需要的字段。 2. 使用白名单机制，在解析后丢弃所有未明确声明的字段。 3. 使用严格的JSON Schema进行验证。 |
| 前端页面在显示从API获取的JSON数据后，出现了奇怪的弹窗或布局错乱。 | 响应JSON中包含了未转义的HTML/JS代码，并被直接插入DOM（XSS）。 | 1. 检查前端渲染数据的地方，是否使用了.innerHTML、.html()或v-html等危险方法。2. 确保对所有来自后端的数据在渲染前进行正确的转义（如使用 .textContent、.text()或模板引擎的自动转义功能）。3. 设置CSP（内容安全策略）头。 |
使用json_decode()或JSON.parse()时，程序抛出解析异常或崩溃。 | 用户提交了格式畸形、超深嵌套或超大的JSON，旨在耗尽服务器资源或触发解析器漏洞。 | 1. 在解析前，对JSON字符串的长度进行限制。 2. 使用健壮的解析库，并做好 try-catch异常处理。3. 对递归解析的深度进行限制（如果解析库支持）。 |
基于JSON的搜索或登录功能，在输入某些特殊字符（如$、.、{、}）时行为异常。 | 可能存在NoSQL注入，用户输入被直接传递给了数据库查询构造器。 | 1. 审查数据库查询代码，避免直接拼接用户输入。 2. 使用ORM或查询构建器提供的参数化查询方法。 3. 对用户输入进行严格的类型转换（如确保密码是字符串，不是对象或数组）。 |
客户端JavaScript使用eval()或new Function()来处理JSON字符串。 | 这是极高危的操作，会导致任意代码执行。 | 1.绝对禁止使用eval()处理任何来自网络或用户的数据。2. 使用 JSON.parse()替代，并做好异常捕获。3. 进行代码审计，全局搜索并移除 eval()的不安全用法。 |
6. 最佳实践与工程建议
防御JSON注入，需要在软件开发的各个阶段建立防线。
6.1 输入验证与过滤（第一道防线）
- 使用强类型：在强类型语言（如Java, C#， Go）中，定义明确的DTO（Data Transfer Object）或模型类来接收反序列化后的JSON对象。框架（如Spring Boot的
@RequestBody）会自动进行类型绑定和基础验证。 - 采用JSON Schema：在动态类型语言（如PHP, Python, Node.js）中，使用JSON Schema定义API合约。在解析JSON后，立即用Schema验证其结构、字段类型、取值范围、是否必需等。这是最有效的验证手段之一。
- 白名单原则：解析后，只取出你明确需要的字段，忽略其他所有额外字段。不要将整个解析后的对象不加选择地传递给业务函数。
6.2 安全解析与处理
- 使用安全的解析库：始终使用标准库提供的
JSON.parse()（JavaScript）、json_decode()（PHP）、json.loads()（Python）等函数。永远不要自己用字符串拼接、正则表达式或eval()来解析JSON。 - 设置解析选项：许多解析库提供了安全选项。例如，PHP的
json_decode()可以设置最大深度JSON_DEPTH；Python的json.loads()可以避免通过object_hook等参数执行意外代码。 - 处理解析错误：一定要捕获并妥善处理解析异常。向客户端返回统一的、信息量有限的错误消息（如“请求格式错误”），避免泄露堆栈信息等内部细节。
6.3 输出编码与转义（防止XSS）
- 上下文感知的转义：数据输出到哪里，就采用对应的转义方式。
- 输出到HTML正文：使用HTML实体编码（如
<转成<）。 - 输出到HTML属性：同样使用HTML实体编码，并始终用引号包裹属性值。
- 输出到JavaScript代码或JSON中：使用JSON编码（
JSON.stringify）。 - 输出到URL参数：使用URL编码。
- 输出到HTML正文：使用HTML实体编码（如
- 利用框架特性：现代前端框架（React, Vue, Angular）默认会对绑定到模板的数据进行HTML转义。除非你明确使用危险函数（如
dangerouslySetInnerHTML、v-html），否则是相对安全的。但切记，这种安全只针对HTML上下文。
6.4 安全配置与架构
- 设置正确的HTTP头：
Content-Type: application/json：确保服务器和客户端都正确声明和检查此头，防止MIME类型混淆攻击。Content-Security-Policy (CSP)：有效遏制XSS的影响，即使有恶意脚本被注入，CSP也能阻止其执行。
- 最小权限原则：运行应用程序的进程或容器应具有完成其功能所需的最小权限。这样即使被攻破，攻击者能做的事情也有限。
- 依赖项管理：定期更新项目所使用的JSON解析库和其他相关依赖，以获取安全补丁。
6.5 测试与审计
- DAST（动态应用安全测试）：使用OWASP ZAP、Burp Suite等工具对API进行自动化扫描，主动发送畸形的、包含注入载荷的JSON请求，观察应用响应。
- SAST（静态应用安全测试）：在代码层面使用工具（如SonarQube, Semgrep）扫描不安全的代码模式，例如搜索
eval()、JSON.parse与innerHTML的连用等。 - 代码审查：将JSON处理逻辑作为代码审查的重点。特别关注从请求到数据库查询，再到响应输出的完整数据流。
7. 总结与学习路线
通过本文的讲解和实战，我们系统性地剖析了JSON注入漏洞。它不像SQL注入那样直接“拖库”，但其危害同样不可小觑，轻则导致逻辑错误、数据泄露，重则引发权限提升甚至远程代码执行。
核心要点回顾：
- 本质是信任边界问题：JSON注入源于应用程序过度信任客户端提交的、结构化的数据。
- 攻击面多样：可从服务端逻辑（字段注入、类型混淆）、客户端渲染（XSS）、数据库查询（NoSQL注入）等多个层面发起。
- 防御需要纵深：单一措施无法完全防护，必须结合输入验证、安全解析、输出编码、安全配置和持续测试。
后续学习建议：
- 深入理解Web安全基础：建议系统学习OWASP Top 10，理解注入、XSS、失效的访问控制等核心漏洞的原理。
- 熟练使用安全工具：在Kali Linux上，继续探索Burp Suite、OWASP ZAP、sqlmap（也支持一些NoSQL注入测试）等工具，学习如何自动化地发现和利用JSON注入等漏洞。
- 搭建并练习靶场：在DVWA（Damn Vulnerable Web Application）、WebGoat或PortSwigger的Web Security Academy中，都有关于JSON注入、XSS等相关漏洞的实战练习，这是巩固知识的最佳途径。
- 关注新兴技术风险：GraphQL API、gRPC等新技术在数据传输格式和处理方式上有所不同，但信任边界和安全原则是相通的，学会举一反三。
安全是一个持续的过程，而非一劳永逸的状态。将本文介绍的安全编码实践融入到日常开发习惯中，在设计和代码审查阶段就考虑安全问题，才能从根本上构建更健壮、更可信的应用程序。
