ASP网站开发安全手册

一前言

Microsoft Active Server Pages（ASP）是服务器端脚本编写环境，使用它可以创建和运行动态、交互的Web 服务器应用程序。使用ASP 可以组合HTML 页、脚本命令和ActiveX 组件以创建交互的Web 页和基于Web 的功能强大的应用程序。

现在很多网站特别是电子商务方面的网站，在前台上大都用ASP来实现。以至于现在ASP在网站应用上很普遍。

ASP是开发网站应用的快速工具，但是有些网站管理员只看到ASP的快速开发能力，却忽视了ASP安全问题。ASP从一开始就一直受到众多漏洞，后门的困扰，包括%81的噩梦，密码验证问题，IIS漏洞等等都一直使ASP网站开发人员心惊胆跳。

本文试图从开放了ASP服务的操作系统漏洞和ASP程序本身漏洞，阐述ASP安全问题，并给出解决方法或者建议。

二关键字

ASP，网络安全，IIS，SSL，加密。

三ASP工作机理

Active Server Page技术为应用开发商提供了基于脚本的直观、快速、高效的应用开发手段，极大地提高了开发的效果。在讨论ASP的安全性问题之前，让我们来看看ASP是怎么工作的。ASP脚本是采用明文（plain text）方式来编写的。

ASP脚本是一系列按特定语法（目前支持vbscript和jscript两种脚本语言）编写的，与标准HTML页面混合在一起的脚本所构成的文本格式的文件。当客户端的最终用户用WEB浏览器通过INTERNET来访问基于ASP脚本的应用时，WEB浏览器将向WEB服务器发出HTTP请求。WEB服务器分析、判断出该请求是ASP 脚本的应用后，自动通过ISAPI接口调用ASP脚本的解释运行引擎（ASP.DLL）。ASP.DLL将从文件系统或内部缓冲区获取指定的ASP脚本文件，接着就进行语法分析并解释执行。最终的处理结果将形成HTML格式的内容，通过WEB服务器“原路”返回给WEB浏览器，由WEB浏览器在客户端形成最终的结果呈现。这样就完成了一次完整的ASP脚本调用。若干个有机的ASP脚本调用就组成了一个完整的ASP 脚本应用。

让我们来看看运行ASP所需的环境：

Microsoft Internet Information Server 3.0/4.0/5.0 on NT Server

Microsoft Internet Information Server 3.0/4.0/5.0 on Win2000

Microsoft Personal Web Server on Windows 95/98

WINDOWS NT Option Pack所带的Microsoft IIS提供了强大的功能，但是IIS在网络安全方面却是比较危险的。因为很少有人会用Windows 95/98当服务器，因此本文我更多的从NT中的IIS安全问题来探讨。

四微软自称的ASP的安全优点

虽然我们本文的重点是探讨ASP漏洞和后门，但是有必要谈谈ASP在网络安全方面的“优点”，之所以加个“”，是因为有时这些微软宣称的“优点”恰恰是其安全隐犯。

微软称ASP在网络安全方面一大优点就是用户不能看到ASP的源程序，

从ASP的原理上看，ASP在服务端执行并解释成标准的HTML语句，再传送给客户端浏览器。“屏蔽”源程序能很好的维护ASP开发人员的版权，试想你辛辛苦苦做了一个很优秀的程序，给人任意COPY，你会怎么想？而且黑客还能分析你的ASP程序，挑出漏洞。更重要的是有些ASP开发者喜欢把密码，有特权的用户名和路径直接写在程序中，这样别人通过猜密码，猜路径，很容易找到攻击系统的“入口”。但是目前已经发现了很多能查看ASP源程序的漏洞，后面我们还要讨论。

IIS支持虚拟目录，通过在“服务器属性”对话框中的“目录”标签可

以管理虚拟目录。建立虚拟目录对于管理WEB站点具有非常重要的意义。虚拟目录隐藏了有关站点目录结构的重要信息。因为在浏览器中，客户通过选择“查看源代码”，很容易就能获取页面的文件路径信息，如果在WEB页中使用物理路径，将暴露有关站点目录的重要信息，这容易导致系统受到攻击。其次，只要两台机器具有相同的虚拟目录，你就可以在不对页面代码做任何改动的情况下，将WEB页面从一台机器上移到另一台机器。还有就是，当你将WEB页面放置于虚拟目录下后，你可以对目录设置不同的属性，如：Read、Excute、Script。读访问表示将目录内容从IIS传递到浏览器。而执行访问则可以使在该目录内执行可执行的文件。当你需要使用ASP时，就必须将你存放.asp文件的目录设置为“Excute（执行）”。建议大家在设置WEB站点时，将HTML文件同ASP文件分开放置在不同的目录下，然后将HTML子目录设置为“读”，将ASP子目录设置为“执行”，这不仅方便了对WEB的管理，而且最重要的提高了ASP程序的安全性，防止了程序内容被客户所访问。

五ASP漏洞分析和解决方法

有人说一台不和外面联系的电脑是最安全的电脑，一个关闭所有端口，不提供任何服务的电脑也是最安全的。黑客经常利用我们所开放的端口实施攻击，这些攻击最常见的是DDOS（拒绝服务攻击）.下面我会列出ASP的二十几个漏洞，每个漏洞都会有漏洞描述和解决方法。

1 在ASP程序后加个特殊符号，能看到ASP源程序

受影响的版本：

win95+pws

IIS3.0

98+pws4 不存在这个漏洞。

IIS4.0以上的版本也不存在这个漏洞。

问题描述：

这些特殊符号包括小数点，%81, ::$DATA。比如：

http://someurl/somepage.asp.

http:// someurl/somepage.asp%81

http:// someurl/somepage.asp::$DATA

http:// someurl/somepage.asp %2e

http:// someurl/somepage %2e%41sp

http:// someurl/somepage%2e%asp

http:// someurl/somepage.asp %2e

http://someurl/msadc/samples/selector/showcode.asp?source=/msadc/samples/../../../../../../ boot.ini （可以看到boot.ini的文件内容）

那么在安装有IIS3.0和win95+PWS的浏览中就很容易看到somepage.asp的源程序。究竟是什么原因造成了这种可怕的漏洞呢？究其根源其实是Windows NT 特有的文件系统在做怪。有一点常识的人都知道在NT 提供了一种完全不同于FAT 的文件系统：NTFS，这种被称之为新技术文件系统的技术使得NT 具有了较高的安全机制，但也正是因为它而产生了不少令人头痛的隐患。大家可能不知道，NTFS 支持包含在一个文件中的多数据流，而这个包含了所有内容的主数据流被称之为“DATA”，因此使得在浏览器里直接访问NTFS 系统的这个特性而轻易的捕获在文件中的脚本程序成为了可能。然而直接导致::$DATA 的原因是由于IIS 在解析文件名的时候出了问题，它没有很好地规范文件名。

解决方法和建议：

如果是Winodws NT用户，安装IIS4.0或者IIS5.0，Windows2000不存在这个问题。如果是win95用户，安装WIN98和PWS4.0。

2 ACCESS mdb 数据库有可能被下载的漏洞

问题描述：

在用ACCESS做后台数据库时，如果有人通过各种方法知道或者猜

到了服务器的ACCESS数据库的路径和数据库名称，那么他能够下载这个ACCESS数据库文件，这是非常危险的。比如：如果你的ACCESS数据库book.mdb 放在虚拟目录下的database目录下，那么有人在浏览器中打入：

http:// someurl/database/book.mdb

如果你的book.mdb数据库没有事先加密的话，那book.mdb中所有重要

的数据都掌握在别人的手中。

解决方法：

(1) 为你的数据库文件名称起个复杂的非常规的名字，并把他放在几目

录下。所谓“非常规”，打个比方：比如有个数据库要保存的是有关书籍的信息，可不要把他起个“book.mdb”的名字，起个怪怪的名称，比如d34ksfslf.mdb，再把他放在如./kdslf/i44/studi/ 的几层目录下，这样黑客要想通过猜的方式得到你的ACCESS数据库文件就难上加难了。

(2)不要把数据库名写在程序中。有些人喜欢把DSN写在程序中，比如：

DBPath = Server.MapPath("cmddb.mdb")

conn.Open "driver={Microsoft Access Driver (*.mdb)};dbq=" amp; DBPath

假如万一给人拿到了源程序，你的ACCESS数据库的名字就一览无余。因此建议你在ODBC里设置数据源，再在程序中这样写：

conn.open “shujiyuan”

(3)使用ACCESS来为数据库文件编码及加密。首先在选取“工具-＞安

全-＞加密/解密数据库，选取数据库（如：employer.mdb），然后接确定，接着会出现”数据库加密后另存为“的窗口，存为：employer1.mdb。接着employer.mdb就会被编码，然后存为employer1.mdb..

要注意的是，以上的动作并不是对数据库设置密码，而只是对数据库文件加以

编码，目的是为了防止他人使用别的工具来查看数据库文件的内容。

接下来我们为数据库加密，首先以打开经过编码了的employer1.mdb，在打开时，选择“独占”方式。然后选取功能表的“工具-＞安全-＞设置数据库密码”，接着输入密码即可。

为employer1.mdb设置密码之后，接下来如果再使用ACCEES数据库文件时，则ACCESS会先要求输入密码，验证正确后才能够启动数据库。

不过要在ASP程序中的connection对象的open方法中增加PWD的参数即可，例如：

param=”driver={Microsoft Access Driver (*.mdb)};Pwd=yfdsfs”

param=paramamp;”;dbq=”server.mappath(“employer1.mdb”)

conn.open param

这样即使他人得到了employer1.mdb文件，没有密码他是无法看到employer1.mdb的。

3 code.asp文件会泄漏ASP代码

问题描述：

举个很简单的例子，在微软提供的ASP1.0 的例程里有一个.asp 文件

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

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

不过这是个比较旧的漏洞了，相信现在很少会出现这种漏洞。

下面这命令是比较新的：

http://someurl/iissamples/exair/howitworks/code.asp?/lunwen/soushuo.asp=xxx.asp 最大的危害莫过于asa文件可以被上述方式读出；数据库密码以明文形式暴露在黑客眼前;

问题解决或建议：

对于IIS自带的show asp code的asp程序文件，删除该文件或者禁止访问该目录即可

4、filesystemobject 组件篡改下载fat 分区上的任何文件的漏洞

问题描述：

IIS3、IIS4 的ASP 的文件操作都可以通过filesystemobject 实现，包括文本文件的读写目录操作、文件的拷贝改名删除等，但是这个强大的功能也留下了非常危险的“后门”。利用filesystemobjet 可以篡改下载fat 分区上的任何文件。即使是ntfs 分区，如果权限没有设定好的话，同样也能破坏，一不小心你就可能遭受“灭顶之灾”。遗憾的是很多webmaster 只知道让web 服务器运行起来，很少对ntfs 进行权限设置，而NT 目录权限的默认设置偏偏安全性又低得可怕。因此，如果你是Webmaster

，建议你密切关注服务器的设置，尽量将web 目录建在ntfs 分区上，目录不要设定everyone full control，即使是是管理员组的成员一般也没什么必要full control，只要有读取、更改权限就足够了。也可以把filesystemobject的组件删除或

者改名。

5、输入标准的HTML语句或者javascript语句会改变输出结果

问题描述：

在输入框中打入标准的HTML语句会得到什么相的结果呢？

比如一个留言本，我们留言内容中打入：

＜font size=10＞你好！＜/font＞

如果你的ASP程序中没有屏蔽html语句，那么就会改变“你好”字体的大小。在留言本中改变字体大小和贴图有时并不是什么坏事，反而可以使留言本生动。但是如果在输入框中写个javascript 的死循环，比如：＜a herf="http://someurl" onMouseover="while(1){window.close('/')}"＞特大新闻＜/a＞

那么其他查看该留言的客人只要移动鼠标到”特大新闻”，上就会使用户的浏览器因死循环而死掉。

解决方法和建议：

编写类似程序时应该做好对此类操作的防范，譬如可以写一段程序判断客户端的输入，并屏蔽掉所有的HTML、Javascript 语句。

6、ASP程序密码验证漏洞

漏洞描述：

很多网站把密码放到数据库中，在登陆验证中用以下sql,(以asp为例）

sql="select * from user where username='"amp;usernameamp;"'and pass='"amp; pass amp;'"

此时，您只要根据sql构造一个特殊的用户名和密码，如：ben' or '1'='1

就可以进入本来你没有特权的页面。再来看看上面那个语句吧：

sql="select * from user where username='"amp;usernameamp;"'and pass='"amp; passamp;'"

此时，您只要根据sql构造一个特殊的用户名和密码，如：ben' or '1'='1 这样,程序将会变成这样: sql="select*from username where username="ben'or'1'=1amp;"and pass="amp;passamp;"

or 是一个逻辑运算符,作用是在判断两个条件的时候,只要其中一个条件成立,那么等式将会成立.而在语言中,是以1来代表真的(成立).那么在这行语句中,原语句的"and"验证将不再继续,而因为"1=1"和"or"令语句返回为真值.。

另外我们也可以构造以下的用户名：

username='aa' or username＜＞'aa'

pass='aa' or pass＜＞'aa'

相应的在浏览器端的用户名框内写入：aa' or username＜＞'aa

口令框内写入：aa' or pass＜＞'aa,注意这两个字符串两头是没有'的。

这样就可以成功的骗过系统而进入。

后一种方法理论虽然如此，但要实践是非常困难的，下面两个条件都必须具备。

1. 你首先要能够准确的知道系统在表中是用哪两个字段存储用户名和口令的，只有这样你才能准确的构造出这个进攻性的字符串。实际上这是很难猜中的。

2.系统对你输入的字符串不进行有效性检查。

问题解决和建议：

对输入的内容验证和“’”号的处理。

7、IIS4或者IIS5中安装有INDEX SERVER服务会漏洞ASP源程序

问题描述：

在运行IIS4或者IIS5的Index Server，输入特殊的字符格式可以看到ASP源程序或者其它页面的程序。甚至以及添打了最近关于参看源代码的补丁程序的系统，或者没有.htw文件的系统，一样存在该问题。获得asp程序，甚至global.asa文件的源代码，无疑对系统是一个非常重大的安全隐患。往往这些代码中包含了用户密码和ID，以及数据库的源路径和名称等等。这对于攻击者收集系统信息，进行下一步的入侵都是非常重要的。

通过构建下面的特殊程序可以参看该程序源代码：

http://202.116.26.38/null.htw?CiWebHitsFile=/default.aspamp;CiRestriction=noneamp;Ci HiliteType=Full

这样只是返回一些html格式的文件代码，但是当你添加%20到CiWebHitsFile 的参数后面，如下:

http://someurl/null.htw?CiWebHitsFile=/default.asp%20amp;CiRestriction=noneamp;Ci HiliteType=Full

这将获得该程序的源代码。

（注意：/default.asp是以web的根开始计算。如某站点的http:///welcome/welcome.asp

那么对应就是：

http://someurl/null.htw?CiWebHitsFile=/welcome/welcome.asp%20amp;CiRestriction=n oneamp;CiHiliteType=Full

)

由于'null.htw'文件并非真正的系统映射文件，所以只是一个储存在系统内存中的虚拟文件。哪怕你已经从你的系统中删除了所有的真实的.htw文件，但是由于对null.htw文件的请求默认是由webhits.dll来处理。所以，IIS仍然收到该漏洞的威胁。

问题解决或者建议：

如果该webhits提供的功能是系统必须的，请下载相应的补丁程序。如果没必要，请用IIS的MMC管理工具简单移除.htw的映象文件。

补丁程序如下：

Index Server 2.0:

Intel:

https://www.wendangku.net/doc/6b7165491.html,/downloads/release.asp?ReleaseID=17727

Alpha:

https://www.wendangku.net/doc/6b7165491.html,/downloads/release.asp?ReleaseID=17728

Indexing Services for Windows 2000:

Intel:

https://www.wendangku.net/doc/6b7165491.html,/downloads/release.asp?ReleaseID=17726

解决方案

运行Regedt32.exe

在：

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w3svc\parameters

增加一个值：

Value Name: MaxClientRequestBuffer

Data Type: REG_DWORD

设置为十进制

具体数值设置为你想设定的IIS允许接受的URL最大长度。

CNNS的设置为256

18、MS ODBC数据库连接溢出导致NT/9x拒绝服务攻击

漏洞描述:

Microsoft ODBC数据库在连接和断开时可能存在潜在的溢出问题(Microsoft ACCESS数据库相关)。

如果不取消连接而直接和第二个数据库相连接，可能导致服务停止。

影响系统:

ODBC 版本: 3.510.3711.0

ODBC Access驱动版本: 3.51.1029.00

OS 版本: Windows NT 4.0 Service Pack 5, IIS 4.0 (i386)

Microsoft Office 97 Professional (MSO97.dll: 8.0.0.3507)

漏洞检测方法如下:

ODBC 连接源名称: miscdb

ODBC 数据库型号: MS Access

ODBC 假设路径: d:\data\misc.mdb

ASP代码如下:

...lots of html removed...

在这种情况下，IIS处理进程将会停顿，CPU使用率由于inetinfo.exe进程将达到100%。只有重新启动计算机才能恢复。

19、ASP主页.inc文件泄露问题

漏洞描述：

受影响的版本:任何提供ASP服务的系统

远程:YES / 本地:YES

内容摘要:

当存在asp的主页正在制作并没有进行最后调试完成以前，可以被某些搜索引擎机动追加为搜索对象，如果这时候有人利用搜索引擎对这些网页进行查找，会得到有关文件的定位，并能在浏览器中察看到数据库地点和结构的细节揭示完整的源代码。具体操作过程是：

- 利用搜索引擎查找包含+"Microsoft VBScript 运行时刻错误执行搜索" +".inc ，" 的关键字

- 搜索引擎会自动查找包含asp的包含文件(.inc)并显示给用户

- 利用浏览器观看包含文件的源代码，其中可能会有某些敏感信息

漏洞的利用:

例子:

- https://www.wendangku.net/doc/6b7165491.html,/inc/lib/prep.lib

暴露数据库连接和性质, 资源地点, 小甜饼逻辑,服务器IP 地址

- https://www.wendangku.net/doc/6b7165491.html,/SFLib/ship.inc

暴露数据库性质

- https://www.wendangku.net/doc/6b7165491.html,:8013/includes/general.inc

暴露cobranding

- https://www.wendangku.net/doc/6b7165491.html,/corporate/admin/include/jobs.inc

暴露datafile 地点和结构

- https://www.wendangku.net/doc/6b7165491.html,/SFLib/design.inc

包括数据库结构为StoreFront 2000 暴露源代码

- https://www.wendangku.net/doc/6b7165491.html,/scripts/IsSearchEngine.inc

暴露搜索引擎记录文件

- https://www.wendangku.net/doc/6b7165491.html,/include/functions.inc

暴露成员电子邮件地址

- https://www.wendangku.net/doc/6b7165491.html,/flat/comments.txt

暴露成员私人的注释文件

- https://www.wendangku.net/doc/6b7165491.html,/two/cookies.inc

暴露cookie 逻辑

解决方案:

- 搜索引擎应该不索引有asp 运行时刻错误的页

- 程序员应该在网页发布前对其进行彻底的调试

- 安全专家需要固定asp 包含文件以便外部的用户不能看他们

asp 新闻组、站点提供两个解决方案对这个漏洞进行修正，首先对.inc 文件内容进行加密，其次也可以使用.asp 文件代替.inc 文件使用户无法从浏览器直接观看文件的源代码。.inc 文件的文件名不用使用系统默认的或者有特殊含义容易被用户猜测到的，尽量使用无规则的英文字母。

20、利用Activer server explorer可对文件进行读写访问

漏洞描述：

chinaasp的Activer server explorer可以很方便的对本地文件在线查看服务器上的目录在线查看文件的名称、大小、类型、修改时间,在线编辑纯文本文件，如.txt、.htm、.asp、.pl、.cgi等等,直接执行服务器上的文件。

Activer server explorer要求填写相对路径或者绝对路径，但是假如：有一个攻击者把Activer server explorer上传到目标服务器上的某个目录，并且这个目录支持ASP的话，那么他就可以通过Activer server explorer修改、执行目标服务器上的文件。这种情况可以发生在一个攻击者拥有目标NT服务器上的一个可写目录帐号，并且这个目录又支持ASP。比如一些支持ASP的个人免费主页服务器，把Activer server explorer先传上你申请的免费主页空间，再通过各种方法得到目标服务器的路径，(比如可通过漏洞：“请求不存在的扩展名为idq或ida 文件，会暴露文件在服务器上的物理地址.”).或者直接在相对路径上填”.”，一般是默认。这样攻击者就能任意修改，执行目标服务器上的文件，不管他对这个文件有无读写访问权。

所以那些提供有ASP服务的个人主页或者其它服务的服务器，就要加倍小心这种攻击了。

漏洞解决方法

其实Activer server explorer就是利用了上面讲的漏洞4filesystemobject 组件篡改下载fat 分区上的任何文件的漏洞。

那么我们如何才能限制用户使用FileSystemObject对象呢？一种极端的做法是完全反注册掉提供FileSystemObject对象的那个组件，也就是Scrrun.dll。具体的方法如下：

在MS－DOS状态下面键入：

Regsvr32 /u c:\windows\system\scrrun.dll

（注意：在实际操作的时候要更改成为你本地的实际路径）

但是这样的话，就不能使用FileSystemObject对象了，有时利用FileSystemObject 对象来管理文件是很方便，有什么办法能两全其美呢？

我们可以做到禁止他人非法使用FileSystemObject对象,但是我们自己仍然可以使用这个对象.

方法如下:

查找注册表中

HKEY_CLASSES_ROOT\Scripting.FileSystemObject 键值

将其更改成为你想要的字符串(右键-->"重命名"),比如更改成为

HKEY_CLASSES_ROOT\Scripting.FileSystemObject2

这样,在ASP就必须这样引用这个对象了:

Set fso = CreateObject("Scripting.FileSystemObject2")

而不能使用:

Set fso = CreateObject("Scripting.FileSystemObject")

如果你使用通常的方法来调用FileSystemObject对象就会无法使用了。

只要你不告诉别人这个更改过的对象名称，其他人是无法使用FileSystemObject 对象的。这样，作为站点管理者我们就杜绝了他人非法使用FileSystemObject对象，而我们自己仍然可以使用这个对象来方便的实现网站在线管理等等功能了！

21 IIS4.0/IIS5.0超长文件名请求存在漏洞

漏洞描述：

受影响的版本:

Microsoft IIS 5.0

+ Microsoft Windows NT 2000

Microsoft IIS 4.0

+ Microsoft Windows NT 4.0

+ Microsoft BackOffice 4.5

- Microsoft Windows NT 4.0

+ Microsoft BackOffice 4.0

- Microsoft Windows NT 4.0

当在一个已知的文件名后加230个"%20"再加个.htr，会使安装有Microsoft IIS 4.0/5.0泄漏该文件的内容。这是由ISM.dll映射的.htr文件引起的.比如：

http://target/filename%20<重复230次>.htr

这种请求只有当.htr请求是第一次调用或者ISM.dll第一次装载进内存，才能起作用。

解决方法：

安装补丁

Microsoft IIS 5.0:

https://www.wendangku.net/doc/6b7165491.html,/download/win2000platform/Patch/Q249599/NT5/EN-US/ Q249599_W2K_SP1_X86_en.EXE

Microsoft IIS 4.0:

https://www.wendangku.net/doc/6b7165491.html,/download/iis40/Patch/Q260838/NT4ALPHA/EN-US/ism pst4i.exe

22ASP编辑器会自动备份asp文件，会被下载的漏洞

漏洞描述：

在有些编辑asp程序的工具，当创建或者修改一个asp文件时，编辑器自动创建一个备份文件，比如：UltraEdit就会备份一个..bak文件，如你创建或者修改了some.asp，编辑器自动生成一个叫some.asp.bak文件，如果你没有删除这个bak文件，攻击有可以直接下载some.asp.bak文件，这样some.asp的源程序就会给下载。

六 ASP安全建议

如何设置才能使ASP更加安全呢？以下我们重点来谈谈ASP安全方面要注意的问题。我们在第五部分“ASP漏洞和解决方法”中针对某些漏洞，也提出了相应的安全建议，这部分就不再重复。

在这部分的后面还要介绍些可扫描ASP漏洞的工具。

1 安装NT最新的补丁

目前最新的补丁是NT Option Pack 6.0.，微软的主页有最新的补丁。一般来说微软都会及时的公布最新的漏洞和补丁。目前IIS最新是5.0。windows2000自带IIS5.0.

IIS 5.0新功能如下：

安全性上：包括摘要式验证、整合的Windows验证、SGC (Server-Gated Cryptography ) 、Microsoft Certificate Services 2.0、集区处理程序之程序保护等。

管理上：包括IIS重新激活、站台CPU使用时间的限制、CPU资源使用记录、使用终端机服务远程管理IIS、自订错误讯息等。

Internet标准上：包括WebDAV(Web Distributed Authoring and Versioning)、FTP 重新激活、HTTP压缩等。

Active Server Pages：包括新的转向方法(Server.Transfer与Server.Execute 方法)、新的错误处理功能(Server.GetLastError方法)、无指令.asp的执行速度增快、可安装组件的效能调升、Scriptlet支持、使用cookie取得浏览器信息、自动增减执行绪(executing threads)、SRC服务器端包含功能、Script Encoder编码保护等。

更具体的功能介绍请参见其它资料。

2 关闭没有用的服务和协议

“尽量少开没用到的服务”，这永远是网络安全的准则。如果开启了某个

服务，你就要面对不少的漏洞困扰，更重要的是你还要时时提防未来的由这个服务所引起的漏洞。

比如，你不使用ftp,那就把FTP关了，不然你就要发费大量的精力

和金钱去应付那些什么DOS，缓冲区溢出之类的漏洞。NETBIOS也是windows的一大安全隐患，我想目前服务器很少需要Netbios。再如你的IIS安装了index server 服务，那你至少要面对三个以上的有关这个服务的漏洞，因此如果你没用到INDEX SERVER服务，也大可删除他.

同样的道理，我们要安装最少的协议。千万不要安装点对点通道

通讯协议。此外，还必须小心地配置TCP/IP协议。在TCP/IP的属性页中选择“IP

地址”项目，然后选择“高级”。在弹出来的对话框中选择“安全机制”，这样你

可以禁止UDP，然后开启IP端口6和TCP端口80。当然开不开这些端口主要是看你的情况了。

IIS中的应用程序映射也是个很大的安全漏洞，请在IIS中设置好扩展名和可执行

路径，删除没用的扩展名。

3 设置好你的NT

NT缺省安装时，系统账号Administrator和Guest被自动设置，很多攻击者就是利用这些账号来猜密码，从而进入你的系统。虽然没有足够的耐心，很难猜中这

些密码，但是为了安全起见，建议把这些账号重新命名或者删除。

NT SERVER的系统策略编辑器非常有用。按“管理工具”－＞“系统策略编辑器”就可以进入，然后选择“文件”－＞“打开注册表”，并选择“本地计算机”图标，就可以认真配置了。主要设置以下几项：

1．取消：网络－＞系统规则更新－＞远程更新

2．取消：WINDOWS NT网络－＞共享－＞创建隐藏的驱动器共享

3．设置：Windows NT远程访问下面的各项

4．设置：Windows NT系统->登录中各个项目。包括设置登录标记;不允许从“身

份验证对话框”关机;不显示上次登录的用户名.

5．设置：WINDOWS NT系统->文件系统中的“不为长文件名创建8.3文件名”

不要使用远程管理软件，除非不得已。由于NT不太支持远程管理，所以你可能会安装Reachout或者PC anywhere来管理。可是，当你安装了这些软件，你就不得不开启TCP/IP的所有端口。

在你离开服务器的时候，请按”Ctrl+del+alt”，并选择“锁定工作站”。

4 磁盘文件格式使用比较安全的NTFS格式。

NTFS 权限是 Web 服务器安全性的基础，它定义了一个或一组用户访问文件和

目录的不同级别。当拥有 Windows NT 有效帐号的用户试图访问一个有权限限制的

文件时，计算机将检查文件的访问控制表 (ACL)。该表定义了不同用户和用户组所被赋予的权限。例如，Web 服务器上的 Web 应用程序的所有者需要有“更改”权限来查看、更改和删除应用程序的 .asp 文件。但是，访问该应用程序的公共用户应

仅被授予“只读”权限，以便将其限制为只能查看而不能更改应用程序的 Web 页。

5 对目录设置不同的属性，如：Read、Excute、Script。

您可以通过配置您的 Web 服务器的权限来限制所有用户查看、运行和操作您的ASP 页的方式。不同于 NTFS 权限提供的控制特定用户对应用程序文件和目录的访

问方式， Web 服务器权限应用于所有用户，并且不区分用户帐号的类型。对于要

运行您的 ASP 应用程序的用户，在设置 Web 服务器权限时，必须遵循下列原则：对包含 .asp 文件的虚拟目录允许“读”或“脚本”权限。

对 .asp 文件和其他包含脚本的文件（如 .htm 文件等）所在的虚目录允许“读”和“脚本”权限。

对包含 .asp 文件和其他需要“执行”权限才能运行的文件（如 .exe 和 .dll 文件等）的虚目录允许“读”和“执行”权限。

6 维护 Global.asa 的安全

为了充分保护 ASP 应用程序，一定要在应用程序的 Global.asa 文件上为适当的用户或用户组设置 NTFS 文件权限。如果 Global.asa 包含向浏览器返回信息的命令而您没有保护 Global.asa 文件，则信息将被返回给浏览器，即便应用程序的其他文件被保护。

7不要把密码，物理路径直接写在程序中。

很难保证您的ASP程序是否会给人拿到，即使你安装了最新的补丁。为

了安全起见，应该把密码和用户名保存在数据库中，使用虚拟路径。

8 在程序中记录用户的详细信息.

这些信息包括用户的浏览器、用户停留的时间，用户IP等。其中

记录IP是最有用的。

可用下面的语句了解客户端和服务端的信息：

:

如果我们可以记录了用户的IP，就能通过追捕来查用户的具体地点。

当然如果用户通过代理来浏览网页，上面的方法只能看到用户代理的IP，而不能记录用户真实的IP。ASP没有提供查看客户端网卡物理地址（即MAC）的功能。

9 Cookie 安全性

ASP 使用 SessionID cookie 跟踪应用程序访问或会话期间特定的 Web 浏览器的信息。这就是说，带有相应的 cookie 的 HTTP 请求被认为是来自同一 Web 浏览器。Web 服务器可以使用 SessionID cookies 配置带有用户特定会话信息的 ASP 应用程序。例如，如果您的应用程序是一个允许用户选择和购买 CD 唱盘的联机音乐商店，就可以用 SessionID 跟踪用户漫游整个应用程序时的选择。

SessionID 能否被黑客猜中？

为了防止计算机黑客猜中 SessionID cookie 并获得对合法用户的会话变量的访问，Web 服务器为每个 SessionID 指派一个随机生成号码。每当用户的 Web 浏览器返回一个 SessionID cookie 时，服务器取出 SessionID 和被赋予的数字，接着检查是否与存储在服务器上的生成号码一致。若两个号码一致，将允许用户访问会话变量。这一技术的有效性在于被赋予的数字的长度（64 位），此长度使计算机黑客猜中 SessionID 从而窃取用户的活动会话的可能性几乎为 0。

加密重要的 SessionID Cookie.

截获了用户 sessionID cookie 的计算机黑客可以使用此 cookie 假冒该用户。如果 ASP 应用程序包含私人信息，信用卡或银行帐户号码，拥有窃取的 cookie 的计算机黑客就可以在应用程序中开始一个活动会话并获取这些信息。您可以通过对您的 Web 服务器和用户的浏览器间的通讯链路加密来防止 SessionID cook ie 被

10使用身份验证机制保护被限制的 ASP 内容

可以要求每个试图访问被限制的 ASP 内容的用户必须要有有效的 Windows NT 帐号的用户名和密码。每当用户试图访问被限制的内容时，Web 服务器将进行身份验证，即确认用户身份，以检查用户是否拥有有效的 Windows NT 帐号。

Web 服务器支持以下几种身份验证方式：

基本身份验证提示用户输入用户名和密码。

Windows NT 请求/响应式身份验证,从用户的 Web 浏览器通过加密方式获取用户身份信息。

然而，Web 服务器仅当禁止匿名访问或 Windows NT 文件系统的权限限制匿名访问时才验证用户身份。

11 保护元数据库

访问元数据库的 ASP 脚本需要 Web 服务器所运行的计算机的管理员权限。在从远程计算机上运行这些脚本时，须经已通过身份验证的连接，如使用 Windows NT 请求/响应验证方式进行连接。应该为管理级 .asp 文件创建一个服务器或目录并将其目录安全验证方式设置为Windows NT 请求/响应式身份验证。目前，仅Microsoft Internet Explorer version 2.0 或更高版本支持 Windows NT 请求响应式身份验证。

12 使用 SSL 维护应用程序的安全

SSL （Secure Sockets Layer）协议是由Netscape首先发表的网络资料安全传输协定,其首要目的是在两个通信间提供秘密而可靠的连接。该协议由两层组成，底层是建立在可靠的传输协议（例如：TCP）上的是SSL的记录层，用来封装高层的协议。SSL握手协议准许服务器端与客户端在开始传输数据前，能够通过特定的加密算法相互鉴别。SSL的先进之处在于它是一个独立的应用协议，其它更高层协议能够建立在SSL协议上。

SSL3.0 协议作为 Web 服务器安全特性，提供了一种安全的虚拟透明方式来建立与用户的加密通讯连接。SSL 保证了 Web 内容的验证，并能可靠地确认访问被限制的Web 站点的用户的身份。

通过 SSL，您可以要求试图访问被限制的 ASP 应用程序的用户与您的服务器建立一个加密连接；以防用户与应用程序间交换的重要信息被截取。

比如好多基于WEB的ASP论坛都会提供注册用户互相发送信息的服务，这种信息是明文传送的，如果在网吧就很容易给人监听到。如果加了一层SSL认证，就会防止发送信息被监听的可能。

13 客户资格认证

控制对您的 ASP 应用程序访问的一种十分安全的方法是要求用户使用客户资格登录。客户资格是包含用户身份信息的数字身份证，它的作用与传统的诸如护照或驾驶执照等身份证明相同。用户通常从委托的第三方组织获得客户资格，第三方组织在发放资格证之前确认用户的身份信息。（通常，这类组织要求姓名、地址、电话号码及所在组织名称；此类信息的详细程度随给予的身份等级而异。）每当用户试图登录到需要资格验证的应用程序时，用户的 Web 浏览器会自动向

服务器发送用户资格。如果 Web 服务器的 Secure Sockets Layer (SSL) 资格映射特性配置正确，那么服务器就可以在许可用户对 ASP 应用程序访问之前对其身份进行确认。

作为 ASP 应用程序开发人员，您可以编写脚本来检查资格是否存在并读取资格字段。例如，您可以从资格证明中访问用户名字段和公司名字段。Active Server Pages 在 Request 对象的 ClientCertificate 集合中保存资格信息。

必须将 Web 服务器配置为接受或需要客户资格，然后才能通过 ASP 处理客户资格；否则，ClientCertificate 集合将为空。

14 ASP的加密

由于ASP脚本是采用明文（plain text）方式来编写的，所以应用开发商辛苦开发出来的ASP应用程序，一旦发布到运行环境中去后，就很难确保这些“源代码”不会被流传出去。这样就产生了如何有效地保护开发出来的ASP脚本源代码的需求。

官方加密程序：从微软免费下载到sce10chs.exe 直接运行即可完成安装过程。安装完毕后，将生成screnc.exe文件，这是一个运行在DOS PROMAPT的命令工具。运行screnc – l vbscript source.asp destination.asp生成包含密文ASP脚本的新文件destination.asp用记事本打开看凡是“"之内的，不管是否注解，都变成不可阅读的密文了，但无法加密中文。

几种ASP源代码保护方法：

1，“脚本最小化”即ASP文件中只编写尽可能少的源代码，实现

商业逻辑的脚本部分被封装到一个COM/DCOM组件，并在ASP脚

本中创建该组件，进而调用相应的方法（methed）即可。应用开发者

动手开发ASP脚本应用之前就可按此思路来开发，或者直接用ASP

脚本快速开发出原型系统后，针对需要保护、加密的重要脚本用

COM/DCOM组件来重新开发、实现并替换。

2，“脚本加密”即ASP脚本仍直接按源代码方式进行开发，但在发布到运行环境之前将脚本进行加密处理，只要把加密后的密文脚本发布出去。即在ASP.DLL读取脚本这个环节加入密文还原的处理。实现这种思路的方法有两种：一是自行开发一个ISAPI的IIS过滤（filter）块，在ASP.DLL之前勾连（hook）对ASP脚本文件的读取，以便把文件系统读出的密文还原成ASP.DLL可以解释的明文；

方法二是直接由ASP.DLL提供对ASP脚本加密处理的支持。微软在新版本的Vbscript.dll jscript.dll中提供这种成为MS script encode技术的支持。这样，无论是客户端的Vbscript jscript（包括WSH脚本等），还是服务器端的Vbscript jscript （即ASP脚本）都可以支持加密处理。

MS script encode 技术具体的实现思路包括以下两个方面：一是加密过程，通过提供一个实用程序对包含ASP脚本源代码的文本文件进行扫描，找出其标记为