依然是一次关于SQL注入的记录

2024年5月13日01:04:20评论8 views字数 837阅读2分47秒阅读模式

0x00 文章背景

是的，又是一个自闭的下午，Xray扫到一个注入，我本来以为可以直接梭哈出来库名，这样的话高危又到手一个，离完成KPI就又近了一步。结果，好好好，我遇到的注入都是比较抽象的这样子。

0x01 中道崩殂

根据Xray给的测试语句，肉眼可见延迟：

那么必有注入，但是延时比较麻烦，那么我们把它变成盲注：

case when 1=1 then 1 else 0 end

所以，先来判断长度是否大于3，直接返回，无延时，故为true：

将大于号改成等于号，那么长度不等于3，所以为fasle，判断来到else当中，故此延时生效：

语句是没问题的，直接拿BP跑一下，看库名的长度是多少:

这里通过响应来排序，肉眼可见的9位长度。到这里都是没毛病的，下来就拉闸了。

取库名

到这就没反应了，我狠狠的裂开了：

依然是一次关于SQL注入的记录

语句实在是没问题，理论上应该延时，指定是出了问题，但是我没找出来问题出在哪个地方。

0x02 不会就问

于是，秉承着我的座右铭：

菜就多练，不会就问

好的，得到了我想要的结果。这里不让用逗号，所以substr或者是mid函数直接就萎掉。那么逗号可以换成from for的形式，是一样的效果：

select substr('abc' from 1 for 1)

把逗号换掉，改成from for的形式：

然后把库名爆出来，BP跑的话我会使用hex函数来跑。不了解的话，可以看我去年发的这篇文章：

'or(case when (hex(mid(database() from 1 for 1))='1') then 1 else (sleep(2)) end)='1

当然了，用sqlmap跑肯定是释放双手了，但前提需要知道到底是什么玩意不能用，才能选择正确的Sqlmap tamper来绕过。

(

END

)

依然是一次关于SQL注入的记录

原文始发于微信公众号（犀利猪安全）：又幸福了 | 依然是一次关于SQL注入的记录

免责声明:文章中涉及的程序(方法)可能带有攻击性，仅供安全研究与教学之用，读者将其信息做其他用途，由读者承担全部法律及连带责任，本站不承担任何法律及连带责任；如有问题可邮件联系(建议使用企业邮箱或有效邮箱,避免邮件被拦截，联系方式见首页)，望知悉。

CVE-2017-3066 深入利用获取命令回显