SQL注入绕WAF-Skill

原创

凌曦安全
凌曦安全

凌曦安全

2026年8月31日 10:00
上海

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

本推文提供的信息、技术和方法仅用于教育目的。文中讨论的所有案例和技术均旨在帮助读者更好地理解相关安全问题，并采取适当的防护措施来保护自身系统免受攻击。

严禁将本文中的任何信息用于非法目的或对任何未经许可的系统进行测试。未经授权尝试访问计算机系统或数据是违法行为，可能会导致法律后果。

作者不对因阅读本文后采取的任何行动所造成的任何形式的损害负责，包括但不限于直接、间接、特殊、附带或后果性的损害。用户应自行承担使用这些信息的风险。我们鼓励所有读者遵守法律法规，负责任地使用技术知识，共同维护网络空间的安全与和谐。

SQL注入绕WAF-Skill

目前skill已在凌曦安全GitHub公开（文末获取）

• 课程完整介绍链接：https://www.yuque.com/syst1m-/blog/lc3k6elv0zqhdal3
• 课程试听直达（公开课）：https://space.bilibili.com/66074656?spm\_id\_from=333.1007.0.0

一、skills介绍

某次SRC GET类型阿里云绕过报告。

某池WAF绕过输出的报告

1.1 为什么要做这个skills

让 AI 做 SQL 注入测试，真正困难的从来不是生成几个 Payload，而是控制范围、减少噪声、区分假象，并把结论整理成可以复现和审查的证据。

很多人第一次让 AI 测 SQL 注入，提示词可能只有一句：

帮我看看这个参数有没有 SQL 注入。

听上去很简单，实际却有不少坑：一次 500 能不能说明存在注入？响应变慢究竟是数据库延迟，还是网络抖动？工具说后端是 MySQL，证据真的够吗？遇到 WAF 后返回 200，又是否代表请求已经到达数据库？

为了解决这些问题，我们实现了一个 sqli Skill。它不是一份固定 Payload 字典，也不是给某个扫描器套了一层自然语言外壳，而是一套强调范围、证据、低噪声和可复现报告的 SQL 注入验证流程。

又或者面临一个场景，发现了疑似注入自己不会判断，或者说判断出来了但是有WAF或者后端的限制面对的注入无从下手但是上交标准又是需要注入出用户名 或者数据库名,又怕ai测试的时候乱来，这个skills也能覆盖这种情况。

1.2 一条完整的验证链路

Skill 默认把任务分成五个环节。

1.2.1 判断是否真的存在注入

这一阶段只回答一个问题：目标输入能否稳定、可控地改变后端 SQL 语义？

单次报错、单次超时、一个特殊字符造成的页面变化，都不能直接作为确认依据。Skill 会关注基线、对照样本、重复性和因果关系，尽量排除业务逻辑、缓存、输入校验、临时故障和安全设备拦截造成的假象。

最终结论不会粗暴地写成“有”或“没有”，而是采用更审慎的表达：

• 已确认；
• 高度疑似；
• 当前证据未确认。

1.2.2 判断后端数据库类型

确认存在注入后，下一步是识别数据库产品，或者至少缩小到证据能够支持的产品族。

Skill 不会因为响应头、Web 框架、默认端口或扫描器标签就直接宣布“这是 MySQL”或“这是 SQL Server”。这些只能算旁证，真正的结论需要来自数据库运行时行为，而且要同时记录：

• 支持当前判断的证据；
• 与判断相反的证据；
• 尚未排除的候选；
• 当前结论的置信度。

如果两个兼容产品暂时无法区分，它会诚实地报告产品族或兼容方言，而不是猜一个看起来更具体的答案。

1.2.3 判断能够成立的注入类型

“数值型”“字符型”和“布尔盲注”“联合查询型”不是同一个维度。

前者描述 SQL 上下文和闭合方式，后者才是注入技术类型。实际交流中，这两类概念经常被混为一谈。

sqli Skill 会分别判断联合查询、布尔、报错、时间、堆叠、内联或带外等通道。同一个参数可能同时支持多种技术，也可能只能确认其中一种。每一种被确认的类型，都需要有该技术特有、可重复的运行时证据。

1.2.4 只按用户目标提取数据

默认流程不会在确认漏洞后顺手遍历所有库、表和字段。

只有用户明确提出目标，Skill 才会继续提取，例如当前用户、当前数据库、指定表、指定字段或指定记录；而且采用最窄解释，不擅自扩大范围。

例如用户只要求确认当前数据库名，流程就不应该自动扩展到所有表名，更不会执行破坏性 SQL、文件读写、系统命令、持久化或跨目标操作。

这种“按需取数”看起来克制，却是SRC或其他场景中非常关键的设计。

1.2.5 WAF 识别与语义复验

看到拦截页消失，不代表 WAF 已经被有效绕过；状态码从 403 变成 200，也不代表注入语义仍然成立。

一个有效的 WAF 绕过必须同时证明两件事：

1. 请求确实跨过了原有的拦截或规范化边界；
2. 变换后的输入仍然到达预期后端路径，并保留原本要验证的 SQL 语义。

如果只能证明“页面不拦了”，却不能证明数据库行为，Skill 不会把它写成绕过成功。

1.2.6  知识库可以扩展，但不会接管判断

sqli Skill 预留了五类用户知识库目录：

可以把自己的比赛笔记、特殊语法、过滤规则、抓包说明和复盘资料放进去。任务需要时，skills会读取对应阶段的相关内容。

但知识库不是不可质疑的答案，更不是固定字典。里面的方法仍需经过当前目标的运行时证据验证；资料没有命中时，流程也会继续根据响应形成新假设，而不是停在“字典跑完了”。

1.2.7 怎么使用

第一种情况不确定是否有注入

对以下数据包进行注入，获取当前用户名。GET /challenge/item?id=12 HTTP/1.1Host: 127.0.0.1:8080Cookie: session=REDACTED

第二种情况已知有注入

id 参数已经确认存在 SQL 注入，后端是 PostgreSQL，获取当前数据库名称GET /challenge/item?id=12 HTTP/1.1Host: 127.0.0.1:8080Cookie: session=REDACTED

输入越完整，复现越可靠。除了 URL，最好同时提供 HTTP 方法、参数位置、Body 编码、必要 Header、Cookie、认证状态。

二、写在最后

我越来越觉得，AI 安全工具真正的价值，不是更快地吐出 Payload，而是帮助测试者维持一条严谨的证据链。

一个成熟的 SQL 注入验证流程，至少应该回答这些问题：

• 我测试的范围是什么？
• 哪个输入真正影响了 SQL 语义？
• 结论能否稳定复现？
• DBMS 和注入类型是如何判断的？
• WAF 绕过后，后端语义是否仍然成立？
• 是否只获取了任务真正需要的数据？
• 其他人能否根据报告复核我的结论？

sqli Skill 做的，就是把这些问题变成工作时必须遵守的流程。

它不会替代安全工程师的授权判断，也不会替代人对业务影响的理解。但在合法、隔离、可控的环境里，它可以让 SQL 注入测试从“试几个字符串看看”升级为一次更克制、更系统、也更能经得起复盘的验证。

-1 and binary @ union select 1,group_concat(table_name),3 from information_schema.tables where table_schema=0x73716c69#

三、获取skill

关注公众号，后台私信“凌曦安全sql-skill202608”，即可获取

外部交流群加入方式