解决方法:

(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的参数即可,例如:

这样即使他人得到了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日志文件。

(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文件。

问题解决和建议:

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