SQL Injection(SQL注入)介绍及SQL Injection攻击检测工具.doc

一、SQLInjection的原理
SQLInjection的实现方法和破坏作用有很多，但万变不离其宗，其原理可以概括为一句话：SQLInjection就是向服务器端提交事先准备好的数据，拼凑出攻击者想要的SQL语句，以改变数据库操作执行计划。
我想，这么说也许不算精炼，但意思应该很明确了，这句话主要包含这么三层意思：
1.攻击者通过何种途径注入?
存在SQLInjection漏洞的地方都是应用程序需要根据客户端环境构造SQL语句的地方。由此可以推论，只要存在"客户端数据替换预定义变量"的地方，就有可能被注入。
客户端提交数据可以有很多种方式：GET，POST，Client-Agent，Cookie，ServerEnviroment...
2.攻击者为什么可以将它想要的语句"注入"?
因为服务器端应用程序采用拼凑(请特别留意这个词)SQL语句的方式，这使得攻击者有机会在提交的数据中包含SQL关键字或者运算符，来构造他们想要的语句。
3.SQLInjection最终结果是什么?
改变数据库操作执行计划。
这个结果不一定是恶意的，只要你的SQL语句没有按照你预期的计划(plan)执行，那么就可以视为被注入了，不管提交数据的人是不是恶意的。
设有这样的sql语句：
updatetableNamesetcolumnName1="$Client_Submit_Data"wherePK_ID=1234
$Client_Submit_Data是一个变量，它代表客户端提交的数据，这里我就不管环境是ASP还是PHP还是其他什么东西了。
假设这个操作是要更新一篇文章的标题，很多人是不是会这么构造SQL语句?我们看看$Client_Submit_Data包含引号的情况，令$Client_Submit_Data=谁能告诉我"sqlinjection"是什么?
那么sql语句将被拼凑成这样：
updatetableNamesetcolumnName1="谁能告诉我"sqlinjection"是什么?"wherePK_ID=1234
执行结果很明显，将执行这样的语句：updatetableNamesetcolumnName1="谁能告诉我"
where子句被忽略掉了，很遗憾，你的数据库中所有文章标题都会被update为"谁能告诉我"
在这个例子当中，用户应该是无心的——标题里面包括引号应该很正常吧——但结果却和SQLInjection无异。
好啦，说了半天废话，言归正传，说一下如何应对这种问题。
我相信这里的朋友都看过很多防止SQLInjection的文章了，也大都会通过replace来防范一些注入，问题是：你们知其然的时候是否知其所以然?
我认为，彻底解决SQLInjection的最好方法是：避免拼凑SQL语句。这就是我在上面要大家特别注意拼凑这个词的原因。
SQLInjection之所以有机可乘，是因为绝大多数ServerApplication采用拼凑SQL语句的方式来构建应用程序(阅读这个帖子的诸位，你们回首想想自己的项目，有几个不是通过拼凑SQL语句的方式来操作数据库?想想你们见过的被注入的案例，有几个不是采用的拼凑SQL语句的应用)，所谓拼凑SQL语句，简单一点说就是：用连接字符串操作(ASP中的&和PHP中的.)将SQL关键字和客户端提交的数据连接起来并发送给DBMS执行。这样做直接导致DBMS根本不知道你计划(planto)做什么，而只知道你要(isto)做什么，不是吗，服务器端脚本总是将要执行的SQL语句构造好，然后发给数据库，DBMS根本不知道客户端数据替换了变量之后，这个语句的执行计划是否有变化。服务器端脚本总是粗暴的告诉DBMS：你只管这么做好了，别问我为什么。就像上面我提到的更新文章标题的例子，DBMS不知道你只想更新第1234篇文章的标题，它以为你就是要把所有的标题都变成这个，因为你的语句就是没有where子句嘛!
说到这里，可能大家都明白了，所谓的最好方法是StoredProcedure。Yes!Thatis!
要想做出安全可靠的Serverapplication，你最好把自己当作两个人，一个DBA，一个Coder(ASPCoder,PHPCoderorothers)，很多人往往只知道：我在做一个BBS，我在做一个留言本，我在做一个新闻发布系统，我们的流程都是这样的，给用户一个表单，让用户提交，然后去写数据库，用的时候根据条件把数据记录找出来，然后显示。没事，如果你是一个业余爱好者，只想自己写点小东西玩玩，这足够了!如果你想把WebDev作为你的职业，或者说，你想成为一个非常专业的业余爱好者，你必须当自己是一个DBA+Coder，至于要不要是一个Designer就看你的能力和精力咯!
好了，点到为止，我就说这么多，彻底的解决方