故事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注入怎么能靠几个简单的关键字过滤？
补充截图：
相关文章
