Sql="Select count(*) from Admin Where UserName='"UserName"' and Pwd='"Pwd"'" if rs(0) > 0 then....
这个时候的注入就是用or注入，构造出一个特殊的sql语句： Sql="Select count(*) from Admin Where UserName='' or ''='' and Pwd='' or ''='' " 这就是在用户名和密码的文本框都输入 ' or ''='' 构造出来的，这个时候count(*)的结果必然大于0，它等于你的admin表的记录数，因为每条记录都符合select语句的要求。当然我们可以通过制定相应的规则来过滤这种注入信息，同时辅助其他方法，比如我是这样写的：
复制代码 代码如下:
"select password from Admin where username='"UserName"'" if rs.eof then ... else if rs("password")=request.form("pass") then ... end if end if
这样的写法，即使你没有制定任何规则，那么上述方式也基本无法注入，因为它只能通过第一步检测，在后面的if rs("password")=request.form("pass") then 这里它就没有办法了，因为不会有人给管理员设置' or ''='' 这样的密码。这就没法相等，登录必然被拒绝。当然，为了稳妥起见，最好两种办法同时使用，确保万无一失。 注入还有一种经常被人忽略的情况，就是cookie注入。在一个参数既可能通过url传递，又可能通过表单传递的时候，大多数人都会简写为request("page")这样的方式。你轻松了，注入者也轻松了，因为request在不制定具体方法的时候，它尝试接收参数的顺序是QueryString/Form/Cookie，如果注入者伪造一个cookie，然后在浏览器中输入www.sitename.com/shownews.asp，如果shownews.asp里面写的是request，它就不会报错，因为程序从cookie中找到了id，如果没有对这个参数进行检测，那么注入就可能发生了。这里建议大家用select case或者if来判断，麻烦了一点，但安全第一呀。 二，ASP上传漏洞。用过几种无组件上传类，大同小异，都缺乏对上传文件类型的有效检测，这个问题比较郁闷，现在只能依靠其他手段来手动检测，而且都是在服务器端的。如果说ASP本身有什么问题的话，就在这里了。 三，后台权限判断。看过几个后台，权限判断都是只在登录的第一个页面判断权限，后台的每个页面都没有判断了。后台所有页面都是需要判断权限的，否则我在浏览器里直接输入某个功能页面的地址就可以畅通无阻了，你那个后台登录还做它干什么呢？ 四、忽略服务器端验证。javascript是个强大的东西，它最常用的功能就是客户端的检测，比如不许输入空字符，或者定义正则表达式完成更高级的检测，有的程序员觉得这很好，浏览器帮助验证了，客户端就减少了很多工作量，服务器负担也小了，性能也优化了。但现在的浏览器几乎都提供了取消javascript支持的选项，也就是说，客户端提交的信息可能根本就没有经过检测就被提交给服务器了。这个时候你那节省下来的服务器资源在安全性面前就显得微不足道了，所以说客户端和服务器端的验证都需要，甚至你在客户端可以没有任何验证，服务器端都必须有验证。 这同样适合于处理站外提交的信息。站外提交也可以跳过客户端验证的，最简单的做法就是右键查看你的表单源码，复制到本地，把action的值改成网络地址，然后去掉客户端验证的内容。即使他能够躲过你的站外提交检测代码，也无法跳过服务器端的验证。当然，如果他提交的内容没问题，很正常，那站外提交的东西保存也就保存了——可是，如果是这样，他还搞这么复杂干什么呢？ 五、总结。 事实上所有asp可能出现的问题都和一个问题有关，那就是错误。要么是程序写法上出现的错误，要么是客户端提交错误参数导致的错误。ASP有一个错误处理机制，建议大家写到每页都要包含进去的那个页面里，就是on error resume next，忽略错误继续执行，哪怕错误导致页面什么也显示不出来，它也不会向客户端透露一点错误的内容，有了它能解决不少问题。但最终ASP的安全还是要靠程序员的细心，对于每个可能出现问题的地方都加以处理，这样的程序才会变得安全。 本文参考了atmo相关文章的很多内容，在此向atmo表示感谢！如果有什么错漏之处，还希望各位指出！ 大家可以多参考下网站上发布的一些webshell攻击与防范的文章。
