历史记录

    清空历史记录
    • 相关的动态
    • 相关的文章
    • 相关的用户
    • 相关的圈子
    • 相关的话题
    注册 登录
    Mysql注入中锁机制的应用
    1420999080046119 发表于 福建 漏洞分析 2055浏览 · 2025-06-26 17:39

    前言
    在sql注入的延时注入中，常见的函数有sleep()直接延时、BENCHMARK()通过让数据库进行大量的计算而达到延时的效果、笛卡尔积、正则匹配等，但还有一个常常被忽略的函数，也就是Mysql中的锁机制。虽然早些年就已经出现过相关的技术文章，但是他的应用却几乎见不到，也没有看到有文章对他的机制和运用进行深入讲解，而且该函数也常常被waf忽略导致延时。
    Mysql锁机制介绍

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


    RELEASE_LOCK(str)
    用于解开锁，str表示要解开的锁名
    返回值：
    1：成功释放，当前会话持有锁并成功释放
    0：释放失败，当前会话不持有该锁
    NULL：错误或锁不存在， 锁名称从未被获取
    示例：
    通过返回值1判断成功获取名为1的锁
    image.png
    图片加载失败
    通过返回值1判断成功释放名为1的锁
    image.png
    图片加载失败
    再次释放时，则为Null（锁不存在）
    image.png
    图片加载失败
    核心特性
    命名锁机制：
    基于字符串名称的锁，不同锁名互不影响，例如：
    GET_LOCK('test1', 10)
    GET_LOCK('test2', 10)
    他们直接由于锁名不同，所以互不影响


    会话级作用域：
    当一个会话成功获取了某个命名锁后，其他会话在尝试获取相同名称的锁时将会被阻塞，直到锁被释放或超时。
    而在同一个会话内部，即使多次请求相同的锁，也不会造成阻塞，会直接返回成功，因为该会话已经持有该锁。
    1750956682256.jpg
    图片加载失败
    示例：
    会话1先通过GET_LOCK()函数获取了名为1的锁，返回结果为1表示获取成功
    image.png
    图片加载失败
    会话2再次通过GET_LOCK()函数获取名为1的锁，但是名为1的锁以及被会话1占有，所以会话2直到超时5秒，结果为0表示获取失败
    image.png
    图片加载失败
    锁释放规则：
    显式释放：RELEASE_LOCK('lock_name')
    隐式释放：会话终止（连接关闭）
    时效释放：受wait_timeout 参数控制
    不会随事务结束自动释放（与InnoDB行锁不同）


    SHOW VARIABLES LIKE 'wait_timeout';
    可以查看会话超时时间（秒），这里是2分钟
    image.png
    图片加载失败
    SET SESSION wait_timeout = 600;
    可以通过该函数来设置wait_timeout参数
    image.png
    图片加载失败
    通过网上搜索发现wait_timeout参数的默认值是8小时，但是我的数据库默认就是2分钟，也没有看到官方的具体说明，可能是受到Mysql版本的影响。
    Web各类布局中的利用

    利用条件
    刚刚讲完了Mysql锁的机制，那么要使用GET_LOCK()函数成功让目标数据库发现延迟，就需要具备以下两个条件：
    1需要不同会话（只有不同会话的锁竞争才会导致延时）
    2获取锁的会话具备长时效应（既会话或锁不被马上释放）
    image.png
    图片加载失败
    短会话模式
    模式简介：
    每个HTTP请求都新建数据库连接，请求完成后立即关闭连接。无连接复用。
    使用规模：
    极少，主要存在于遗留系统或极低流量场景
    image.png
    图片加载失败
    利用可行性：
    这种情况下，大概率是无法造成锁等待，虽然每次用户的请求满足条件1：需要不同会话。但是无法满足条件2：获取锁的会话具备长时效应。也就是说当A会话获取完锁a，B会话还没来得及等待锁a，A会话就已经结束了，就自动释放锁，就无法达到锁等待的效果。
    举一个最简单的例子，phpstudy中搭建的靶场sqli-labs就是如此（短会话模式）
    这里拦截后大量发包，在一次性并发。
    image.png
    图片加载失败
    通过数据库监听工具可以看到，当数据库还没来得及因为其他会话的锁造成等待，其他会话的锁就已经结束并关闭连接，自动释放锁了。所以不满足条件2：获取锁的会话具备长时效应。
    image.png
    图片加载失败
    长会话模式
    模式简介：
    整个Web应用使用单个持久数据库连接，所有用户请求共享此连接。
    使用规模：
    较少，特定场景：金融交易系统、小型嵌入式应用，一些较老的cms也存在此情况
    image.png
    图片加载失败
    利用可行性：
    所有用户操作在同一个会话中，但条件1需要不同会话才会产生锁等待，所以不会发生锁等待，也就不能造成延时的效果


    这里以MRCMS-3.1.2版本为例，他就是长会话模式
    image.png
    图片加载失败
    通过数据库监听工具可以看到，无论进行多少次数据库操作他的thread_id一直都为994，尽管切换登录，替换用户凭证，ip等都还是thread_id为994且没有断开连接，那么就不满足条件1：需要不同会话（只有不同会话的锁竞争才会导致延时），也就不会导致锁等待，就不会造成延时的效果。
    image.png
    图片加载失败
    连接池模式
    模式简介：
    预先创建连接池（如20个连接）
    每个HTTP请求从池中借用连接，用完归还
    物理连接复用，逻辑会话隔离，既每个会话重复的从连接池中使用连接
    使用规模：
    主流，现代Web应用常出现，Spring Boot(HikariCP), Django, Laravel等默认使用
    image.png
    图片加载失败
    利用可行性：
    锁绑定物理连接，不自动释放
    用户A获取锁 → 未释放 → 连接1归还但不自动释放 → 用户B使用连接2 → 锁冲突
    image.png
    图片加载失败
    利用方法：
    那么只要我们通过大量的请求，就一定会从Pool中请求到两个不同的物理连接，这样利用GET_LOCK函数就能达到延时的效果
    用户级长连接（绑定会话）
    模式简介：
    每个用户分配专属数据库连接，在整个会话期间保持打开（既长连接）。
    使用规模：
    较少，实时系统：在线协作工具、交易平台
    1750957077801.jpg
    图片加载失败
    利用可行性：
    用户A在会话1持有锁
    用户B在会话2请求同名锁 → 满足条件1（不同会话）+条件2（锁未释放）
    利用方法：
    只要不同用户的凭证去请求同一个锁，比如GET_LOCK(1,5)那么就会发生锁等待，造成延时效果
    IP/客户端级连接

    模式简介：
    与上一个用户级长连接极其相似，只不过按客户端IP分配固定连接，同IP的多个用户共享连接。
    使用规模：
    极少，特殊场景：游戏服务器、定制网关
    1750957093438.jpg
    图片加载失败
    利用可行性：
    IP组内：同会话无冲突（如IP1用户A和用户B无锁等待）
    IP组间：不同会话有冲突（如IP1用户 vs IP2用户）
    利用方法：
    和用户级长连接（绑定会话）类似，只是需要ip不同
    多Web共用数据库

    模式简介：
    现在常见的web部署方式为站库分离，且多站共用一个库，多个独立应用（如微服务）共享同一数据库，各自使用连接池。
    使用规模：
    常见，微服务架构，现代云原生应用常见模式
    1750957112410.jpg
    图片加载失败
    利用可行性：
    多web共享同一连接池：那么原理与连接池模式相同
    多web使用独立连接池：不同连接池=不同会话，原理与连接池模式相同
    多web不使用连接池+全是短会话：无法产生，与短连接原理相同
    多web不使用连接池+全是长会话：无法产生，与长连接原理相同
    多web不使用连接池+长会话+短会话：不同web的连接也就会产生不同的会话，满足条件1：需要不同会话；长会话满足条件2：获取锁的会话具备长时效应。
    利用方法：
    多web不使用连接池+长会话+短会话：先对长会话的web进行注入来获取锁，再通过短会话web注入来达到锁等待，造成延时效果。
    雷池waf延时实战

    雷池waf配置

    这里均采用默认配置
    image.png
    图片加载失败
    常规延时手段
    Sleep延时被拦截
    1750957404453.jpg
    图片加载失败
    BENCHMARK函数被拦截
    1750957437509.jpg
    图片加载失败
    可以看到常规的延时手法都直接拦截了，那么接下来使用我们刚刚讲解的锁机制来延时


    锁函数造成延时
    这里采用两个web共用一个数据库的形式，一个是phpstudy中搭建的靶场sqli-labs短会话模式，另一个是MRCMS-3.1.2长会话模式，那么两者构成的就是多Web共用数据库模式。


    多web不使用连接池+长会话+短会话：
    先对长会话的web进行注入来获取锁，再通过短会话web注入来达到锁等待，造成延时效果。
    先使用MRCMS-3.1.2的漏洞接口注入来获取锁：
    image.png
    图片加载失败
    然后在sqli-labs中直接注入
    ?id=1%27||%20GET_LOCK(1,5)%20||%27
    成功造成延时效果，且不触发雷池waf拦截
    image.png
    图片加载失败
    接着嵌套if语句，依旧成功造成延时，且不触发雷池waf拦截
    ?id=1%27||%20if(1,GET_LOCK(1,5),1)%20||%27
    image.png
    图片加载失败
    通过数据库监听工具看到时间部分确实造成了延时，以及长会话和短会话共用数据库连接导致的不同会话造成了锁等待，最终产生延时效果
    image.png
    图片加载失败
    到雷池waf后台可以看到锁函数实际上是检测到了，但在默认配置下不拦截，只拦截了底部的两条比较常见的延时函数。
    image.png
    图片加载失败
    总结
    利用锁机制的优势就是不易被waf检测（在写文章的时候似乎写入其他延时payload会导致出错无法预览，而锁机制的延时payload则可以正常预览，这也算是不易被检测的一种），既然大名鼎鼎的雷池waf都能成功延时，那么市面上大多数的waf应该也一样。
    那么接下来的注入方法就由各位师父大显神通了，这里就不再做太多的赘述。
    ​
    4 人收藏 3 人喜欢 转载 分享
    1 条评论
    某人
    表情
    可输入 255 字
    用户pRG6L1WelH
    2025-06-29 10:13 0 回复
    能找网页漏洞不？
      发布投稿
    热门文章
    优秀作者
    目录
    先知社区
    本站/app由 Djingoii 提供技术和产品支持