记一次SQL注入Bypass过程

前言

某日突然对肥宅的生活感到了厌倦，竟连肥宅快乐水喝起来也索然无味，我需要改变！想起胖友几天前发的一个灰色性质网站，正好测试一下打发时间。直入主题，通过访问网站发现需要输入密码，地址栏有传递参数，手工测试加引号报错，初步判断存在SQL注入。

链接：http://xxxx.com/login.php?id=1'

发现Get传入id参数，直接加引号

如上报错，且显示了数据库查询语句，select* from catconfig where id='1''。

一般来说到这里，可以直接扔进Sqlmap跑，我作为一个肥宅主义者-懒，自然选择抄起神器一顿操作，然后便出现如下的画面。

如上，Sqlmap报一大片刺眼的红色光芒让我的眼睛发疼，我知道这不是一个简单的站，“连接被重置”简简单单五个字让人心凉凉，这个站看似漏洞百出，实则暗藏玄机。根据我多年的计算机基础知识判断，这站应该是有WAF，只有WAF才能如此毫不讲道理，如此狠心，甚至没任何提示的就把我IP拉黑了，一般来说waf拉黑IP是有时间限制的，10-40分钟不等，可以设置。于是在等待的时间里，我进行信息收集。

正常的测试流程，信息收集应该是最先做的。不过我是个肥宅，不到必不得已，我很可能就忽略不收集了。

信息收集

在被拉黑的这段时间里，我收集了一些基本信息，如下

1、IP：x.x.x.x xx省xx市阿里云

2、独立服务器，无旁站

看到阿里云我突然就明白了，阿里云盾防护，难怪被拉黑了。此处透露一个可能人尽皆知的小技巧，阿里云盾不拦截阿里云自身的服务器，所以如果用阿里的ECS去跑就不会被拦截。不过我作为一个肥仔，能省一杯快乐水的钱则省一杯，不到必不得已，我不会去开通阿里云的ECS的。

过了差不多半个小时，我发现我的访问恢复了，顺带收集一下服务器环境信息。

1、容器：Nginx（访问不存在的目录，404页面）

2、系统：Linux（通过大小写判断，Linux对大小写敏感，Windows大小写不区分）

3、数据库：Mysql（引号报错）

4、脚本：php

（不瞎都看的出来）

在获取上述信息后，进行下一步的测试。

两层防护？

于是又回到原点，我看着这个主页面，页面静静的看着我，貌似在说：来啊，小老弟，怕你不成。此时我想点支烟，但我突然想起没有打火机，再一想，我根本不抽烟啊，于是我喝了一口快乐水，嗝～。

手工测试，顺手and1=1，返回

噗，这不是360安全主机吗？除了阿里云盾还有360安全主机？

于是开始了疯狂的Fuzz，感觉想用unionselect去查询是很困难的了，测试中发现使用报错注入能成功Bypass。如下：

exp(~(select*from(select%20user())x));--+

构造为：http://xxxx.com/login.php?id=1'and exp(~(select*from(select user())x));--+

如上，可以获取当前的数据库用户，附常用的函数，分别进行测试

1.version()——MySQL版本

2.user()——数据库用户名

3.database()——数据库名

4.@@datadir——数据库路径

5.@@version_compile_os——操作系统版本

此外，在该站点的另外一处注入点处，发现表名cat_members

此处先假定admin用户也存在cat_members表中，根据多年的计算机基础知识，一般列名为username，password。为什么这样，因为懒想碰碰运气。

那么我的查询语句应该是：

但是当试图读password数据时

于是进行测试，发现以下规律：

当出现Selectfrom时会进行拦截

于是整个测试重点变成了如何BypassSelect from 语句。

思考尝试

由上，测试主要受阻于拦截了Selectfrom语句，于是我抄起键盘一顿百度加论坛乱搜，找到了大佬们以前的bypass方法。

搜索到的一些Payload

1、/*!12345select*//**/from

2、/*!50001select*/from

3、Select/**/column_name/**/from

4、/*!/*!select*/column_name/*!/*!from*/

5、空格用/*!*/代替

6、%53elect/*!1,2,schema_name%0aFROM

7、Get+Post，编码，超长内容等等。

以上收集来源于土司论坛及百度搜索。

但测试发现只要带/**/这样就直接拦截了，所以上述的payload在此处都失效。

根据如上的测试，判断是通过正则进行匹配，只要匹配到某些字符则进行拦截

测试到这里，我已经很疲惫了，200斤的身体也开始慢慢透支，力不从心，于是我缓缓翻着网页上的搜索结果，继续逐个测试，竟然发现了转机。

突破总结

可能是真的运气好，真好，明天会更好，大家好，我是陆超。呃，回到话题，在先知论坛的一篇文章中，我的WafBypass之道（SQL注入篇）中，找到了一个Bypass方法。

链接：https://xz.aliyun.com/t/368

Payload：%23%0a

此处确实运气好，成功猜到了admin用户在cat_members,且列名为username、password。如果不是的话，可以使用以下方法，逐个获取，先获取表，在获取列名，不过需把空格替换为以上的payload。

接上，解密一下，登录即可

总结：

网上bypass的文章有很多，不过还是要结合实际进行测试，很多时候运气与坚持也占了很大因素，作为幸运肥宅，我不会轻易低头。后续发现此为匹配规则如下，作为小白，看得我脑壳疼，欢迎各位大佬指教。

文章仅用于普及网络安全知识，提高小伙伴的安全意识的同时介绍常见漏洞的特征等，若读者因此作出危害网络安全的行为后果自负，与合天智汇以及原作者无关，特此声明！