ASP文件中的安全问题
浅谈ASP的安全问题
先说句牢骚话，我经常看到有人说ASP不安全，比如容易被注入，这种说法我一直感到无法理解。如果你水平不高，那么你用php用ASP.net用JSP都有被注入的可能，这关ASP什么事？ASP只是一种技术，用它开发的网站是否安全，只跟程序员和服务器管理员的水平有关系，任何技术开发的网站都一样。只要你的程序有漏洞，而且你用的数据库支持标准SQL语法，或者注入者会这种语法，那么就存在被注入的可能。
闲话少说，我今天结合我个人的经验来简单说说ASP中常见的安全问题。
一，注入。无论什么时候讲到网站的安全问题，SQL注入都是首当其冲的。我们先来看看SQL注入是怎么回事。简单的说，SQL注入就是通过各种方式传递非法的参数，其方式和目的无法是以下几种：
·期望程序出错，从而从服务器返回的错误信息中获得一些注入者想要的东西，这种方法常用来判断数据库的类型。
·执行特殊语句，用来猜解表名等。
·构造特殊语句，这个常常就是用来绕过登录检测取得管理权限的。
针对以上问题，我一般采用以下的应对方法：
·前面两种情况应该一起考虑。无论是哪种注入方式，其实都是通过构造非法的参数来实现的，那么我们就通过程序来限制参数，给合法的参数制定一个规则，不符合这个规则的就是非法的。但在检测时经常见出现下面的错误：
1，用isnumeric函数来检测id。这个函数仅仅是判断是否是数字，仅此而已，那么如果我这样输入一个url：shownews.asp?id=1.1，那么也会通过检测，因为1.1也是数字，或者id=0也行。有这样的id吗？没有，任何数据库表中的id都是从1开始的正整数。所以请大家不要这样再使用它来检测id的合法性。那用什么呢？这里就要用到正则表达式了。
可以通过id=cint(request("id"))或clng，或者就是用正则表达式替换所有的非数字字符，这样就只有数字了。（asp下替换非数字为空的正则）
2，缺少错误处理，或错误处理不完善。比如rs.eof的情况，不加处理的话，我写个id=999999999999999，那么程序就会出错，我相信绝少有哪个网站有如此大的id，即使有我还可以换个更大的。我曾经就遇到过有人用工具连续试探我的id，从8000测试到10000多。还有就是type参数，一般网站的新闻都会分好几个栏目，这时都依靠type来确定每个列表页面该显示哪个栏目的内容，如果有人提交一个不存在的type值呢？这也需要处理，select case中的case else子句就是为这种意外情况准备的，别为了省事不去用它。
·绕过登录检测的问题大多数是因为程序员把登录检测语句写成这样：
代码如下:
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攻击与防范的文章。
