SQL注入还是很流行和普遍，随着web程序的风行，甚至有愈演愈烈之势。
关于SQL注入的影响，也是可大可小的，先说个小故事吧。记得五六年前帮助一个朋友对他的网站义务做渗透测试时，随手试试，就找到个SQL注入的问题。于是打个电话给朋友，告诉他有这样的问题的严重性，他很客气的说，“太谢谢你了，哦，SQL注入啊，没关系了”。我无语片刻后，花了一点时间，利用刚找到的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，比如
a. 尽可能少的权限，
b. 把管理的帐号的程序使用的帐号分开
c. 去掉一些危险的扩展存储过程，比如SQL Server里面的xp_cmdshell
d. 打好补丁
e. 数据库的密码不要放在配置文件里
f. ….
