一些防止SQL注入攻击的方法

sql注入被那些菜鸟级别的所谓黑客高手玩出了滋味，，发现现在大部分黑客入侵都是基于sql注入实现的
，哎，，谁让这个入门容易呢，好了，，不说废话了，，现在我开始说如果编写通用的sql防注入程序
一般的http请求不外乎 get 和 post,所以只要我们在文件中过滤所有post或者get请求中的参数信息中
非法字符即可，所以我们实现http 请求信息过滤就可以判断是是否受到sql注入攻击。
iis传递给asp.dll的get 请求是是以字符串的形式，，当 传递给Request.QueryString数据后，，
asp解析器会分析Request.QueryString的信息，，然后根据"&"，分出各个数组内的数据
所以get的拦截如下
首先我们定义请求中不能包含如下字符
'|and|exec|insert|select|delete|update|count|*|%|chr|mid|master|truncate|char|declare
各个字符用"|"隔开，，然后我们判断的得到的Request.QueryString
具体代码如下
dim sql_injdata
SQL_injdata = "'|and|exec|insert|select|delete|update|count|*|%|chr|mid|master|truncate|char|declare"
SQL_inj = split(SQL_Injdata,"|")

If Request.QueryString<>"" Then
For Each SQL_Get In Request.QueryString
For SQL_Data=0 To Ubound(SQL_inj)
if instr(Request.QueryString(SQL_Get),Sql_Inj(Sql_DATA))>0 Then
Response.Write "<Script Language=JavaScript>alert('天下电影联盟SQL通用防注入系统提示↓nn请不要在参数中包含非法字符尝试注入！');history.back(-1)</Script>"
Response.end
end if
next
Next
End If
这样我们就实现了get请求的注入的拦截，但是我们还要过滤post请求，所以我们还得继续考虑request.form,这个也是以数组形式存在的，，我们只需要再进一次循环判断即可。代码如下
If Request.Form<>"" Then
For Each Sql_Post In Request.Form
For SQL_Data=0 To Ubound(SQL_inj)
if instr(Request.Form(Sql_Post),Sql_Inj(Sql_DATA))>0 Then
Response.Write "<Script Language=JavaScript>alert('天下电影联盟SQL通用防注入系统提示↓nn请不要在参数中包含非法字符尝试注入！nnHTTP://www.521movie.com ');history.back(-1)</Script>"
Response.end
end if
next
next
end if
好了大功告成，，我们已经实现了get和post请求的信息拦截，，你只需要在conn.asp之类的打开数据库文件之前引用这个页面即可。放心的继续开发你的程序，，不用再考虑是否还会受到sql注入攻击。难道不是么？

以上这种方法也算是一种方法，但是效率比较低。

目前关于sql injection目前网络上面能见到的方法都是加强数据库配置
在web程序中对参数进行严格限制来进行,这些方法对程序员和系统管理员有一定程序要求,而且碰到做虚拟主机业务的,就会防不胜防。
isapi_rewrite for iis 和apache mod_rewrite 是一种URL重写工具，可以
将输入的URL进行按要求转换,目前rewrite的最大用处就是在网站中将动态的页面
转换成静态的url，以便google之类的搜索引擎能搜到，增加排名。google里面有
很多的这种应用的例子，rewrite的相关信息也去google找.
利用rewrite模块的功能，能够很方便的实现对URL参数进行过滤，从而实现
主机级别的sql injection攻击防范。
rewrite对URL的匹配是一种正则表达式匹配，功能非常强大。
以过滤asp+sqlserver环境下的sql injection为例子，对某些特殊字符进行过滤
如：()';
则在httpd.ini中书写规则
RewriteRule [^?]+\?.*[;'\(\)].* /warning.txt
上面的规则将匹配URL的参数部分，如果参数中包含;'()，则将该URL重写，将/warning.txt的
内容返回给客户端，IIS log中也只会留下访问warning.txt的200信息。需要过滤得单个字符都可以直接加在[;'\(\)]中。
匹配2个字符串，如不想让URL参数中出现空格，--等，则使用如下的Rule
RewriteRule [^?]+\?.*(?:%20|--).* /warning.txt
RewriteRule 后面也可以跟一个[F]字段，表示禁止，如
RewriteRule [^?]+\?.*(?:%20|--).* /warning.txt [F]
这时，/warning.txt部分被忽略，如果匹配了字符串，该访问将被拒绝，返回404错误。
基本规则就这样，为了彻底的防止sql injection，这2个个规则需要写得很详细，将攻击中
要用到的特殊字符(串)一一过滤。
简单点的话，也可以不用" [^?]+\? "部分，则将匹配整个URL。

rewrite用处还不止是防止sql injection ,也可以用来做一些其他的限制，如默认自带的一条
规则：
RewriteRule .*(?:global.asa|default\.ida|root\.exe|\.\.|=).* . [F,I,O]
可以限制对含有global.asa,default.ida root.exe 以及".."的URL进行访问。

这种防止sql injection的方法相对于目前常用的方法来说，简单了不少，可以减少
程序漏洞带来的危害。
____________________________________________________________________
下面一段是回答别人问题的:
1.我这边的测试结果是,对post get head方式都有用.

2.这个问题(在URl编码前还是后?)我也有些疑惑,我的测试结果:
a.比如过滤空格,在规则中过滤%20就行了,应该是在解码之后(最后面的空格直接忽略的),我是重定向到readme.txt的
IIS Log:
06:39:30 127.0.0.1 HEAD /reply.asp id=9¤tpage=1% 200 结尾添加%
06:39:30 127.0.0.1 HEAD /reply.asp id=9¤tpage=1%2 200 结尾添加%2
06:39:30 127.0.0.1 HEAD /readme.txt - 200 添加%20

b.被重写的url不在服务器上运行.测试过程如下,copy cmd到web目录c.exe,开运行权限,
c.exe?/c+echo+test>test.txt
没加规则能产生test.txt
加上过滤>的规则后
c.exe?/c+echo+test2>>test.txt
test中无新数据.
另外,被重写的规则,在iis log中都是留下了访问重写后url的记录.
00:42:05 127.0.0.1 GET /c.exe /c+echo+test+>test.txt 502 前
00:43:31 127.0.0.1 GET /c.exe /c+echo+test+>>test.txt 502 前
00:43:36 127.0.0.1 GET /readme.txt - 200 加上规则

但是rewrite目前外面的运用基本上都是将动态页面以静态url输出,如果动态url被重写了,按照我上面的测试,根本不会在iis上执行,也就无法得到正确结果. 请高手研究一下rewrite的流程.

因为没有环境,暂时还没做性能上面的测试，谁有兴趣可以测试一下性能和这个isapi本身的安全性.

以下是User Agent的介绍

[ISAPI_Rewrite]

RewriteCond User-Agent: .*MSIE.*
RewriteRule /foo\.htm /foo.IE.htm [L]

RewriteCond User-Agent: (?:Lynx|Mozilla/[12]).*
RewriteRule /foo\.htm /foo.20.htm [L]

RewriteRule /foo\.htm /foo.32.htm [L]

看来rewrite的功能确实很强大的

HTTPHeaderName =
Accept:
Accept-Charset:
Accept-Encoding:
Accept-Language:
Authorization:
Cookie:
From:
Host:
If-Modified-Since:
If-Match:
If-None-Match:
If-Range:
If-Unmodified-Since:
Max-Forwards:
Proxy-Authorization:
Range:
Referer:
User-Agent:
Any-Custom-Header: