MySQL锁机制注入绕过WAF技术详解

一、MySQL锁机制基础

1.1 核心函数介绍

GET_LOCK()函数

• 功能：MySQL提供的用户级锁函数，用于应用层实现跨会话锁机制
• 语法：GET_LOCK(str lock_name, int timeout)
• 参数：
  • lock_name：锁名称（最大64字符，区分大小写）
  • timeout：等待超时时间（秒）
    • 0：立即返回
    • 负数：无限等待（MySQL 5.7.5+）
• 返回值：
  • 1：成功获取锁
  • 0：获取锁超时（其他会话持有锁且未在指定时间内释放）
  • NULL：发生错误（如参数无效、内存不足等）

RELEASE_LOCK()函数

• 功能：释放锁
• 语法：RELEASE_LOCK(str)
• 参数：str表示要解开的锁名
• 返回值：
  • 1：成功释放，当前会话持有锁并成功释放
  • 0：释放失败，当前会话不持有该锁
  • NULL：错误或锁不存在（锁名称从未被获取）

1.2 锁机制核心特性

1. 命名锁机制：

   • 基于字符串名称的锁，不同锁名互不影响
   • 示例：GET_LOCK('test1', 10)和GET_LOCK('test2', 10)互不影响

2. 会话级作用域：

   • 一个会话成功获取命名锁后，其他会话尝试获取相同名称的锁会被阻塞
   • 同一会话内多次请求相同锁不会阻塞，直接返回成功

3. 锁释放规则：

   • 显式释放：RELEASE_LOCK('lock_name')
   • 隐式释放：
     • 会话终止（连接关闭）
     • 受wait_timeout参数控制（不会随事务结束自动释放）
   • 查看超时时间：SHOW VARIABLES LIKE 'wait_timeout';
   • 设置超时时间：SET SESSION wait_timeout = 600;

二、Web应用数据库连接模式分析

2.1 短会话模式

• 特点：每个HTTP请求新建数据库连接，请求完成后立即关闭
• 使用场景：遗留系统或极低流量场景
• 利用可行性：
  • 满足条件1：不同会话
  • 不满足条件2：获取锁的会话不具备长时效应（锁会立即释放）
  • 无法有效利用：如sqli-labs靶场

2.2 长会话模式

• 特点：整个Web应用使用单个持久数据库连接，所有用户请求共享
• 使用场景：金融交易系统、小型嵌入式应用、部分老CMS
• 利用可行性：
  • 不满足条件1：所有操作在同一会话中
  • 无法有效利用：如MRCMS-3.1.2

2.3 连接池模式

• 特点：
  • 预先创建连接池（如20个连接）
  • 每个HTTP请求从池中借用连接，用完归还
  • 物理连接复用，逻辑会话隔离
• 使用场景：主流现代Web应用（Spring Boot、Django、Laravel等）
• 利用可行性：
  • 锁绑定物理连接，不自动释放
  • 用户A获取锁→未释放→连接1归还但不自动释放→用户B使用连接2→锁冲突
  • 有效利用方法：大量请求获取不同物理连接

2.4 用户级长连接（绑定会话）

• 特点：每个用户分配专属数据库连接，在整个会话期间保持打开
• 使用场景：在线协作工具、交易平台等实时系统
• 利用可行性：
  • 用户A在会话1持有锁
  • 用户B在会话2请求同名锁
  • 满足条件1（不同会话）+条件2（锁未释放）
  • 有效利用方法：不同用户凭证请求同一锁

2.5 IP/客户端级连接

• 特点：按客户端IP分配固定连接，同IP的多个用户共享连接
• 使用场景：游戏服务器、定制网关等特殊场景
• 利用可行性：
  • IP组内：同会话无冲突
  • IP组间：不同会话有冲突
  • 利用方法：类似用户级长连接，但需要不同IP

2.6 多Web共用数据库模式

• 特点：站库分离，多站共用一个库，多个独立应用共享同一数据库

• 使用场景：微服务架构、现代云原生应用

• 利用可行性分析：

  配置情况	利用可行性
  多web共享同一连接池	同连接池模式
  多web使用独立连接池	同连接池模式
  多web不使用连接池+全是短会话	不可行
  多web不使用连接池+全是长会话	不可行
  多web不使用连接池+长会话+短会话	可行

• 有效利用方法：

  • 先对长会话的web进行注入获取锁
  • 再通过短会话web注入达到锁等待，造成延时效果

三、绕过WAF实战技巧

3.1 常规延时方法被拦截情况

• sleep()函数：被拦截
• BENCHMARK()函数：被拦截

3.2 锁机制延时方法

1. 环境配置：

   • Web1：sqli-labs（短会话模式）
   • Web2：MRCMS-3.1.2（长会话模式）
   • 两者共用同一数据库

2. 攻击步骤：

   • 第一步：通过MRCMS漏洞接口注入获取锁

     GET_LOCK('lockname', timeout)
     

   • 第二步：在sqli-labs中注入造成延时

     ?id=1'|| GET_LOCK(1,5) ||'
     或
     ?id=1'|| if(1,GET_LOCK(1,5),1) ||'
     

3. 优势：

   • 不易被WAF检测（雷池WAF默认配置不拦截）
   • 可嵌套在条件语句中使用

3.3 检测与防御建议

对于防御方：

1. 监控异常锁请求
2. 限制GET_LOCK函数权限
3. 配置WAF规则检测锁函数使用模式

对于攻击方：

1. 优先识别目标数据库连接模式
2. 针对不同模式选择合适的利用方法
3. 结合条件语句增强隐蔽性

四、技术总结

1. 锁机制注入核心条件：

   • 条件1：需要不同会话（只有不同会话的锁竞争才会导致延时）
   • 条件2：获取锁的会话具备长时效应（会话或锁不被马上释放）

2. 最佳利用场景：

   • 连接池模式
   • 用户级长连接模式
   • 多Web共用数据库模式（尤其是不使用连接池+长会话+短会话组合）

3. 绕过WAF优势：

   • 非常规延时方法，WAF规则库可能未覆盖
   • 可与其他SQL注入技术结合使用
   • 在默认配置下不易被检测

4. 扩展应用：

   • 可用于盲注中的时间延迟判断
   • 可结合条件语句实现基于时间的布尔盲注
   • 在特定环境下可替代被拦截的sleep和benchmark函数