文章总结： 本文深入讲解SQL注入中参数类型与编码的进阶利用技术。内容涵盖注入原理、六大关键因素及JSON、XML、Base64格式下的Payload构造。通过真实SRC案例，解析发现URL路径异常并利用Base64编码绕过防护的过程。最后总结黑盒与白盒排查技巧，强调理解数据流转与工具利用的重要性。 综合评分： 89 文章分类： WEB安全,渗透测试,SRC活动,实战经验,漏洞分析
第54天-Web安全进阶：当SQL注入遭遇参数编码——从基础到实战
原创
萧瑶 萧瑶
AlphaNet
2026年2月26日 14:30 江苏
在Web安全领域，SQL注入是一个经典而持久的话题。随着防护手段的升级，攻击技术也在不断演变。当常规的’ or 1=1– +被WAF拦截时，攻击者是如何突破的？答案往往藏在参数类型、格式与编码的细节中。今天，我们就来深入探讨这个进阶话题，并通过一个真实案例，看看如何发现“隐藏”的注入点。
🧠 基石回顾：SQL注入核心知识
在探讨高级技巧前，让我们快速回顾一下基础知识。
· 数据库知识：我们攻击的目标通常是库名、表名、列名及其中数据。需要了解MySQL的information_schema、SQL Server的sysobjects等自带数据库，以及数据库用户权限（决定了你能执行多危险的操作）、敏感函数（如load_file()、xp_cmdshell）和默认端口（3306、1433等）。
· 产生原理：根本原因是代码中执行的SQL语句拼接了用户可控的变量，且未做严格过滤。
· 利用过程：一般遵循判断数据库类型 -> 判断参数类型/格式 -> 获取数据库名 -> 获取表名 -> 获取列名 -> 获取数据的流程。
🔍 影响SQL注入的六大关键因素
能否成功注入，以及如何注入，取决于以下因素的排列组合：
-
数据库类型：MySQL、MSSQL、Oracle的注入语法和函数各不相同。
-
数据操作方法：增、删、改、查（SELECT、INSERT、UPDATE、DELETE）的注入利用方式有别。
-
参数数据类型：数字型（无需闭合）、字符型（需闭合引号）、搜索型（需处理通配符%），这直接关系到符号干扰。
-
参数数据格式：明文、JSON、XML、编码（如Base64）、加密。这大大增加了注入的复杂度。
-
提交数据方式：GET、POST、Cookie、HTTP头等都可能成为注入点。
-
有无数据处理：有回显、无回显（布尔盲注、时间盲注）、报错回显等，决定了利用手段。
🚀 进阶篇：当参数“改头换面”
现代应用常采用结构化或编码后的数据格式进行传输，这使得简单的注入测试失效。以下是几种常见的高级场景：
- 数字、字符与搜索型注入（基础变形）
这是最基础的，但也是理解复杂注入的起点。关键在于“闭合”与“注释”。
-- 数字型：$id 直接传入
select \* from news where id=$id;
-- Payload: 1 union select 1,2,3 --
-- 字符型：$name 被引号包裹
select \* from news where name='$name';
-- Payload: xiaodi' union select 1,2,3 --
-- 搜索型：被 % 和引号包裹
select \* from news where name like '%$name%';
-- Payload: xiao%' union select 1,2,3 --
- XML与JSON注入
数据以结构化格式整体提交，注入点隐藏在某个字段值中。
XML数据示例：
<news>
<article>
<id>1</id> <!-- 此处可能是注入点 -->
<title>xiaodi</title> <!-- 此处也可能是注入点 -->
</article>
</news>
攻击者需要构造闭合XML标签的Payload，例如将id值改为：1
JSON数据示例：
{
"news": [
{
"id": 1, // 此处可能是注入点
"title": "xiaodi" // 此处也可能是注入点
}
]
}
测试时，需要将Payload放在JSON值的位置，并注意引号、花括号的闭合。
- 编码注入（以Base64为例）
这是最具隐蔽性的情况之一。应用收到数据后，会先解码再拼接到SQL语句中。
Base64编码后的JSON数据：
{
"news": [
{
"id": "MQ==", // 解码后是 "1"
"title": "eGlhb2Rp" // 解码后是 "xiaodi"
}
]
}
攻击者需要先构造明文Payload，如 1′ union select 1,2#，然后对其进行Base64编码得到 MScgdW5pb24gc2VsZWN0IDEsMiM=，再放入JSON的id字段中。如果应用处理不当，解码后的恶意代码将被执行。
🎯 实战案例：一次“奇怪”的SQL注入
我们来看一个真实的SRC漏洞案例（来源：深潜sec安全团队），它完美诠释了参数格式对注入的影响。
漏洞发现过程
-
初始碰壁：测试者在某个接口抓包后，对请求包中的所有GET/POST参数都进行了常规SQL注入测试（加单引号、and 1=1等），但均无任何异常回显或报错，似乎不存在漏洞。
-
发现异常点：在观察请求包时，测试者注意到URL路径中出现了两个连续的斜杠//，这显得很不寻常。正常的RESTful风格API通常是单斜杠，如/api/user/1。
-
关键尝试：测试者尝试在//之间插入一些SQL注入测试语句，如/api//user/1，结果服务器返回了提示：需要Base64编码。
-
柳暗花明：测试者立即将Payload进行Base64编码后放入路径中再次请求。这一次，服务器返回了数据库错误信息，证明存在SQL注入！并且通过后续测试确认，该注入点为双引号闭合的字符型注入。
-
成功利用：确认漏洞后，使用SQLMap并加载其内置的tamper/base64encode.py脚本，对所有注入Payload自动进行Base64编码，成功获取了数据库中的所有数据。
案例深度解析
这个案例之所以“奇怪”，是因为它结合了两种隐蔽手段：
· 非常规注入位置：注入点不在常见的参数值中，而是在URL的路径中。
· 强制数据编码：服务器要求路径参数必须为Base64格式，这天然“过滤”掉了大部分不带编码的扫描器的探测。
给你的启示
· 细心是金：不要放过任何一个异常点，比如奇怪的路径格式、特殊的HTTP头、隐藏的POST参数。
· 脑洞大开：测试时要思考数据的完整处理流程：它是如何被接收、解析、解码，最终拼接到SQL中的？
· 善用工具：SQLMap的tamper脚本库非常强大，学会使用base64encode.py、charencode.py等脚本，能帮你自动化处理很多编码/绕过问题。
💡 如何更好地发现SQL注入？
· 黑盒测试（模拟黑客）：
· 全面撒网：对请求中的每一个参数（包括GET、POST、Cookie、HTTP头）进行模糊测试。
· 格式感知：根据数据提交格式（JSON/XML）构造闭合Payload。
· 编码变异：尝试对Payload进行URL编码、Base64编码、Unicode编码等，观察服务器反应。
· 功能联想：搜索功能考虑%闭合，排序功能考虑order by后注入。
· 白盒测试（代码审计）：
· 追踪用户输入数据的流向，找到所有拼接SQL语句的地方。
· 重点关注数据在拼接前是否经过解码、反序列化等处理。
· 这部分更深入的内容，我们将在后续的代码审计课程中详细探讨。
📝 总结
SQL注入漏洞并未消失，它只是变得更隐蔽。理解参数数据类型、数据格式、编码方式对SQL语句的最终影响，是挖掘高级注入漏洞的关键。希望今天的笔记能为你打开一扇新的大门，在未来的安全测试中更加游刃有余。
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：AlphaNet 萧瑶 萧瑶《第54天-Web安全进阶：当SQL注入遭遇参数编码——从基础到实战》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论