不管你相不相信，通过 asp，可能可以很方便地入侵 web server、窃取服务器上的文件、捕获 web 数据库等全面的用户口令，甚至恶意删除服务器上的的文件，直至造成系统损坏，这些都决非骇人听闻，而且都确的确实发生过，本文将向你一一揭示这些 asp 存在的漏洞，并提出一些防范意见。

　　上一篇中给大伙着重谈了“ADO 存取数据库时如何分页显示”的问题，有位哥们来信给我指出我在计算页面总数时忽略了 Recordset 对象的一个重要参数“PageCount”，它能在给 Pagesize 赋值后自动得出页面的总数，而无须用“INT(RS.recordcount/PgSz*-1)*-1”这样繁琐的公式。我要感谢这位哥们热心地给我指出程序中的不足，由于这个程序是我在很久以前写的，因为在分页显示的时候记录的总数不一定能整除页面显示记录的数目，而那时我又不能肯定 PageCount 是否能正确得出页面的数目，所以偷懒写了这个公式：），说实话我到现在还都没试过用 pagecount，感兴趣的朋友千万要试一下哦，可别学我的懒惰呀。

　　最近我在 chinaasp 的 bbs 上讨论问题时发现许多朋友对于 asp 的一些安全性问题不甚了解，甚至不晓得如何解决最常见的 asp::$DATA 显示源代码的问题，因此我认为特别有必要在这里给广大朋友们重点谈一谈这个问题，在征得 chinaasp 飞鸟的同意下，我将他曾经写过的一点关于 asp 漏洞的介绍加上我自己的一些实践经验拿出来给大伙详细研究一下这个对于 webmaster 来说非常重要的 asp 的安全性问题。

　　当去年 ::$DATA 的漏洞被发现并公布的第贰天，我曾经检测了当时国内大部分运用 asp 的站点，其中百分之九十九都存在以上可以看见源代码的问题，当日我甚至在微软的站点上抓下了 search.asp 这个文件的源代码。可能你会觉得看到源代码并没有啥大碍，如果作为 webmaster 的你这么想就大错特错了。譬如，如果 asp 程序员将站点的登陆密码直接写在 asp 里，那么一旦源码被发现，他人就可以很容易的进入本不该被看到的页面，我就曾经利用这个方法免费成了一个收费网站的成员（大家可别揭发我哦！），而且很多数据库的连接用户名和密码也都是直接写在 asp 里，一旦被发现，假如你的数据库允许远程访问而且没有设防的话就相当危险了。在一些用 asp 开发的 bbs 程序中，往往使用的是 access mdb 库，如果 mdb 库存放的路径被获知，数据库就很有可能被他人下载，加之如果数据库里含有的密码不加密，那就非常危险了，获取密码的人如果有意进行恶意破坏，他只需要以 admin 身份登陆删除所有 bbs 里的帖子，就够你呛的了。下面列出了目前已经发现的一些漏洞，但愿大家提高警觉一、经过实验我们发现， win95+pws 上运行 ASP 程序，只须简单地在浏览器地址栏的 asp 文件名后多加一个小数点 ASP 程序就会被下载下来。 IIS3 也存在同样的问题，假如你目前还在使用 IIS3 务必要测试一下。
　　二、 iis2、 iis3、 iis4 的一个广为人知的漏洞就是 ::$DATA，通过它使用 ie 的 view source 或 netscape 直接访问该 asp 文件就能吹灰之力地看到 asp 代码。 win98+pws4 不存在这个漏洞。

　　究竟是啥原因造成了这种可怕的漏洞呢？究其根源实际上就是 Windows NT 特有的文件系统在做怪。有一点常识的人都明白在 NT 提供了一种完全不同于 FAT 的文件系统： NTFS，这种被称之为新技术文件全面的技术使得 NT 具有了较高的安全机制，但也正是因为它而发生了很多令人头痛的定 时炸弹。大家可能不晓得， NTFS 支持包含在一个文件中的多数据流，而这个包含了所有内容的主数据流被称之为“DATA”，因此使得在浏览器里直接访问 NTFS 全面的这个特性而轻易的捕获在文件中的脚本程序成了可能。然而直接造成 ::$DATA 的起因是由于 IIS 在解析文件名的时候出了事情，它没有很好地规范文件名。
　　我们该如何解决这个问题呢？办法有几种：

　　a、是将 .asp 文件存放的目录设置为不可读（ASP 仍能执行），这样 html、 css 等文件就不能放在这个目录下，不然它们将不能被浏览。

　　b、是安置微软提供的补丁程序，下载的地址如下（注意针对不一样的系统有不同样的补丁）：

　　该补丁是针对 IIS3， Intel 平台

　　ftp.microsoft.com/bussys/iis/iis-public/fixes/cht/security/iis3-datafix/iis3fixi.exe

　　该补丁是针对 IIS3， Intel 平台

　　ftp.microsoft.com/bussys/iis/iis-public/fixes/cht/security/iis3-datafix/iis3fixa.exe

　　该补丁是针对 IIS4， Alpha 平台

　　ftp.microsoft.com/bussys/iis/iis-public/fixes/cht/security/iis4-datafix/iis4fixi.exe

　　该补丁是针对 IIS4， Alpha 平台

　　ftp.microsoft.com/bussys/iis/iis-public/fixes/cht/security/iis4-datafix/iis4fixa.exe

　　c、是在服务器上安置 ie4.01sp1，这个是否有效，作者我没具体试过。

　　d、存粹作者的个人意见，尽量安置英文版的 NT，而不要使用中文版，究其原因作者也说不清，只是根据实践经验英文版的 NT 较中文版 bug 少，如果哪位哥们知道原因千万要告知我。

　三 . 支持 ASP 的免费主页空间和虚拟主机服务的服务器面临的困扰

　　1、服务器上的 ASP 代码很可能被人其它拥有 asp 权限的人非法获取。

　　举个很容易的案例，在微软提供的 ASP1.0 的例程里有一个 .asp 文件专门用来查看其它 .asp 文件的源代码，该文件为 ASPSamp/Samples/code.asp。假如有人把这个程序上传的服务器，而服务器端没有任何防范措施的话，他就可以很容易地查看他人的程序。
　　例如 :

　　code.asp?source=/directory/file.asp

　　2、使用的 ACCESS mdb 数据库可能被人下载一般来说在提供 asp 权限的免费主页服务器上不会提供代为设定 DSN 的服务，因此 asp 程序使用的数据库通常都局限在使用 mdb 库，而 mdb 远端数据库所在的位置是使用我们在第十四期中讲到过的 DSN-less 方法直接在 asp 中指定的，方法如下 :

　　 < %connstr = "DBQ="+server.mappath("database/source.mdb")+";DefaultDir=;DRIVER={Microsoft Access Driver (*.mdb)};DriverId=25;FIL=MS Access;ImplicitCommitSync=Yes;MaxBufferSize=512;MaxScanRows=8;PageTimeout=5; SafeTransactions=0;Threads=3;UserCommitSync=Yes;"%>
　　正如前文所言，在这种情景下 mdb 库很可能被他人下载，从而造成诸如密码等的泄露。

　　因此，作为 webmaster 应该采取一定的措施，严禁 code.asp 之类的程序（似乎很难办到 , 但可以定期检索特征代码），限制 mdb 的下载。

　　3、来自强大的 filesystemobject 组件的要挟

　　IIS3、 IIS4 的 ASP 的文件操作都能通过 filesystemobject 实现，包含文本文件的读写目录操作、文件的拷贝改名删除等，可是这个强大的功能也留下了非常危险的“后门”。利用 filesystemobjet 可以篡改下载 fat 分区上的任何文件。即便是 ntfs 分区，如果权限没有设定好的话，同样也能破坏，一不小心你就可能遭受“弥天大祸”。遗憾的是很多 webmaster 只知道让 web 服务器运行起来，很少对 ntfs 进行权限设置，而 NT 目录权限的默认设置偏偏安全性又低得可怕。因此，假如你是 Webmaster，作者强烈推荐你高度关注服务器的设置，尽量将 web 目录建在 ntfs 分区上，目录不要设定 everyone full control，即便是是管理员组的成员一般也没啥必要 full control，只要有读取、更改权限就足以。
　　四、 ASP 应用程序可能面临的攻击过去许多 Internet 上 CGI 写的留言本或 BBS 是把客户输入的留言变为一个变量，然后再把这个变量插入到显示留言的 HTML 文件里，因此客户输入的文本如要在 HTML 文件里显示就得符合 HTML 标准，而 CGI 程序里通常都加入了特定的 HTML 语言。当客户输入内容，插入 HTML 文件时，即同时插入到了头尾 HTML 语句中，如：

　　 < font> 客户输入的变量 < /font> 但如果把前后的 HTML 标记给敝屏了，就可以做很多事情了。

　　如输入时打上：

　　 < /font> 符合 HTML 标准的语句 < font> 前后的 < font> 是用来敝屏 CGI 中的 HTML 语句用的。插入到 HTML 文件里的就变成了：

　　 < font>< /font> 符合 HTML 标准的语句 < font>< /font> 由于这样一个特性，使得写个 javascript 的死循环变得非常容易，只要在输入框中输入：

　　< a href="URL" > 或 < a herf="URL" onMousever="while(ture){window.close('/')}"> 那么就能让其它查看该留言的顾客的浏览器因死循环而死掉。 ASP 开发的程序同样可能存在这个问题，因此当你用 asp 编写类似程序时应该做好对此类操作的防范，譬如可以写一段程序判断客户端的输入，并屏蔽掉所有的 HTML、 javascript 语句。

　　看完本期后，假如你非常的震惊，那么你务必完全对你现有的网站或 asp 程序进行一翻检测，瞧瞧是否存在上述漏洞。假如你对文中所谈到的漏洞都有所了解并已经有充分的对策，那么在恭喜你的同时，还是要提醒你我们时常查看你的网站和 asp 程序，假如你有数据库也应该我们时常查看，以防他人利用一些我们未知的漏洞进行攻击。最后，假如你对本文所表达的 asp 安全性问题有啥独特的见解，或对漏洞有新的发现，期待能来信同我探讨。