堵塞Web漏洞

转自：http://www.chinafu.com/service/doc-view-149.html

Web的大多数安全问题都属于下面三种类型之一：

1、服务器向公众提供了不应该提供的服务。

2、服务器把本应私有的数据放到了公开访问的区域。

3、服务器信赖了来自不可信赖数据源的数据。

显然，许多服务器管理员从来没有从另一个角度来看看他们的服务器，例如使用端口扫描程序。如果他们曾经这样做了，就不会在自己的系统上运行那么多的服务，而这些服务原本无需在正式提供Web服务的机器上运行，或者这些服务原本无需面向公众开放。

与这种错误经常相伴的是，为了进行维护而运行某些不安全的、可用于窃取信息的协议。例如，有些Web服务器常常为了收集订单而提供POP3服务，或者为了上载新的页面内容而提供FTP服务甚至数据库服务。在某些地方这些协议可能提供安全认证(比如APOP)甚至安全传输(比如POP或者FTP的SSL版本)，但更多的时候，人们使用的是这些协议的非安全版本。有些协议，比如Msql数据库服务，则几乎没有提供任何验证机制。

从公司外面访问自己的网络，完整地检测、模拟攻击自己的网站看看会发生些什么，这对于Web管理者来说是一个很好的建议。有些服务在机器安装之后的默认配置中已经启动，或者由于安装以及初始设置的需要而启动了某些服务，这些服务可能还没有正确地关闭。例如，有些系统提供的Web服务器会在非标准的端口上提供编程示范以及系统手册，它们往往包含错误的程序代码并成为安全隐患所在。正式运行的、可从Internet访问的Web服务器不应该运行这些服务，请务必关闭这些服务。

9.1Web服务器常见漏洞介绍

我们的目的就是向大家介绍Web服务器的常见漏洞，相信看了自己也能试着发现一些Web服务器的漏洞了。不过需要记住的是，不要为了寻找漏洞而寻找漏洞。另外，即使你找到了漏洞，是否能够利用还是另外一回事。

Web服务器存在的主要漏洞包括物理路径泄露，CGI源代码泄露，目录遍历，执行任意命令，缓冲区溢出，拒绝服务，条件竞争和跨站脚本执行漏洞，和CGI漏洞有些相似的地方，但是更多的地方还是有着本质的不同。不过无论是什么漏洞，都体现着安全是一个整体的真理，考虑Web服务器的安全性，必须要考虑到与之相配合的操作系统。

9.1.1物理路径泄露

物理路径泄露一般是由于Web服务器处理用户请求出错导致的，如通过提交一个超长的请求，或者是某个精心构造的特殊请求，亦或是请求一个Web服务器上不存在的文件。这些请求都有一个共同特点，那就是被请求的文件肯定属于CGI脚本，而不是静态HTML页面。

还有一种情况，就是Web服务器的某些显示环境变量的程序错误的输出了Web服务器的物理路径，这应该算是设计上的问题。

9.1.2目录遍历

目录遍历对于Web服务器来说并不多见，通过对任意目录附加“../”，或者是在有特殊意义的目录附加“../”，或者是附加“../”的一些变形，如“..\”或“..//”甚至其编码，都可能导致目录遍历。前一种情况并不多见，但是后面的几种情况就常见得多，去年非常流行的IIS二次解码漏洞和Unicode解码漏洞都可以看作是变形后的编码。

9.1.3执行任意命令

执行任意命令即执行任意操作系统命令，主要包括两种情况。一是通过遍历目录，如前面提到的二次解码和UNICODE解码漏洞，来执行系统命令。另外一种就是Web服务器把用户提交的请求作为SSI指令解析，因此导致执行任意命令。

9.1.4缓冲区溢出

缓冲区溢出漏洞想必大家都很熟悉，无非是Web服务器没有对用户提交的超长请求没有进行合适的处理，这种请求可能包括超长URL，超长HTTPHeader域，或者是其它超长的数据。这种漏洞可能导致执行任意命令或者是拒绝服务，这一般取决于构造的数据。

9.1.5拒绝服务

拒绝服务产生的原因多种多样，主要包括超长URL，特殊目录，超长HTTPHeader域，畸形HTTPHeader域或者是DOS设备文件等。由于Web服务器在处理这些特殊请求时不知所措或者是处理方式不当，因此出错终止或挂起。

9.1.6条件竞争

这里的条件竞争主要针对一些管理服务器而言，这类服务器一般是以System或Root身份运行的。当它们需要使用一些临时文件，而在对这些文件进行写操作之前，却没有对文件的属性进行检查，一般可能导致重要系统文件被重写，甚至获得系统控制权。

9.2CGI的安全性

现在我们来谈谈到底什么是CGI(CommonGateIntergace)。在物理上，CGI是一段程序，它运行在Server上，提供同客户段Html页面的接口。这样说大概还不好理解。那么我们看一个实际例子：现在的个人主页上大部分都有一个留言本。留言本的工作是这样的：先由用户在客户段输入一些信息，如名字之类的东西。接着用户按一下“留言”(到目前为止工作都在客户端)，浏览器把这些信息传送到服务器的CGI目录下特定的CGI程序中，于是CGI程序在服务器上按照预定的方法进行处理。在本例中就是把用户提交的信息存入指定的文件中。然后CGI程序给客户端发送一个信息，表示请求的任务已经结束。此时用户在浏览器里将看到“留言结束”的字样。整个过程结束。

CGI是一种共用网关接口，它可以称之为一种机制.因此您可以使用不同的程序编写适合的CGI程序，这些程序语言包括VisualBasic、Delphi或C/C++等，您将已经写好的程序放在Web服务器的计算机上运行，再将其运行结果通过Web服务器传输到客户端的浏览器上。事实上，这样的编制方式比较困难而且效率低下，因为你每一次修改程序都必须重新将CGI程序编译成可执行文件。

9.2.1为什么使用CGI

CGI可以为我们提供许多HTML无法做到的功能，比如：

1、一个记数器

2、顾客信息表格的提交以及统计

3、搜索程序

4、Web数据库

用HTML是没有办法记住客户的任何信息的，就算用户愿意让你知道。用HTML也是无法把信息记录到某一个特定文件里的。要把客户段的信息记录在服务器的硬盘上，就要用到CGI。这是CGI最重要的作用，它补充了HTML的不足。是的，仅仅是补充，不是替代。

9.2.2CGI安全问题

在计算机领域——尤其在Internet上——尽管大部分Web服务器所编的程序都尽可能保护自己的内容不受侵害，但只要CGI脚本中有一点安全方面的失误——口令文件、私有数据、以及任何东西，就能使入侵者能访问计算机。遵循一些简单的规则并保持警惕能使自己的CGI脚本免受侵害，从而可以保护自己的权益。这里所说的CGI安全，主要包括两个方面，一是Web服务器的安全，一是CGI语言的安全

先从CGI问题的分类开始谈起，一般来说，CGI问题主要有以下几类：

1、暴露敏感或不敏感信息；

2、缺省提供的某些正常服务未关闭；

3、利用某些服务漏洞执行命令；

4、应用程序存在远程溢出；

5、非通用CGI程序的编程漏洞。

下面我们就来详细介绍一下关于CGI的漏洞：

●配置错误

这里所说的配置错误主要指CGI程序和数据文件的权限设置不当，这可能导致CGI源代码或敏感信息泄露。还有一个经常犯的错误就是安装完CGI程序后没有删除安装脚本，这样攻击者就可能远程重置数据。前些日子“XX大联盟”论坛多次被黑就是这个低级错误所致。

●边界条件错误

这个错误主要针对C语言编写的CGI，利用这个错误，攻击者可能发起缓冲区溢出攻击，从而提升权限。

●访问验证错误

这个问题主要是因为用于验证的条件不足以确定用户的身份而造成的，经常会导致未经授权访问，修改甚至删除没有访问权限的内容。用于确定用户身份的方法一般有两种，一是账号和密码，一是Session认证。而不安全的认证方法包括Userid认证，Cookie认证等等。

●来源验证错误

比较常见的利用这种错误进行攻击的方法就是DoS，也就是拒绝服务攻击，如我们知道的灌水机，就是利用CGI程序没有对文章的来源进行验证，从而不间断的发文章，最后导致服务器硬盘充满而挂起。

●输入验证错误

这种错误导致的安全问题最多，主要是因为没有过滤特殊字符。比如说，没有过滤“%20”造成的畸形注册，没有过滤“../”经常造成泄露系统文件，没有过滤“$”经常导致泄露网页中的敏感信息，没有过滤“;”经常导致执行任意系统指令，没有过滤“|”或“\t”经常导致文本文件攻击，没有过滤“’”和“#”经常导致SQL数据库攻击，没有过滤“<”和“>”导致的Cross-SiteScripting攻击等。

●意外情况处理失败

这种错误也很常见，如没有检查文件是否存在就直接打开设备文件导致拒绝服务，没有检查文件是否存在就打开文件提取内容进行比较而绕过验证，上下文攻击导致执行任意代码等。

●策略错误

这种错误主要是由于编制CGI程序的程序员的决策造成的。如原始密码生成机制脆弱导致穷举密码导致在Cookie中明文存放账号密码导致敏感信息泄露，使用与CGI程序不同的扩展名扩展名存储敏感信息导致该文件被直接下载，丢失密码模块在确认用户身份之后直接让用户修改密码而不是把密码发到用户的注册信箱，登陆时采用账号和加密后的密码进行认证导致攻击者不需要知道用户的原始密码就能够登陆等。

●习惯问题

程序员的习惯也可能导致安全问题，如使用某些文本编辑器修改CGI程序时，经常会生成“.bak”文件，如果程序员编辑完后没有删除这些备份文件，则可能导致CGI源代码泄露。另外，如果程序员总喜欢把一些敏感信息(如账号密码)放在CGI文件中的话，只要攻击者对该CGI文件有读权限(或者利用前面介绍的一些攻击方法)就可能导致敏感信息泄露。

●使用错误

主要是一些函数的使用错误，如Perl中的“die”函数，如果没有在错误信息后面加上“\n”的话，就极可能导致物理路径泄露。

●其它错误

此外，还有一些其它难以归类的错误，如“非1即0”导致绕过认证的问题。

9.2.3常用的的CGI漏洞检测工具

1.Twwwscan

这个工具速度比较快，而且可以利用参数把windows系统和unix系统分开扫描，不使用图形界面，比较简单些；

2.Cis

是个图形化的小巧扫描工具，主要是针对windows系统设计，对检查出来的CGI问题有比较详细的描述，利于使用、分析和解决漏洞；

3.Voideye

图形界面做的比较花哨，可以检查的CGI问题比较多些，但不太准确。

4.Webscan

检查种类特多，好象有300来条，能提供HTML格式报告，集合了一些跟随攻击方式，这些工具只是检查一下服务器有没有这个链接存在，如果有，就会报出存在漏洞，这当然会有很多误报，工具是死的，人是活的，熟练应用这些辅助工具需要点时间熟悉一下就行了。

9.2.4如何让你的CGI更安全

了解了CGI的安全问题，我们也该知道怎么加强CGI的安全了吧？下面简单总结一下作为参考：

1、使用最新版本的Web服务器，安装最新的补丁程序，正确配置服务器；

2、按照帮助文件正确安装CGI程序，删除不必要的安装文件和临时文件；

3、使用C编写CGI程序时，使用安全的函数；

4、使用安全有效的验证用户身份的方法；

5、验证用户的来源，防止用户短时间内过多动作；

6、推荐过滤；

7、注意处理好意外情况；

8、实现功能时制定安全合理的策略；

9、培养良好的编程习惯；

10、科学严谨的治学态度，避免“想当然”的错误；

9.3 ASP的安全性

ASP(ActiveServerPage)，一个重要的Web技术。它的出现给互联网带来了新的活力，它以一种前所未有的方式处理浏览器与服务器的交互通过内建对象、ADO支持、WSH(可通过它管理NTDOMAIN)几乎可以完成传统应用程序所能完成的一切工作！

ASP是一种类似HTML(HypertextMarkupLanguage超文本标识语言)、Script与CGI(CommonGAtewayInterface通用网关接口)的结合体，但是其运行效率却比CGI更高、程序编制也比HTML更方便且更有灵活性，程序安全及保密性也比Script好。如果您是第一次接触互连网(Internet)，那么您可能不很了解上述名词，以下对各种名词加以解释并说明它们之间的区别。

HTML(HypertextMarkupLanguage)是一种超文本标识语言，文件通过这种格式可以在互连网上载送浏览，用户只要使用网页浏览器工具就可以浏览这些文件，目前比较常用的工具包括MicrosoftInternetExplorer，NetscapeCommunicator等，由于HTML文件都是由标签(tag)所组成，因此它比较适合制作静态网页，再者，由于先天上的限制HTML是无法直接存取数据库的，所以存取数据库的工作大多是依靠CGI来处理。ASP不但可以包含HTML标签，也可以直接存取数据库及使用无限扩充的ActiveX控件，因此在程序编制上要比HTML方便而且更富有灵活性。

简单讲，ASP是位于服务器端的脚本运行环境，通过这种环境，用户可以创建和运行动态的交互式Web服务器应用程序，如交互式的动态网页，包括使用HTML表单收集和处理信息，上传与下载等等，就像用户在使用自己的CGI程序一样。但是他比CGI简单。更重要的是，ASP使用的ActiveX技术基于开放设计环境，用户可以自己定义和制作组件加入其中，使自己的动态网页几乎具有无限的扩充能力，这是传统的CGI等程序所远远不及的地方。使用ASP还有个好处，就在于ASP可利用ADO(ActiveDataObject，微软的一种新的数据访问模型，类似于DAO)方便地访问数据库，从而使得开发基于WWW的应用系统成为可能。

9.3.1ASP漏洞分析和解决方法

ASP的漏洞已经算很少的了，想要找到数据库的实际位置也不简单，但这不表明黑客无孔可入，也正是这个观点，一般的程序设计员常常忘记仔细的检查是否有漏洞，所以才有可能导致网站资料被窃取的事件发生。

ASP里面含有一个安全漏洞，就是在/site/eg/source.asp这个随软件一起销售的范例程序，里面的内容有教使用者如何在服务器的这个目录下随意写入档案。解决这个漏洞的方法是建议删除所有软件提供的范例程序。

1、Code.asp文件会泄漏ASP代码

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

code.aspsource=/directory/file.asp

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

下面这命令是比较新的：

http://someurl/iissamples/exair/howitworks/code.asp/lunwen/soushuo.asp=xxx.asp

最大的危害莫过于ASP文件可以被上述方式读出；数据库密码以明文形式暴露在黑客眼前；

问题解决或建议：

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

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

IIS3、IIS4的ASP的文件操作都可以通过Filesystemobject实现，包括文本文件的读写目录操作、文件的拷贝改名删除等，但是这个强大的功能也留下了非常危险的“后门”。利用Filesystemobjet可以篡改下载FAT分区上的任何文件。即使是NTFS分区，如果权限没有设定好的话，同样也能破坏，一不小心你就可能遭受“灭顶之灾”。遗憾的是很多Webmaster只知道让Web服务器运行起来，很少对NTFS进行权限设置，而NT目录权限的默认设置偏偏安全性又低得可怕。因此，如果你是Webmaster，建议你密切关注服务器的设置，尽量将Web目录建在NTFS分区上，目录不要设定EveryoneFullControl，即使是是管理员组的成员一般也没什么必要FullControl，只要有读取、更改权限就足够了。也可以把Filesystemobject的组件删除或者改名。

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

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

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

<fontsize=10>你好！</font>

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

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

解决方法和建议：

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

4、AccessMDB数据库有可能被下载的漏洞

问题描述：

在用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={MicrosoftAccessDriver(*.mdb)};dbq=”&DBPath

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

conn.open“shujiyuan”

(3)使用Access来为数据库文件编码及加密。首先在选取“工具”→“安全”→“加密/解密数据库”，选取数据库(如：employer.mdb)，然后接确定，接着会出现“数据库加密后另存为”的窗口，存为：employer1.mdb。接着“employer.mdb”就会被编码，然后存为：employer1.mdb。

注意：以上的动作并不是对数据库设置密码，而只是对数据库文件加以编码，目的是为了防止他人使用别的工具来查看数据库文件的内容。

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

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

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

以下为引用的内容： 　　param=“driver={MicrosoftAccessDriver(*.mdb)};Pwd=yfdsfs” 　　param=param&“;dbq=”&server.mappath(“employer1.mdb”) 　　conn.openparam

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

5.asp程序密码验证漏洞

漏洞描述：

很多网站把密码放到数据库中，在登陆验证中用以下Sql，(以ASP为例)

sql=“select*fromuserwhereusername=”&username&“andpass=”&pass&”

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

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

sql=“select*fromuserwhereusername=”&username&“andpass=“&pass&”

or是一个逻辑运算符，作用是在判断两个条件的时候，只要其中一个条件成立，那么等式将会成立。而在语言中，是以1来代表真的(成立)。那么在这行语句中，原语句的“and”验证将不再继续，而因为“1=1”和“or”令语句返回为真值。
另外我们也可以构造以下的用户名：

username=aaorusername<>aa

pass=aaorpass<>aa

相应的在浏览器端的用户名框内写入：aaorusername<>aa口令框内写入：aaorpass<>aa，注意这两个字符串两头是没有的。这样就可以成功的骗过系统而进入。

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

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

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

问题解决和建议：对输入的内容验证和“”号的处理。

6.IIS4或者IIS5中安装有IndexServer服务会漏洞ASP源程序

问题描述：

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

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

http://202.116.26.38/null.htwCiWebHitsFile=/default.asp&CiRestriction=none&CiHiliteTyp-e=Full

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

http://someurl/null.htw?CiWebHitsFile=/default.asp%20&CiRestriction=none&CiHiliteType=Full

这将获得该程序的源代码。(注意：/default.asp是以Web的根开始计算。如某站点的http://XXXXXX/welcome.asp)

那么对应就是：

http://someurl/null.htwCiWebHitsFile=/XXXXXX/welcome.asp%20&CiRestriction=none&CiHiliteType=Full)

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

问题解决或者建议：

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

7.NTIndexServer存在返回上级目录的漏洞

问题描述：

IndexSserver2.0是WinNT4.0OptionPack中附带的一个软件的工具，其中的功能已经被WinNT/2000中的IndexingServices所包含。当与IIS结合使用时，IndexServer和IndexingServices便可以在最初的环境来浏览WebSearch的结果，它将生成一个HTML文件，其中包含了查找后所返回页面内容的简短引用，并将其连接至所返回的页面[即符合查询内容的页面]，也就是超级连接。要做到这一点，它便需要支持由Webhits.dll-ISAPI程序处理的.htw文件类型。这个Dll允许在一个模版中使用“../”用做返回上级目录的字符串。这样，了解服务器文件结构的攻击者便可以远程的阅读该机器上的任意文件了。

漏洞的利用：

(1)您的系统中存在.htw文件

IndexServer提供的这种超级连接允许Web用户获得一个关于他搜寻结果的返回页，这个页面的名字是与CiWebHitsFile变量一起通过.htw文件的，Webhits.dll这个ISAPI程序将处理这个请求，对其进行超级连接并返回该页面。因此用户便可以控制通过.htw文件的CiWebHits变量，请求到任何所希望获得的信息。另外存在的一个问题便是ASP或其他脚本文件的源代码也可以利用该方法来获得。

上面我们说过Webhits.dll后接上“../”便可以访问到Web虚拟目录外的文件，下面我们来看个例子：

http://somerul/iissamples/issamples/oop/qfullhit.dll?

iWebHitsFile=/../../winnt/system32/logfiles/w3svc1/ex000121.log&CiRestriction=none&Ci-HiliteType=Full

在浏览器中输入该地址，便可以获得该服务器上给定日期的Web日志文件。

以下为引用的内容： 在系统常见的.htw样本文件有： 　　/iissamples/issamples/oop/qfullhit.htw 　　/iissamples/issamples/oop/qsumrhit.htw 　　/iissamples/exair/search/qfullhit.htw 　　/iissamples/exair/search/qsumrhit.hw 　　/iishelp/iis/misc/iirturnh.htw[这个文件通常受loopback限制]

(2)您的系统中不存在.htw文件

调用一个Webhits.dllISAPI程序需要通过.htw文件来完成，如果您的系统中不存在.htw文件，虽然请求一个不存在的.htw文件将失败，但是您的仍然存在可被利用的漏洞。其中的窍门便是利用Inetinfo.exe来调用Webhits.dll，这样同样能访问到Web虚拟目录外的文件。但我们需要通过制作一个的特殊的URL来完成这个文件必须是一个静态的文件，如“.htm”，“.html”，“.txt”或者“.gif”，“.jpg”。这些文件将用作模版来被Webhits.dll打开。现在我们需要获得Inetinfo.exe来利用Webhits.dll，唯一可以做到这点的便是请求一个.htw文件：

http://url/default.htm.htwCiWebHitsFile=/../../winnt/system32/logfiles/w3svc1/ex000121.l-og&CiRestriction=none&CiHiliteType=Full

很明显，这个请求肯定会失败，因为系统上不存在这个文件。但请注意，我们现在已经调用到了Webhits.dll，我们只要在一个存在的文件资源后面[也就是在.htw前面]加上一串特殊的数字(%20s)，[就是在例子中“default.htm”后面加上这个代表空格的特殊数字]，这样我们便可以欺骗过Web服务器从而达到我们的目的.由于在缓冲部分中.htw文件名字部分被删除掉[由于%20s这个符号]，所以，当请求传送到Webhits.dll的时候，便可以成功的打开该文件，并返回给客户端，而且过程中并不要求系统中真的存在.htw文件。

问题解决和建议：

微软已经对该问题发放了补丁:

以下为引用的内容： 　　IndexServer2.0: 　　Intel:http://www.microsoft.com/downloads/release.aspReleaseID=17727 　　Alpha:http://www.microsoft.com/downloads/release.asp?ReleaseID=17728 　　Windows2000IndexingServices:Intel:http://www.microsoft.com/downloads/release.asp?ReleaseID=17726