防范SQL注入几点小建议

2007-04-06 » 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 * 打好补丁 * 数据库的密码不要放在配置文件里 * …. 原本想更详细和具体点，无奈细节很多，最近时间又有限，只好匆匆提笔又匆匆收笔了，当然实在是不应该的，所以还望各位斧正和提供意见了。