现在网上流传一种方法，就是利用额外访问量来进行拒绝服务式攻击，这种攻击，只需要一个文件，短短的几行代码，就可以通过访问该文件的用户，在他们不知不觉的情况下给你的目标带来数十倍，甚至上百倍的访问量，当该文件的访问量达到一定数目时，给对方带来的压力将是非常可怕的。而且，这种攻击由于攻击源都是普通用户，无法在放火墙上面做任何设置，可以说是防不胜防。但是道高一尺，魔高一丈，有矛必有盾，这样的攻击方式很难维护，但是也绝对不是不能防护。下面讨论一下防御办法。
1：利用参数变换保护数据库访问率：对于使用到数据库或者其它文件资源的动态页面可以使用参数变换，比如我们设定函数Encrypt(id)把id转化成String的参数，我们的页面news.asp?id=acehj.我们可以通过Decrypt(string)进行解码，把它们解回id这样一来，客户很难伪造一个合法的参数访问页面，页面在解码的过程中利用验证码就拒绝了非法客户的访问，避免了恶意客户的数据库访问，通过牺牲一点点的CPU计算时间获得了数据库访问的安全。大家先看几个例子看能不能猜出里面的函数变换139<=>adkl.110<=>abba.80<=>hag.11234567890<=>abdfhjlnprjs。
看出来了吗？Encrypt和Decrypt的代码如下：
＜%
Function Encrypt (id)
StrR=""
Chk=0
For x=1 to len(id)
StrR=StrR&chr(95+x+cint(mid(id,x,1)))
Chk=Chk+Cint(mid(id,x,1))
Next
Chk=Chk mod 26
StrR=StrR&chr(95+chk)
Encrypt=StrR
End Function
Function Decrypt(str)
StrR=""
For x=1 to len(str)-1
u=(asc(mid(str,x,1))-x-95)
StrR=""
For x=1 to len(str,x,1))-x-95
u=(asc(mid(str,x,1))-x-95)
StrR=StrR&u
Next
Chk=Chk mod 26
if right(str,1)<>chr(95+chk) then
response.write "验证错误"
response.end
end if
Decrypt=StrR
End Function
%＞
调用Encrypt(1235)得到acehj("aech?")时，只有？为j时能得到正确结果1234，除此之外的任何字符都将返回"现验证错误"。
通过这样的保护变化，客户访问的就是news.asp?id=acehj.无法看到实际id为1235,随机生成的id又无法通过验证过程，就无法通过软件模拟来制造多线程的合法访问，避免因为非法访问使得数据库资源耗尽而拒绝服务。另外，在这样的保护下，SQL lnjection漏洞也得到了很好的防御。