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

补充截图：