来源：http://www.cnblogs.com/cheatlove/articles/384233.html
SQL注入攻击：
(1) 脚本注入式的攻击
(2) 恶意用户输入用来影响被执行的SQL脚本
风险：
风险方面，SQL注入攻击是位居前列的，与缓冲区溢出等漏洞基本相当。而且如果要实施缓冲区溢出攻击，攻击者必须首先能绕过站点的防火墙；而对于SQL注 入攻击，由于防火墙为了使用户能访问网络应用程序，必须允许从Internet到Web服务器的正向连接，因此一旦网络应用程序有注入漏洞，攻击者就可以 直接访问数据库进而甚至能够获得数据库所在的服务器的访问权，因此在某些情况下，SQL注入攻击的风险要高于所有其他漏洞。
解决方案：
(1) 在服务端正式处理之前对提交数据的合法性进行检查；
(2) 封装客户端提交信息；
(3) 替换或删除敏感字符/字符串；
(4) 屏蔽出错信息。
方 案(1)被公认是最根本的解决方案，在确认客户端的输入合法之前，服务端拒绝进行关键性的处理操作，不过这需要开发者能够以一种安全的方式来构建网络应用 程序，虽然已有大量针对在网络应用程序开发中如何安全地访问数据库的文档出版，但仍然有很多开发者缺乏足够的安全意识，造成开发出的产品中依旧存在注入漏 洞；
方案(2)的做法需要RDBMS的支持，目前只有Oracle采用该技术；
方案(3)则是一种不完全的解决措施，例如，当客户端的输入为“… ccmdmcmdd…”时,在对敏感字符串“cmd”替换删除以后，剩下的字符正好是“…cmd…”；
方案(4)是目前最常被采用的方法，很多安全文档都 认为SQL注入攻击需要通过错误信息收集信息，有些甚至声称某些特殊的任务若缺乏详细的错误信息则不能完成，这使很多安全专家形成一种观念，即注入攻击在 缺乏详细错误的情况下不能实施。（实际上，屏蔽错误信息是在服务端处理完毕之后进行补救，攻击其实已经发生，只是企图阻止攻击者知道攻击的结果而已）