震惊！MSSQL眼里的00字符居然是这个亚子,sqlchop,安全狗，奇安信WAF被绕过
-0x01悲报
邪恶的安全狗官方视奸了本博客，看到了这个访问量不足20的文章并在十天甚至九天一瞬修补了bypass的技巧,坐实了他们每天25小时高强度全网搜索bypass技巧的猜测。
他们无耻地拦截了union[所有符号]all[所有符号]select走向了更加粗鲁的位置，简直跟国内的云防护学坏了！
不幸中的万幸就是他们就知道修补union注入中00字符的问题，并没有考虑到布尔注入的处理规则仍然存在问题，我就在618晚上更新这个，看看他们多久修补
0x00为什么我要写这个
嘻嘻嘻，上次干了云锁现在还没修复，估计他们也没看到，不妨再放点东西出来
希望安全狗官方不要看到这个
blogspot似乎有bug,我无法打出%+00,所以后文的00字符都用【00字符】代替
0x01Payload
id=1【00字符】union【00字符】all【00字符】select【00字符】null,@@version,null
为了防止这些厂商不认账,特地贴出bypass的图
他们又不是3█0怎么会这么做嘛
更新:发现奇█信的也能bypass,鉴于奇█信原来也是3█0的,故特此补图.由于他们非常无耻地直接拦截关键字@@version故select一些不关键的元素代替,但是只要细心构造也是能找到完全绕过的办法的.
更新:发现奇█信的也能bypass,鉴于奇█信原来也是3█0的,故特此补图.由于他们非常无耻地直接拦截关键字@@version故select一些不关键的元素代替,但是只要细心构造也是能找到完全绕过的办法的.
0x02 为什么能Bypass?
似乎mssql会把【00字符】当作空格于是导致bypass,真的神奇了
由于这个特性之前好像没人提,fuzz的时候都是从%01开始的，这个新发现的特性估计可以通杀一波WAF了?
突然感觉放出来好亏
由于这个特性之前好像没人提,fuzz的时候都是从%01开始的，这个新发现的特性估计可以通杀一波WAF了?
评论
发表评论