SQL注入检测高级技巧：绕过WAF与无报错场景下的检测方法

1. SQL注入检测的常见挑战

在测试SQL注入漏洞时，安全研究人员常面临两大难题：

1. WAF拦截问题：

   • and 1=1 被拦截
   • order by 被拦截
   • sleep(5) 被拦截
   • benchmark(50000000,MD5(1)) 被拦截

2. 无明确报错信息：

   • 插入单引号(')后返回码仍是200
   • 无SQL语法错误提示
   • 无500响应码
   • 可能仅返回空响应或页面微小变化

2. 新型检测方法论

2.1 核心思路

不依赖插入payload导致的页面差异来判断，而是依赖插入payload后页面是否保持不变来判断潜在注入点。

优势：

• 不易被WAF检测
• 高效判断潜在注入可能性

2.2 检测流程

1. 确定输入是否影响页面：

   • 先输入一个明显无效值(如"fake")，观察页面变化
   • 确认存在可控的输入影响点

2. 构造测试payload：

   • 使用数据库字符串连接的特殊符号构造变形payload
   • 常见变形方式(以TrackingId="c7oeRGoH7RkYYQzC"为例)：
     • c7'||'oeRGoH7RkYYQzC (Oracle/PostgreSQL)
     • c7' 'oeRGoH7RkYYQzC (SQL Server)
     • c7'+'oeRGoH7RkYYQzC (MySQL)
     • c7'%2b'oeRGoH7RkYYQzC (URL编码版)

3. 验证特殊符号是否被过滤：

   • 测试变形如c'7oeRGoH7RkYYQzC或c|7oeRGoH7RkYYQzC
   • 若页面变化，说明特殊符号未被完全过滤

4. 数据库类型识别：

   • 对于||连接符有效的疑似Oracle/PostgreSQL环境：
     • Oracle测试：c7'||'oeRGoH7RkYYQz'||to_char('C')||'
     • PostgreSQL测试：c7'||'oeRGoH7RkYYQz'||cast('C'+as+text)||'

3. 实战案例分析

以PortSwigger靶场为例(https://portswigger.net/web-security/sql-injection/blind/lab-conditional-responses)：

1. 确认基础输入影响：

   • 有效TrackingId显示"Welcome back!"
   • 无效值不显示该信息

2. 测试字符串连接：

   • c7'||'oeRGoH7RkYYQzC返回相同页面 → 疑似Oracle/PostgreSQL

3. 验证特殊符号处理：

   • 测试c'7oeRGoH7RkYYQzC → 页面变化确认符号未被过滤

4. 精确数据库识别：

   • 测试Oracle特有函数to_char()或PostgreSQL的cast()语法

4. 方法局限性

1. 误报可能性：

   • 特殊符号被简单去除可能导致假阳性
   • 错误处理返回默认值可能误导判断

2. 无法检测的情况：

   • 某些特定过滤逻辑可能完全规避此方法
   • 极其严格的输入验证场景

5. 高级技巧与注意事项

1. 数字型注入检测：

   • 原理相同但构造方式不同
   • 例如测试算术运算：1+1、2-1等

2. 团队协作价值：

   • 初级研究人员可识别可疑点
   • 高级专家负责深入利用
   • 实现高效分工合作

3. 持续学习建议：

   • 研究不同数据库的字符串连接语法
   • 掌握各数据库特有的函数和语法特性
   • 关注WAF绕过技术的最新发展

6. 总结

这种SQL注入检测方法通过观察页面一致性而非差异性，有效规避了WAF拦截和无报错信息的难题。虽然存在一定误报率，但为安全研究人员提供了一种高效识别潜在注入点的新思路。实际应用中应结合多种技术手段，并充分考虑目标环境的具体特性。