2007年4月3日星期二

防范SQL注入几点小建议

SQL注入还是很流行和普遍,随着web程序的风行,甚至有愈演愈烈之势。
关于SQL注入的影响,也是可大可小的,当然不是每个SQL注入的漏洞都能让入侵者拿到系统级别权限,实际上稍做配置,就不太容易了。不过以上我说的几步很简单,简单到所有的脚本小子高中生初中生都会,准确地说,他们比我更擅长和更迅速,有简单而高效的利用工具,甚至他们不需要学习什么是SQL。

然而五六年过去了,这些伎俩都没有过时,可见并非所有的防守方的防范技术都在与时俱进。谈论SQL注入的文章很多,却很少看到有文章全面的从开发者的角度出发,列出实际开发中应该注意的一些防范措施,本文尝试做这么一件事情。关于什么是SQL注入,有很多文章谈过了,就不详谈了。

造成SQL注入的一个很重要的原因是,数据和逻辑的混杂。很常见的做法就是,将用户的输入和SQL语句进行拼接,最终导致了用户的输入变为了SQL语句的一部分。因此,防范SQL注入的一个很重要的原则就是,让数据只是数据,尽量不要使用用户的数据来构造SQL语句。当然,SQL注入如此盛行的另外一个重要原因是,充满想象力的恶意输入。

类似SQL这样的结构化查询语句,都有可能有类似的注入攻击,比如LDAP,甚至XPath。

如何防范SQL注入呢?以下几点可以帮助你。

1) 使用参数化的查询

不同的语言和平台都有不同的方式使用。比如,在ADO.net中,可以使用Paramater.Add;在Java中,可以使用setString, setBoolean等;Perl DBI Module,则使用Prepare, bind_param。

使用参数化查询,自然避免了使用拼接字符串以构造SQL语句,因此也把用户的输入和程序的逻辑分离开了。另外,也有了强类型的检查。不用再担心单引号和分号等等“非法”字符了。

2) 在存储过程中使用参数化输入

如果使用存储过程,则应使用参数作为存储过程的输入。

利用存储过程来防范SQL注入,也依赖于使用的方式,如果又重新回到了拼接字符串,依然可能导致SQL注入。

而且,有些数据库不支持存储过程,比如PostgreSQL,MySQL4.x,Access。

另外,对于存储过程,只要赋予数据库用户对存储过程最小的权限就可以了,一般来说,就是执行的权限。

3) 严格验证用户输入

越严格越好,比如不光是过滤或escape/encode一些常见的非法字符,而是只允许输入符合要求的字符,比如对于id,可能就是0-9的数字,等等。

4) 不暴露任何错误消息

攻击者们总是喜欢通过错误信息以判断是否存在SQL注入的问题,另外也通过错误信息以获得进一步的信息。一个好的做法是,一旦出错,就跳转到自定义的错误页面。

5) 配置安全的数据库

本着深度防守的原则,数据库的安全配置也是很重要的一环。比如,即使有SQL注入的问题,但是程序里数据库用户的权限极低,这样也可以把影响降到最低。这里可能有很多的tips,比如

* 尽可能少的权限,
* 把管理的帐号的程序使用的帐号分开
* 去掉一些危险的扩展存储过程,比如SQL Server里面的xp_cmdshell
* 打好补丁
* 数据库的密码不要放在配置文件里
* ….

原本想更详细和具体点,无奈细节很多,最近时间又有限,只好匆匆提笔又匆匆收笔了,当然实在是不应该的,所以还望各位斧正和提供意见了。

没有评论:

其他的文章

 
©2003-2007 [ 温柔菜刀 ] : Blogger Name 刘斌的博客