极详深度笔记SQL注入快速判定与应对策略1. 简述与核心观念核心观念为何要做“人形扫描器”WAF现状现代WAF防火墙规则库非常完善常规扫描器如AWVS、AppScan的自动Payload如AND 11极易被拦截或封禁IP 。漏网之鱼老网站并非唯一目标新网站因开发人员疏忽如未覆盖所有参数、无法使用预编译的场景依然存在大量注入 。法律红线高危预警红线标准在SRC或授权测试中证明漏洞存在的边界是获取database()库名或user()当前用户。严禁操作严禁执行dump脱库、严禁读取公民个人信息、严禁在DELETE/UPDATE/INSERT业务点使用扫描器可能导致批量删库或垃圾数据污染。注入类型的深度分类按数据类型整型 (Integer)select * from users where id 1。参数直接参与运算无需闭合引号 。字符型 (String)select * from users where id 1。参数被引号包裹占比最高必须先闭合引号才能执行后续语句 。按位置常规GET/POST 参数。JSON注入常见于API接口需注意JSON格式破坏问题 。排序注入 (Order By)重难点。出现在ORDER BY后面。因为ORDER BY后的参数如果是字符串如1会导致排序功能失效所以开发人员往往无法使用预编译Prepare Statement只能直接拼接导致必然存在注入风险 。2. 常规注入手动判定无视WAF技巧整型判定 (Integer Injection)核心原理数据库会将数学运算结果作为参数值执行。WAF通常只拦截SQL关键字不拦截数字运算。减法运算首选推荐操作输入id2-1。现象如果页面返回的内容与id1的内容完全一致且与id2不同则证明数据库执行了减法运算存在注入 。加法运算避坑指南操作输入id11。坑点在 URL (GET请求) 中号会被浏览器解码为空格。因此传入后端的变成了id1 1导致测试失败 。修正必须对加号进行 URL 编码输入id1%2b1。若页面返回id2的内容则存在注入 。逻辑运算id1 and 11/id1 and 12。缺点AND是 WAF 的重点拦截对象容易触发拦截不如算术运算隐蔽。字符型四法快速判定核心技巧原理利用 SQL 语法的引号配对规则。此方法不使用AND、OR等敏感词误报率极低且能绕过绝大多数 WAF。假设后端 SQL 为SELECT * FROM table WHERE id 输入值输入(1个单引号)→\rightarrow→报错后端变成id 1解析3个单引号不成对导致 SQL 语法错误 。输入(2个单引号)→\rightarrow→正常后端变成id 1解析第一个引号是闭合第二个和第三个引号组成了空字符串或转义第四个是后端的闭合。语法合法逻辑通过 。输入(3个单引号)→\rightarrow→报错后端变成id 1解析5个单引号不成对语法错误 。输入(4个单引号)→\rightarrow→正常后端变成id 1解析两对空字符串语法合法 。判定结论只要符合“报错 - 正常 - 报错 - 正常”的规律90% 以上概率存在字符型注入。闭合与注释的细节--(MySQL注释符)SQL 标准注释是--(后面必须有一个空格)。在 URL 中空格若未编码容易丢失所以习惯用代替空格URL解码后为空格即--。#(Hash注释符)坑点在 URL 中#代表锚点Fragment不会发送给服务器。修正必须编码为%23才能被后端接收为注释符 。利用闭合绕过注释如果注释符被过滤可以使用或 and 11来手动闭合后端的单引号 。3. Order By 排序注入手动判定为什么 Order By 无法预编译预编译机制预编译将参数视为“值”而非“代码”。冲突点如果在ORDER BY ?中传入id数据库会将其解析为按照字符串 “id” 排序即所有行都一样而不是按照列名id排序。结果为了功能正常开发人员必须使用拼接从而导致注入 。四法快速判定 (利用多列排序特性)原理ORDER BY支持多列排序order by col1, col2。我们可以注入一个新的排序字段。Payload 构造流程假设注入点在order by后1 desc, 1→\rightarrow→正常回显含义先按第1列倒序如果有相同值再按第1列正序。逻辑合法 。1 desc, 0→\rightarrow→报错含义尝试按第0列排序。SQL中列号从1开始第0列不存在必报错 。1 desc, 2→\rightarrow→正常回显含义假设表中至少有2列逻辑合法 。1 desc, 9999→\rightarrow→报错含义尝试按第9999列排序超出列数范围必报错 。避雷与高级玩法不参与排序陷阱如果在ORDER BY后注入if(11,1,2)或sleep(5)这些函数会执行。但是函数的返回值通常被视为常量不会改变数据的排序顺序。误区不要试图观察“排序是否变化”来判断布尔盲注而应该直接观察是否报错或是否延时 。利用可以直接配合报错注入语句如updatexml在排序处直接获取数据 。4. JSON / Int类型 SQL注入实战原始类型与格式破坏场景API 接收 JSON 数据如{id: 1}。常见错误测试时直接输入{id: 1}。后果JSON 规范要求键值对格式严格。1不是合法的 JSON 数字或字符串导致 Web 服务器层如 Tomcat/Nginx/PHP解析器直接抛出JSON Format Error请求根本没传到数据库导致漏测 。正确姿势主动添加双引号策略主动将 Int 类型转换为 String 类型测试。Payload将{id: 1}修改为{id: 1}。先闭合 JSON 的双引号使其成为合法的 JSON 字符串。如果后端代码没有强制校验类型如(int)$id它会将字符串拼接到 SQL 中此时单引号生效触发注入 。转义细节如果在 Payload 中需要用到双引号必须使用\进行转义否则会破坏 JSON 结构 。XiaSql 插件辅助 (WAF不拦截原理)工作原理被动扫描插件监听 Burp 流量。判定逻辑发包 A插入→\rightarrow→记录响应包长度通常变短或报错。发包 B插入→\rightarrow→记录响应包长度通常恢复正常。对比若 A 与 B 的响应长度存在显著差异则判定疑似注入 。优势只发送单引号不发送SELECT、UNION等敏感词WAF 几乎不拦截。5. SQLmap 的高级使用模式基础与进阶指令GET型sqlmap -u url?id1。POST型 / 需鉴权型步骤在 Burp 中抓取完整数据包→\rightarrow→右键 “Copy to file” 保存为1.txt。指令sqlmap -r 1.txt。优势完美解决 Cookie、Header Token 等鉴权问题且能测试 JSON 或 Multipart 表单中的参数 。精准打击指令sqlmap -r 1.txt -p id。意义只测试id参数。避免全量扫描浪费时间适用于已知注入点的快速利用 。Shell 获取与提权 (高阶)--sql-shell提供交互式 SQL 环境。注意除非是堆叠注入Stacked Injection否则只能执行SELECT查询不能执行INSERT/UPDATE。--os-shell(获取系统Shell)MySQL 苛刻条件DB用户为 Root 权限拥有FILE权限。知道网站绝对路径物理路径。secure_file_priv为空允许向任意路径写文件默认是关闭的。原理上传两个文件一个小马用于文件上传一个用于执行 CMD 命令 。--os-pwn/ UDF 提权结合 Metasploit 进行 UDF 提权。注意集成环境如 phpStudy的 MySQL 往往被阉割可能导致提权失败 。严禁操作红线脱库--dump或--dump-all。除非红队明确授权否则在 SRC 挖掘中属于违法行为 。破坏性测试在增加、删除、修改Update/Insert/Delete的功能点绝对禁止使用 SQLMap 自动扫描否则可能导致生产环境数据全毁 。6. Xray - 无WAF环境下的最强扫描配置与联动 (指哪打哪)Xray 的 SQL 注入检测能力被认为是公开工具中最强的建议使用“被动扫描”模式。安装与证书运行xray genca生成 CA 证书。必须同时导入到操作系统受信任根证书和浏览器/Burp中 。开启监听xray webscan --listen 127.0.0.1:7777 --html-output report.html。Burp 联动配置 (核心步骤)在 Burp 中User Options-Upstream Proxy Servers。添加规则Destination:*Proxy:127.0.0.1:7777。效果浏览器操作→\rightarrow→Burp (可手动修改包)→\rightarrow→Xray (自动扫描)→\rightarrow→服务器。指定插件为了防止扫描动作过大导致封禁或业务崩溃建议只开启 SQL 插件--plugins sqldet。重要避坑测试结束后务必关闭 Burp 的 Upstream Proxy否则下次打开 Burp 会因为连不上 Xray 而导致所有请求失败断网。