简单介绍一下SQL语句：通俗来理解就是开发者盲目相信用户，没有严格检查用户输入，导致用户可以输入恶意参数进入程序逻辑，最终拼接恶意参数改变原本的SQL语句逻辑，造成SQL注入漏洞。
本次审计的CMS是基于Web应用的B/S架构的团购网站建设解决方案的建站系统，它可以让用户高效、快速、低成本的构建个性化、专业化、强大功能的团购网站，采用PHP和MYSQL数据库开发技术，版本CV1.6。商业案例如下：
审计结果实战测试：
首先在本地搭建一个网站，方便之后测试，一键安装也没啥说的，跳过。重点讲讲这个团购CMS的SQL操作。这个团购CMS将SQL操作全部写到了include/library/DB.class.php文件：
然后分析这个文件，发现这里面的函数有些使用了：mysql_real_escape_string函数对参数进行过滤，整数参数就强制转换int类型
关于mysql_real_escape_string函数的注入可以尝试宽字节注入，当数据库编码采用GBK的时候可以尝试bypass函数检查，但是此处不适用。之后审计发现其中存在几个未对参数进行过滤直接执行SQL语句的函数：GetDbRowById、GetQueryResult、GetField。
此处采用敏感函数回溯的方法进行审计，先全局搜索这些函数，然后想办法对达到触发条件。
1、 全局搜索GetField函数，发现没有被引用的地方。
2、全局搜索GetQueryResult函数，搜索结果比较多，如下：
先尝试审计第一处：/ajax/manage.php，如下，如果存在，可以通过$id变量进行注入。
追踪如何触发函数：第490行，当变量action满足条件即可：
而继续回溯，$action的来源$_GET:
同时也发现id变量被强制类型转换了，哦豁，这下安逸了，这个点基本利用不了了。同时测试过程中此处还有一处调用了未过滤SQL函数：
不过都用到了ID参数进行注入，所以不能利用，放弃。
之后选择其他可能存在的地方继续审计：/manage/user/index.php
但是这两处同样存在intval参数过滤。
再继续搜索，发现/manage/vote/feedback.php
此处$question[‘id’]参数来源于前一个查询结果，可以考虑二次注入，不过此处因为id参数为提交问卷时系统自动生成，所以无法利用了。
最后两处调用这个函数的地方在DB.class.php中：其中一个属于LimitQuery函数调用，因为存在过滤，所以利用比较困难：
另外一处便是GetDbRowById调用，此处不存在过滤，可能存在注入，这个审计便放到下一部分：
3、全局搜索GetDbRowById函数：根据之前的审计，函数本身没有对参数过滤，其中调用的GetQueryResult函数也没有过滤，可能存在SQL注入。
可以发现GetDbRowById函数在include/library/Table.class.php文件存在调用：_Fetch函数和FetchForce函数
其中_Fetch函数在同类中的Fetch方法被调用：
因此需要全局搜索Fetch函数和FetchForce函数：
首先来搜索FetchForce函数，结果如下，还挺多的
首先要说的就是搜索的结果不一定全部存在注入，需要再次寻找其中疏于过滤的点进行验证，下面举几个栗子：
文件：/ajax/chargecard.php
不需要登录便可以直接访问这个文件，当$action为query时可以调用函数，且$secret不存在过滤，开启debug调试跟踪参数的流程：先输入secret=123’
可以看到对secret参数没有进行任何过滤便传入FetchForce函数：
将存在恶意字符的参数拼接SQL语句，造成SQL注入，因为此处存在对空格等字符的正则匹配，所以可以使用/**/代替空格。
因为此处不存在回显，要使用盲注，使用时间盲注验证，一个用时2秒，一个用时5秒
而且同文件下存在另外一处注入：
这个地方利用方法也差不多，就改一下action参数便可以。
再举一个不存在注入的情况：/ajax/manage.php
虽然调用了FetchForce函数，但是溯源之后发现对id变量进行了强制转换，因此属于不能利用的点。与此同时new.php也属于同理情况：
同时如果继续搜索审计就能发现其他存在注入的点：
其余的文件就不一一看了。
接下来查看Fetch函数：搜索结果如下
先来看文件：/ajax/system.php
不过这个地方应该是需要管理员登录的，登录之后传参是这个亚子的：
可以采用和之前相同的时间盲注：
再看另外一处漏洞：/api/call.php，此处不需要任何登录，可以在前台直接访问到文件，而且其中多个参数存在注入：
再之后很多便与上面的审计方法类似，还存在可以利用的点，也会存在许多无法利用的点，就不一一写出来了。
上面这个注入点还找到一个案例：
不过存在问题的便是这个CMS的密码加了一个固定字符串当作盐，在解MD5时会存在困难。
按照惯例，来小结几句。关于SQL注入的防御，应该有很多方法了，首先就是不信任用户输入，严格过滤参数，之后的话还可以使用预查询方案，之后的话还可以使用软硬件防火墙。不过这些理论上都会存在bypass的情况，不过我太菜，不会bypass。
另外就是关于参数过滤，如同上面，执行参数过滤，但是依然找到了漏网之鱼，所以过滤策略某种情况下也是不可靠的。
最后就是关于代码审计了，代码审计一时爽，一直审计一直爽，奥力给！！！
相关实验：SQL注入漏洞的代码审计02
