如何快乐地检测SQL注入 - FreeBuf网络安全行业门户

官方公众号企业安全新浪微博

FreeBuf.COM网络安全行业门户，每日发布专业的安全资讯、技术剖析。

FreeBuf+小程序把安全装进口袋

Web安全

^{0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
90
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9}

^{0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9}

如何快乐地检测SQL注入

Asura57 2023-01-03 10:36:09 299084

所属地云南省

这估计大家也都发现了，测试SQL注入这种漏洞啊，又有WAF页面又没有明显的报错的情况下, 测试起来就是一个字，烦。

有waf：

我 and 1=1, 啪，它拦了。

我 order by, 啪，它拦了。

我 sleep(5), 啪，它拦了。

我 benchmark(50000000,MD5(1)), 啪，它又拦了。

页面不报错：

我插入一个' 符号, 啪，返回码还是200，不仅不报sql语句的错误，比如SQL syntax error near这种，连通用错误都不报，比如返回一个500响应码啥的。只有一个空的响应，但我不知道是因为我插入了' 导致代码执行异常然后被错误处理程序处理了返回了一个空响应还是因为数据库压根没这个数据返回了一个空响应。当然，有时候也不是空响应，而是返回的页面的发生的微小的变化，需要你放大眼睛才能看见

所以就有这么一个情况，有的人吧，他学了很多sql注入语句，但一开始测试一被waf拦或者页面没有明显报错信息就不知道咋办了。懵了，那怎么办呢。

所以我想了几分钟，终于发现一个比较适合测试SQL注入的方法。

简单来说，就是不依赖插入荷载导致页面差异来判断，而是依赖插入荷载页面是不是还是一样来判断。

不需要' and 1=1 然后 ' and 1=2这种，

因为这样的操作不仅不容易被WAF检测，还能高效判断是不是可能有注入。

下面进入实例讲解。

我去搜了我h1的报告，我发现只有一个sql的漏洞，还是重复的。我打开一看发现已经修复了。

1628845834_6116370a882737006cc85.png!small

这有问题吗？没有问题

因为我还可以用靶场。而且就算没修复，万一打码不严谨，导致意外事情发生，那不就脸黑了。

用这个靶场

https://portswigger.net/web-security/sql-injection/blind/lab-conditional-responses

第一步，当然是先确定我们的输入能不能影响页面。

输入一个fake

1628847572_61163dd47259c61a65349.png!small

1628847444_61163d54319f70e27df68.png!small

很明显，影响了，一个有Welcome back!，一个没。

1628847349_61163cf58eb398332f434.png!small

然后呢，然后很简单，插入一个荷载，然后页面还有Welcome back!，我就认为是有注入的。

插入的荷载要根据具体情况具体构造。

比如这里，TrackingId的值为c7oeRGoH7RkYYQzC，给c7oeRGoH7RkYYQzC 变形一下。

c7'||'oeRGoH7RkYYQzC

c7' 'oeRGoH7RkYYQzC

c7'%2b'oeRGoH7RkYYQzC

上面的荷载无论哪个返回了和c7oeRGoH7RkYYQzC 一样的页面，都可以怀疑是有注入，

为啥是这样3个荷载，很简单，因为是我从这里抄来的。

1628847871_61163eff50170aced649b.png!small

代表了4种数据库连接字符串的方式。

那么直接公布答案，这里是c7'||'oeRGoH7RkYYQzC返回了一样的页面。

所以后端要么是Oracle数据库，要么是PostgreSQL

那么能证明存在注入了吗，当然

不能

万一代码被特殊符号直接过滤掉了，啥特殊符号通通去掉。c7'||'oeRGoH7RkYYQzC

特殊符号去掉以后还是c7oeRGoH7RkYYQzC。那页面不还是一样嘛。

那有办法判断吗。

简单， ez ,

c7oeRGoH7RkYYQzC 变成c’7oeRGoH7RkYYQzC

c7oeRGoH7RkYYQzC 变成c|7oeRGoH7RkYYQzC

这样测一下，就知道特殊符号有没有过滤了，只要页面不一样，就说明没被过滤。注意，是不一样啊，

至于为啥，自己想想。那这样就能判断有注入了吗？当然

不能

万一代码里面遇到特性符号就报错，一报错就跳到错误处理，错误处理一处理完就返回一个默认值。那页面还是不一样，这跟注入半毛钱关系没有。那这样测试有啥用，有用，但不是决定性作用。哪怕看起来像是注入，其实也不一定是注入。

前面说到，能满足c7'||'oeRGoH7RkYYQzC的，后端要么是Oracle数据库，要么是PostgreSQL。

那么试一下下面两个。

c7'||'oeRGoH7RkYYQz'||to_char('C')||'

c7'||'oeRGoH7RkYYQz'||cast('C'+as+text)||'

如果第一个荷载导致页面一致，那数据库就是Oracle，

如果第二个荷载导致页面一致，那数据库就是PostgreSQL

别问我从哪里知道这些函数的，我从这里复制粘贴过来的。从不生产知识，只是知识的搬运工。

1628849127_611643e75722a90fa6562.png!small

那么这时候可以确定有sql 注入了吗？也许，可能，大概吧。因为话不能说得太满。

你发现一个可能存在注入的点，你直接发给一个注入大触手，让他帮你利用，然后啪地一声，几千刀到手，当然这波可能真的是你判断错误，这真不是一个注入点，那有关系吗，没有关系。敢想敢测，才叫挖洞。所以有两个字非常关键，配合。他没时间找可疑的漏洞点，你有时间找可疑的漏洞点，没法深入利用，这就叫配合。你看了这个文章，想要自己找到一个注入，然后发现这个网站10年的间就出现了两个注入的案例。

可能还有人想问，这是字符型的注入，那数字型的咋弄，前面不是说了嘛，具体情况具体分析，发挥你的想象力，你肯定可以自己构造的。

那这个方法就没有缺点吗？肯定有，两个缺点，第一个缺点是很容易产生误报；第二个缺点，有一种情况死活检测不到。