在渗透测试和安全研究领域JSON注入是一个常被提及但容易被误解的漏洞。很多初学者将其与SQL注入混淆或者认为它只存在于老旧系统中。实际上随着RESTful API和前后端分离架构的普及JSON注入的风险不减反增。本文将彻底拆解JSON注入的原理并用最直白的语言和可实操的Kali Linux环境带你从零理解、复现并防御这种漏洞。无论你是刚接触Web安全的新手还是想巩固知识体系的开发者都能通过本文构建一套完整的认知和实践框架。1. 背景与核心概念JSON注入到底是什么在深入技术细节之前我们首先要厘清一个关键问题JSON注入究竟是什么以及它为什么危险简单来说JSON注入是一种针对应用程序处理JSONJavaScript Object Notation数据时的攻击手段。当应用程序在接收、解析或使用JSON数据时如果未对用户输入进行严格的验证、过滤或转义攻击者就有可能注入恶意的JSON结构或代码片段从而破坏应用程序的逻辑、窃取数据或执行非预期的操作。很多人会问“这和SQL注入有什么区别” 这是一个非常好的问题。两者的核心区别在于攻击的目标和影响层面SQL注入攻击目标是数据库。通过注入恶意的SQL代码攻击者可以操纵数据库查询实现数据窃取、篡改甚至删除。JSON注入攻击目标通常是应用程序逻辑或客户端浏览器。它可能影响的是数据解析器、业务逻辑判断或者在极端情况下通过JSONPJSON 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_logic1时代码将用户输入的$_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 idoutput等待加载数据.../div script // 模拟从某个不安全的API获取的JSON数据 // 假设这个JSON字符串可能被攻击者控制或污染 const maliciousJsonString {user: alice, data: img srcx onerroralert(\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 titleJSON注入测试客户端/title script srchttps://code.jquery.com/jquery-3.6.0.min.js/script stylebody { font-family: sans-serif; margin: 40px; } pre { background: #eee; padding: 10px; }/style /head body h2JSON注入测试面板/h2 div h3正常登录/h3 input typetext iduser placeholder用户名 valuealicebr input typetext idpass placeholder密码 valuealice123br button onclicknormalLogin()正常登录/button /div hr div h3注入攻击测试/h3 p修改以下JSON然后点击“注入攻击”。/p textarea idjsonPayload rows10 cols80 { username: alice, password: alice123, role_override: admin, debug_note: scriptalert(XSS可能发生在这里)/script } /textareabr button onclickinjectionAttack()注入攻击/button /div hr h3服务器响应/h3 pre idresponse响应将显示在这里.../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 /html4.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”: “scriptalert(‘XSS’)/script“尝试注入一个HTML/JS片段到响应中。点击“注入攻击”按钮。分析结果查看服务器响应。你会发现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代码并被直接插入DOMXSS。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中定义明确的DTOData 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_DEPTHPython的json.loads()可以避免通过object_hook等参数执行意外代码。处理解析错误一定要捕获并妥善处理解析异常。向客户端返回统一的、信息量有限的错误消息如“请求格式错误”避免泄露堆栈信息等内部细节。6.3 输出编码与转义防止XSS上下文感知的转义数据输出到哪里就采用对应的转义方式。输出到HTML正文使用HTML实体编码如转成lt;。输出到HTML属性同样使用HTML实体编码并始终用引号包裹属性值。输出到JavaScript代码或JSON中使用JSON编码JSON.stringify。输出到URL参数使用URL编码。利用框架特性现代前端框架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注入等漏洞。搭建并练习靶场在DVWADamn Vulnerable Web Application、WebGoat或PortSwigger的Web Security Academy中都有关于JSON注入、XSS等相关漏洞的实战练习这是巩固知识的最佳途径。关注新兴技术风险GraphQL API、gRPC等新技术在数据传输格式和处理方式上有所不同但信任边界和安全原则是相通的学会举一反三。安全是一个持续的过程而非一劳永逸的状态。将本文介绍的安全编码实践融入到日常开发习惯中在设计和代码审查阶段就考虑安全问题才能从根本上构建更健壮、更可信的应用程序。
