SQL Injection（SQL注入）介绍及SQL Injection攻击检测工具

核心提示： 假设这个操作是要更新一篇文章的标题，很多人是不是会这么构造SQL语句？我们看看$Cl ient_Submit_Data包含引号的情况，SQL Injection（SQL注入）介绍及SQL Injection攻击检测工具(2)，令$Client_Submit_Data = 谁能告诉我&quo

假设这个操作是要更新一篇文章的标题，很多人是不是会这么构造SQL语句？我们看看$Cl ient_Submit_Data包含引号的情况，令$Client_Submit_Data = 谁能告诉我"sql injecti on"是什么？

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

update tableName set columnName1 = "谁能告诉我"sql injection"是什么？" where PK_ID = 1234

执行结果很明显，将执行这样的语句：update tableName set columnName1 = "谁能告诉我"

where子句被忽略掉了，很遗憾，你的数据库中所有文章标题都会被update为"谁能告诉我 "

在这个例子当中，用户应该是无心的——标题里面包括引号应该很正常吧——但结果却和SQL Injection无异。

好啦，说了半天废话，言归正传，说一下如何应对这种问题。

我相信这里的朋友都看过很多防止SQL Injection的文章了，也大都会通过replace来防范一些注入，问题是：你们知其然的时候是否知其所以然？

我认为，彻底解决SQL Injection的最好方法是：避免拼凑SQL语句。这就是我在上面要大家特别注意拼凑这个词的原因。

SQL Injection之所以有机可乘，是因为绝大多数Server Application采用拼凑SQL语句的方式来构建应用程序（阅读这个帖子的诸位，你们回首想想自己的项目，有几个不是通过拼凑SQL语句的方式来操作数据库？想想你们见过的被注入的案例，有几个不是采用的拼凑SQL语句的应用），所谓拼凑SQL语句，简单一点说就是：用连接字符串操作（ASP中的&和PHP中的.）将SQL关键字和客户端提交的数据连接起来并发送给DBMS执行。这样做直接导致 DBMS根本不知道你计划（plan to）做什么，而只知道你要（is to）做什么，不是吗，服务器端脚本总是将要执行的SQL语句构造好，然后发给数据库，DBMS根本不知道客户端数据 替换了变量之后，这个语句的执行计划是否有变化。服务器端脚本总是粗暴的告诉DBMS：你只管这么做好了，别问我为什么。就像上面我提到的更新文章标题的例子，DBMS不知道你只想更新第1234篇文章的标题，它以为你就是要把所有的标题都变成这个，因为你的语句就是没有where子句嘛！