一、SQL Injection的原理
SQL Injection的实现方法和破坏作用有很多,但万变不离其宗,其原理可以概括为一句话 :SQL Injection就是向服务器端提交事先准备好的数据,拼凑出攻击者想要的SQL语句,以改变数据库操作执行计划。

这句话主要包含这么三层意思:
1.攻击者通过何种途径注入?
存在SQL Injection漏洞的地方都是应用程序需要根据客户端环境构造SQL语句的地方。由此可以推论,只要存在”客户端数据替换预定义变量”的地方,就有可能被注入。客户端提交数据可以有很多种方式:GET,POST,Client-Agent,Cookie,Server Enviroment…
2.攻击者为什么可以将它想要的语句”注入”?
因为服务器端应用程序采用拼凑(请特别留意这个词)SQL语句的方式,这使得攻击者有机会在提交的数据中包含SQL关键字或者运算符,来构造他们想要的语句。
3.SQL Injection最终结果是什么?
改变数据库操作执行计划。
这个结果不一定是恶意的,只要你的SQL语句没有按照你预期的计划(plan)执行,那么就 可以视为被注入了,不管提交数据的人是不是恶意的。

设有这样的sql语句:

  1. update `tableName` set `columnName1` = " $Client_Submit_Data " where `PK_ID` = '1234'  

假设这个操作是要更新一篇文章的标题,很多人是不是会这么构造SQL语句?我们看看$Cl ient_Submit_Data包含引号的情况,令

  1. $Client_Submit_Data = '谁能告诉我"sql injecti on"是什么?' 

那么sql语句将被拼凑成这样:

  1. update `tableName` set `columnName1` = "谁能告诉我"sql injection"是什么?" where `PK_ID` = '1234'  

执行结果很明显,将执行这样的语句:

  1. update `tableName` set `columnName1` = "谁能告诉我"  

where子句被忽略掉了,很遗憾,你的数据库中所有文章标题都会被update为”谁能告诉我 ”
 
如何应对这种问题。
 
我认为,彻底解决SQL Injection的最好方法是:避免拼凑SQL语句。这就是我在上面要大家特别注意拼凑这个词的原因。
SQL Injection之所以有机可乘,是因为绝大多数Server Application采用拼凑SQL语句的方式来构建应用程序(阅读这个帖子的诸位,你们回首想想自己的项目,有几个不是通过拼凑SQL语句的方式来操 作数据库?想想你们见过的被注入的案例,有几个不是采用的拼凑SQL语句的应用),所谓拼凑SQL语句,简单一点说就是:用连接字符串操作将SQL关键字和客户端提交的数据连接起来并发送给DBMS执行。这样做直接导致 DBMS根本不知道你计划(plan to)做什么,而只知道你要(is to)做什么,不是吗,服务器端脚本总是将要执行的SQL语句构造好,然后发给数据库,DBMS根本不知道客户端数据 替换了变量之后,这个语句的执行计划是否有变化。服务器端脚本总是粗暴的告诉DBMS:你只管这么做好了,别问我为什么。就像上面我提到的更新文章标题的 例子,DBMS不知道你只想更新第1234篇文章的标题,它以为你就是要把所有的标题都变成这个,因为你的语句就是没有where子句嘛!
 
说到这里,可能大家都明白了,所谓的最好方法是Stored Procedure。Yes! That is!
要想做出安全可靠的Server application,你最好把自己当作两个人,一个DBA,一个Coder,很多人往往只知道:我在做一个BBS,我在做一个留言本,我在做一个新闻发布系统,我们的流程都是这样的,给用户一个表单,让用户提交, 然后去写数据库,用的时候根据条件把数据记录找出来,然后显示。没事,如果你 是一个业余爱好者,只想自己写点小东西玩玩,这足够了!如果你想把WebDev作为你的职业,或者说,你想成为一个非常专业的业余爱好者,你必须当自己是 一个DBA+Coder,至于要不要是一个Designer就看你的能力和精力咯!
 
好了,点到为止,我就说这么多,彻底的解决方法是要在DBMS上写入你的数据操作计划,让服务器在开始执行之前知道你的意图,不要粗暴的告诉它:我就是要你执行这个命令,不要问我为什么!
 
实现方法嘛,目前比较普遍的,也比较容易实现的就是存储过程了,应用存储过程不仅可以从根本上解决SQL Injection这个安全问题,还会使得你的应用程序速度成倍增长(这个增长的幅度甚至可能达到一个数量级,这跟很多因素有关,不好一概而论),还会使 得你开发的系统更想大型系统,拥有更好的架构体系(例如MVC模式)。
 
在 MySQL 4.1.x及其后续版本和ODBC中,提供了一种叫做prepared statements的东西,它 本质上也是一种存储过程,一种系统预置(相对于用户自定义)的存储过程。
如 果你没有条件用上存储过程(比如数据库不支持,MySQL,Access,SQLite等都不支持),那么就只能将SQL Injection扼杀在摇篮里了。解决方法,我也只简单的说一句:不要相信任何来自客户端的数据。这个客户端的数据,可以通过很多途径被提交,比如 get,post ,cookie,browser参数,IP地址,等等,只要不是服务器上获取的就都算客户端数据,只要是客户端数据,都是不可信的,在TCP/IP这个大 框架下,什么都是可以伪造的,包括IP地址。
 
凡是来自 也无法穷举可能被用于SQL Injection的符号和关键字,也无法预知替换掉他们是否会有副 作用,最好的办法是不去判断什么数据不符合条件,而改由判断什么数据符合条件,假设你的一个系统用户名只能是字母数字和下划线,那么你就可以用 [0-9a-zA-Z_]+这个正则来匹配它,如果不符合条件,拒之即可,这比费尽心思去过滤单引号分号逗号空格什么的要明了和简洁的多。 

 

附带:PHP防注入的最简单函数

 

  1. $_POST = sql_injection($_POST); 
  2. $_GET = sql_injection($_GET); 
  3.  
  4. function sql_injection($content)
  5. if (!get_magic_quotes_gpc()) { 
  6. if (is_array($content)) { 
  7. foreach ($content as $key=>$value) { 
  8. $content[$key] = addslashes($value); 
  9. else { 
  10. addslashes($content); 
  11. return $content