故事A段:发现整站SQL对外输出:
有个朋友的网站,由于是外包项目,深圳某公司开发的,某天我帮他检测了一下网站相关情况。
我查看了页面源代码,发现了个惊人的事情,竟然整站打印SQL到Html里,着实吓我一跳:
PS:2年前秋色园系列文章有分享一文是整站SQL打印用于分析网站性能,不过也只是本地优化调试,而服务器上也采用某特殊条件才打印。
于是把这赤祼祼的对外公开的SQL问题反映了过去,之后算是取消了。
故事B段:错误异常打印了SQL,诱人:
过了些许天,我又抽空看了看:
原始路径为:http://www.xxx.com/s-l----333.html,我随意加了个引号:
直接打印SQL?这不是引诱人犯罪么?好吧,当时被诱了一下,花了小半天折腾了一下。
故事C段:发现有简单的SQL关键字过滤:
随意加了个“and“条件,发现有过滤一些关键字:
然后多次检测,发现过滤了:and select,update,delete等关键字。
故事D段:发现可以执行自定义语句,但SQL账号似乎没有SA权限或者是关闭了xp_cmdshell服务:
于是我组了一条truncate table xxx,当然,这是个不存在的表名:
试了下,执行完成,没报啥提示,太恐怖了。
既然可以执行自定义语句,那执行下提权语句看看:
http: // www.xxxx.com/s-l-82900-6'%20%20or%201=1;exec master..xp_cmdshell 'net localgroup administrators test /add
发现没啥提示,但是账号不起效果,所以估计sql的账号没有sa权限可以调用xp_cmdshell,另外这里,由于--符号被用来分隔字符串,所以不起作用。
故事E段:发现登陆有明显的SQL漏洞:
过了点时间,我就不折腾了,我打算注册个账号看看其它情况。
到了登陆页,发现注册还要绑定手机号,我就不注册了,于是在登陆里随手弄了一个常见的a' or 1=1--
竟然报密码错误,吓我一跳,说明用户名注入了,只是密码那关错误。
故事F段:发现验证码竟然在Cookie里:
通过拦截请求信息,发现更奇葩的事:
验证码竟然直接放在Cookie里,这。。。
故事G段:破解用户密码:
既然用户名可以注入,为啥密码还报错误?
通过错误的语法,看了一下对方的SQL语句,猜出了基本的代码逻辑:
构造注入语句,发现密码为md5存储:
一开始我构造了条件:
username=a ' or password= ' 123456 ' --&password=123456&verifycode=5020
考虑到用弱密码123456的很多,我就试了下,发现没搞头,本来还想写个爆破弱口令的账号。
后来想想,这密码,一般都是加密的,所以我要知道对方的加密方式。
通过多次构造类似下面的语句:
username=a ' or len(password)=16--&password=123456&verifycode=5020
最终确定了为md5加密存储。
于是把123456 md5一下变成:
username=a ' or password= '49ba59abbe56e057 ' --&password=123456&verifycode=5020
没想到,来了个以下坑爹的提示:
试了下很多个账号,都是这种情况,这提示太坑爹,忽悠了我。
PS:其实是账号通过了,直接拿返回的Cookie就可以进用户的,不过我被忽悠了,以为不可用。
返回的Cookie,实际也是加密的,所以,这种方式,看不到手机号,所以没法直接简单的登陆。
再构造SQL注入语句,创建属于自己的账号和密码:
所以,我就必须执行类似于:update xxx set username= ' 13811114444 ',password= ' 888888 ' where uid= 10003
由于过滤掉update,所以直接来是不行的,本来打还算编码成16进制折腾,发现转16进制麻烦,也懒的开vs折腾。
于是我想到了一个简单的方式,把语句反过来写,再用reverse函数把语句转过来执行。
最终就成了以下函数:
执行后,发现都是返回“当前账号已冻结,请联系客户”这句大忽悠的话。。。
害的我试了N个账号,最后拿其中一个登陆了,才发现是正常的。
后来告诉了对方有SQL注入漏洞,最后反馈说用SQL工具检测正常,无语。
再后来就示例告诉了对方,修正了这个漏洞后,我就写文分享了。
总结:
1:验证码怎么可以放Cookie里?
2:SQL语句怎么可以随意打印给别人看?
3:SQL注入检测怎么能光靠工具?
4:防SQL注入怎么能靠几个简单的关键字过滤?
本文转自cyq1162 51CTO博客,原文链接:http://blog.51cto.com/cyq1162/1254934,如需转载请自行联系原作者