问题 代码安全是众多安全问题的根源。不安全的代码,往往能够被攻击者利用,从而窃取用户隐私甚至协助攻击者盗取商业机密。正因为如此,越来越多的公司在产品研发阶段引入了代码安全检查。常见的代码安全检查方法包括:人工遍历和静态工具扫描。但无论哪一种,都存在一定的弊端,特别是无法回避一个共同的问题:某些漏洞无法立即验证——前端构造的危险SQL命令是否已经在数据库中执行。 思路本文档以PHP+MySQL注入攻击为例,引入数据库审计功能,增强代码安全检查和漏洞挖掘的效率。在一个典型的Web安全架构中,Web前端都会与后台数据库进行交互。代码审计过程中无法发现的隐蔽问题,在数据库审计日志中往往能够得到体现。
策略以典型的SQL注入为例,当攻击者访问PHP注入点时,往往会通过篡改参数的方式提交注入命令。如果被攻击页面脚本确实存在漏洞,则非法命令必定会被带入SQL语句的执行过程。因此,在开启数据库审计功能的情况下,完全可以借助数据库审计日志,判断前端SQL注入是否成功。 实现下图是一个典型的PHP + MySQL注入点。前端Web页面存在SQL注入漏洞,导致攻击者提交的非法表单数据被带入SQL命令。(为方便演示,本页面回显了SQL语句。)
若要通过数据库审计日志查看SQL命令是否成功执行,还需要在执行该操作前配置MySQL数据库审计功能。方法如下: 编辑MySQL配置文件mysql.ini 设置log参数为指定日志文件路径,log=”E:/mysql.log” 修改完成后,保存配置文件并重新启动MySQL服务。 再次访问URL:http://127.0.0.1/sqlinject/sql.php,提交包含非法参数的SQL注入命令。 数分钟后(数据库写日志有缓存机制,不是立即写入),访问文件E:\mysql.log。可以清除地看到MySQL数据库确实执行了带有非法参数的SQL命令,由此可以判断sql.php的代码确实存在SQL注入漏洞。
本次安全代码检查的过程如下图所示,该方法同样适合于其它类型的Web代码安全检查,如:ASP、JSP等;特别是那些前端不显示总结本文档为代码审计、漏洞挖掘提供了一个有价值的参考性的思路。该思路能在一定程度上提高了代码审计的效率和精准度,但也存在一定的弊端,例如:生产系统一般不会轻易开启审计功能,因此该方案无法应用到生产环境。此外,如果网站应用较多,测试过程中产生的数据库日志量大,对日志进行检测和比对会产生一定的工作量。尽管如此,该方法仍然不失为有效的安全核查手段,毕竟在SQL日志中发现恶意数据库命令,足以说明前端代码的不安全性!
|