【网络安全】Mysql注入中锁机制

前言

在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的锁

通过返回值1判断成功释放名为1的锁

再次释放时,则为Null(锁不存在)

核心特性

命名锁机制:

基于字符串名称的锁,不同锁名互不影响,例如:

GET_LOCK('test1', 10)

GET_LOCK('test2', 10)

他们直接由于锁名不同,所以互不影响

会话级作用域:

当一个会话成功获取了某个命名锁后,其他会话在尝试获取相同名称的锁时将会被阻塞,直到锁被释放或超时。

而在同一个会话内部,即使多次请求相同的锁,也不会造成阻塞,会直接返回成功,因为该会话已经持有该锁。

示例:

会话1先通过GET_LOCK()函数获取了名为1的锁,返回结果为1表示获取成功

会话2再次通过GET_LOCK()函数获取名为1的锁,但是名为1的锁以及被会话1占有,所以会话2直到超时5秒,结果为0表示获取失败

锁释放规则:

显式释放:RELEASE_LOCK('lock_name')

隐式释放:会话终止(连接关闭)

时效释放:受wait_timeout 参数控制

不会随事务结束自动释放(与InnoDB行锁不同)

SHOW VARIABLES LIKE 'wait_timeout';

可以查看会话超时时间(秒),这里是2分钟

SET SESSION wait_timeout = 600;

可以通过该函数来设置wait_timeout参数

通过网上搜索发现wait_timeout参数的默认值是8小时,但是我的数据库默认就是2分钟,也没有看到官方的具体说明,可能是受到Mysql版本的影响。

Web 各类布局中的利用

利用条件

刚刚讲完了Mysql锁的机制,那么要使用GET_LOCK()函数成功让目标数据库发现延迟,就需要具备以下两个条件:

  1. 需要不同会话(只有不同会话的锁竞争才会导致延时)
  2. 获取锁的会话具备长时效应(既会话或锁不被马上释放)

短会话模式

模式简介:

每个HTTP请求都新建数据库连接,请求完成后立即关闭连接。无连接复用。

使用规模:

极少,主要存在于遗留系统或极低流量场景

利用可行性:

这种情况下,大概率是无法造成锁等待,虽然每次用户的请求满足条件1:需要不同会话。但是无法满足条件2:获取锁的会话具备长时效应。也就是说当A会话获取完锁a,B会话还没来得及等待锁a,A会话就已经结束了,就自动释放锁,就无法达到锁等待的效果。

举一个最简单的例子,phpstudy中搭建的靶场sqli-labs就是如此(短会话模式)

这里拦截后大量发包,在一次性并发。

通过数据库监听工具可以看到,当数据库还没来得及因为其他会话的锁造成等待,其他会话的锁就已经结束并关闭连接,自动释放锁了。所以不满足条件2:获取锁的会话具备长时效应。

长会话模式

模式简介:

整个Web应用使用单个持久数据库连接,所有用户请求共享此连接。

使用规模:

较少,特定场景:金融交易系统、小型嵌入式应用,一些较老的cms也存在此情况

利用可行性:

所有用户操作在同一个会话中,但条件1需要不同会话才会产生锁等待,所以不会发生锁等待,也就不能造成延时的效果

这里以MRCMS-3.1.2版本为例,他就是长会话模式

通过数据库监听工具可以看到,无论进行多少次数据库操作他的thread_id一直都为994,尽管切换登录,替换用户凭证,ip等都还是thread_id为994且没有断开连接,那么就不满足条件1:需要不同会话(只有不同会话的锁竞争才会导致延时),也就不会导致锁等待,就不会造成延时的效果。

连接池模式

模式简介:

预先创建连接池(如20个连接)

每个HTTP请求从池中借用连接,用完归还

物理连接复用,逻辑会话隔离,既每个会话重复的从连接池中使用连接

使用规模:

主流,现代Web应用常出现,Spring Boot(HikariCP), Django, Laravel等默认使用

利用可行性:

锁绑定物理连接,不自动释放

用户A获取锁 → 未释放 → 连接1归还但不自动释放 → 用户B使用连接2 → 锁冲突

利用方法:

那么只要我们通过大量的请求,就一定会从Pool中请求到两个不同的物理连接,这样利用GET_LOCK函数就能达到延时的效果

用户级长连接(绑定会话)

模式简介:

每个用户分配专属数据库连接,在整个会话期间保持打开(既长连接)。

使用规模:

较少,实时系统:在线协作工具、交易平台

利用可行性:

用户A在会话1持有锁

用户B在会话2请求同名锁 → 满足条件1(不同会话)+条件2(锁未释放)

利用方法:

只要不同用户的凭证去请求同一个锁,比如GET_LOCK(1,5)那么就会发生锁等待,造成延时效果

IP/ 客户端级连接

模式简介:

与上一个用户级长连接极其相似,只不过按客户端IP分配固定连接,同IP的多个用户共享连接。

使用规模:

极少,特殊场景:游戏服务器、定制网关

利用可行性:

IP组内:同会话无冲突(如IP1用户A和用户B无锁等待)

IP组间:不同会话有冲突(如IP1用户 vs IP2用户)

利用方法:

和用户级长连接(绑定会话)类似,只是需要ip不同

Web 共用数据库

模式简介:

现在常见的web部署方式为站库分离,且多站共用一个库,多个独立应用(如微服务)共享同一数据库,各自使用连接池。

使用规模:

常见,微服务架构,现代云原生应用常见模式

利用可行性:

多web共享同一连接池:那么原理与连接池模式相同

多web使用独立连接池:不同连接池=不同会话,原理与连接池模式相同

多web不使用连接池+全是短会话:无法产生,与短连接原理相同

多web不使用连接池+全是长会话:无法产生,与长连接原理相同

多web不使用连接池+长会话+短会话:不同web的连接也就会产生不同的会话,满足条件1:需要不同会话;长会话满足条件2:获取锁的会话具备长时效应。

利用方法:

多web不使用连接池+长会话+短会话:先对长会话的web进行注入来获取锁,再通过短会话web注入来达到锁等待,造成延时效果。

雷池 waf 延时实战

雷池 waf 配置

这里均采用默认配置

常规延时手段

Sleep延时被拦截

BENCHMARK函数被拦截

可以看到常规的延时手法都直接拦截了,那么接下来使用我们刚刚讲解的锁机制来延时

锁函数造成延时

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

多web不使用连接池+长会话+短会话:

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

先使用MRCMS-3.1.2的漏洞接口注入来获取锁:

然后在sqli-labs中直接注入

?id=1%27||%20GET_LOCK(1,5)%20||%27

成功造成延时效果,且不触发雷池waf拦截

接着嵌套if语句,依旧成功造成延时,且不触发雷池waf拦截

?id=1%27||%20if(1,GET_LOCK(1,5),1)%20||%27

通过数据库监听工具看到时间部分确实造成了延时,以及长会话和短会话共用数据库连接导致的不同会话造成了锁等待,最终产生延时效果

到雷池waf后台可以看到锁函数实际上是检测到了,但在默认配置下不拦截,只拦截了底部的两条比较常见的延时函数。

总结

利用锁机制的优势就是不易被waf检测(在写文章的时候似乎写入其他延时payload会导致出错无法预览,而锁机制的延时payload则可以正常预览,这也算是不易被检测的一种),既然大名鼎鼎的雷池waf都能成功延时,那么市面上大多数的waf应该也一样。

那么接下来的注入方法就由各位师父大显神通了,这里就不再做太多的赘述。

相关推荐
码农12138号1 小时前
BUUCTF在线评测-练习场-WebCTF习题[GXYCTF2019]BabyUpload1-flag获取、解析
web安全·网络安全·文件上传漏洞·buuctf·解析漏洞
Johny_Zhao1 小时前
Docker + CentOS 部署 Zookeeper 集群 + Kubernetes Operator 自动化运维方案
linux·网络安全·docker·信息安全·zookeeper·kubernetes·云计算·系统运维
诗句藏于尽头3 小时前
完成ssl不安全警告
网络协议·安全·ssl
独行soc7 小时前
#渗透测试#批量漏洞挖掘#HSC Mailinspector 任意文件读取漏洞(CVE-2024-34470)
linux·科技·安全·网络安全·面试·渗透测试
Me4神秘8 小时前
Linux国产与国外进度对垒
linux·服务器·安全
老K(郭云开)9 小时前
谷歌浏览器安全输入控件-allWebSafeInput控件
安全
Whoisshutiao9 小时前
网安-XSS-pikachu
前端·安全·网络安全
还是奇怪10 小时前
Linux - 安全排查 2
linux·运维·安全
Clownseven16 小时前
云端备份与恢复策略:企业如何选择最安全的备份解决方案
安全
薄荷椰果抹茶18 小时前
【网络安全基础】第六章---Web安全需求
安全·web安全