现在网上流传一种方法，就是利用额外访问量来进行拒绝服务式攻击，这种攻击，只需要一个文件，短短的几行代码，就可以通过访问该文件的用户，在他们不知不觉的情况下给你的目标带来数十倍，甚至上百倍的访问量，当该文件的访问量达到一定数目时，给对方带来的压力将是非常可怕的。而且，这种攻击由于攻击源都是普通用户，无法在放火墙上面做任何设置，可以说是防不胜防。但是道高一尺，魔高一丈，有矛必有盾，这样的攻击方式很难维护，但是也绝对不是不能防护。下面讨论一下防御办法。
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漏洞也得到了很好的防御。
这仅仅是个示范代码，这个函数还有许多可以改进的地方：
1）可以增加函数变化的强度，降低函数被猜测出具体过程的概率。
2）可以把函数运用到Cookie中，对于Cookie做相应的变化，增加防御手段的隐蔽性。
3）可以把客户IP加入函数运算，不光节约增强了函数强度，还达到防止盗链的功能。一旦用户改变IP或伪造COOKIE及ID，马上就发现
4）可以把时间加入函数运算，不光节约服务器的存储空间，而且服务器只要通过对客户发送的字符串进行解码就能判断出客户信息。
