BlueCMS v1.6 sp1 ad_js.php SQL注入漏洞
前言：
在家无聊的时候看了看wooyun当时代码审计的一些案例，能找到源码的就本地搭建复现一下，留点给大家的思路。
针对于 BlueCMS v1.6 sp1 ad_js.php SQL注入漏洞，找到了源码，结合着别人的思路静态审计+动态调试，给大家留下一些思经验。
Tip：SQL语句的拼接
首先看看common.fun.phpw文件，里面的deep_addslashes()函数就是对addslashes()函数做的封装，addslashes()函数的作用是返回在预定义字符之前添加反斜杠的字符串。预定义字符是：单引号（’），双引号（”），反斜杠（\），NULL。其实这样看来，如果过滤的好，除了使用宽字节注入就没有其他方式进行单引号逃逸了。
不过等我看完Wooyun这篇案例后在前面的前提中又加了一个SQL一定要写的好，比如admin/ad.php里面的语句是这样的：
在$sql的变量中看到查询的SQL语句是拼接的，其中$ad_name，$time_set，$content，$exp_content，$ad_id都是用户可控的参数，在开发中保持的原则就是要相信用户输入的都是危险的，都需要做处理，因此前面提到的前四个参数（除$ad_id ）是参数单引号包裹都经过了deep_addslashes()函数过滤。
不过在拼接SQL语句的最后面我们可以看到WHERE ad_id = $ad_id没有单引号包裹，所以不需要逃逸引号闭合，理论上容易出现SQL注入问题 。但是我们又可以看到 $_POST[‘ad_id’]前面又用intval() 函数做了强制类型转化，保证了处理的只能是int类型，所以导致不能进行SQL注入。
但是百密一疏，整套源码中还是出现了没有类型转换且不需要逃逸引号的地方，在文件ad_js.php中：
在执行这句SQL语句的时候，$ad_id参数 只用trim()去除头尾空格，并没有像前面一样用 intval()进行强制类型转化，且参数可控，导致我们可以拼接SQL语句进行注入：
动态调试跟踪输入后处理的状态和结果发现已经成功的进行SQL注入攻击，攻击成功状态如下图：
写个检测插件冷静一下吧。
顺便给个防御建议：
1.强制类型转换
intval()
