测试Web应用程序漏洞的最重要步骤是找出Web服务器上托管的特定应用程序。许多应用程序都具备已知的漏洞和已知的攻击策略,能够利用这些策略来获取远程控制或利用数据。此外,许多应用程序常常被错误配置或未更新,由于他们认为它们仅在“内部”使用,所以不存在威胁。php
随着虚拟Web服务器的普及,IP地址和Web服务器之间传统的1:1类型关系正在失去其原有的重要意义。拥有符号名称解析为同一IP地址的多个网站或应用程序并不罕见。此方案不只限于托管环境,也适用于普通的企业环境。html
安全专业人员有时会得到一组IP地址做为测试目标。能够说这种状况更相似于渗透测试类型的参与,但不管如何,预计这样的任务将测试经过该目标可访问的全部Web应用程序。问题是给定的IP地址在端口80上托管HTTP服务,可是若是测试人员应该经过指定IP地址(他们都知道)来访问它,它会报告“没有在此地址配置的Web服务器”或相似的消息。可是该系统能够“隐藏”许多与不相关的符号(DNS)名称相关联的Web应用程序。显然,分析的程度深受测试人员测试全部应用程序或仅测试他们知道的应用程序的影响。前端
有时,目标规范更丰富。能够给测试者一个IP地址列表及其相应的符号名称。然而,这个列表可能会传达部分信息,即它可能会省略一些符号名称,而客户可能甚至都没有意识到这一点(这种状况更有可能发生在大型组织中)。web
影响评估范围的其余问题由在非显而易见的URL(例如,http://www.example.com/some-strange-URL)上发布的Web应用程序表示,这些URL 在其余地方未引用。这多是因为错误(因为配置错误)或故意(例如,未公开的管理界面)。数据库
要解决这些问题,必须执行Web应用程序发现。浏览器
枚举Web服务器上存在的范围内的应用程序缓存
Web应用程序发现是一个旨在识别给定基础结构上的Web应用程序的过程。后者一般被指定为一组IP地址(多是一个网络块),但可能包含一组DNS符号名称或二者的混合。这些信息在执行评估以前分发,不管是经典式渗透测试仍是以应用为中心的评估。在这两种状况下,除非参与规则另有规定(例如,“仅测试位于URL http://www.example.com/的应用程序”),评估应力求成为最全面的范围,即应该识别经过给定目标可访问的全部应用程序。如下示例检查了可用于实现此目标的一些技术。安全
注意:如下某些技术适用于面向Internet的Web服务器,即DNS和反向IP基于Web的搜索服务以及搜索引擎的使用。示例使用私有IP地址(例如192.168.1.100),除非另有说明,不然它们表明通用 IP地址,仅用于匿名用途。服务器
影响有多少应用程序与给定DNS名称(或IP地址)相关的因素有三个:网络
1.不一样的基本URL
Web应用程序的明显入口点是www.example.com,即便用这种简写表示法,咱们会想到源自http://www.example.com/的Web应用程序(一样适用于https) )。可是,即便这是最多见的状况,也没有什么强迫应用程序以“/”开头。
例如,相同的符号名称能够与三个Web应用程序相关联,例如:http : //www.example.com/url1 http://www.example.com/url2 http://www.example.com/url3
在这种状况下,URL http://www.example.com/不会与有意义的页面相关联,而且三个应用程序将被“隐藏”,除非测试人员明确知道如何访问它们,即测试人员知道url1,url2或url3。一般不须要以这种方式发布Web应用程序,除非全部者不但愿以标准方式访问它们,并准备通知用户他们的确切位置。这并不意味着这些应用程序是秘密的,只是它们的存在和位置没有明确地公布。
2.非标准端口
虽然Web应用程序一般位于端口80(http)和443(https)上,但这些端口号并无什么神奇之处。实际上,Web应用程序可能与任意TCP端口相关联,而且能够经过指定端口号来引用,以下所示:http [s]://www.example.com:port /。例如,http://www.example.com:20000 /。
3.虚拟主机
DNS容许单个IP地址与一个或多个符号名称相关联。例如,IP地址192.168.1.100可能与DNS名称www.example.com,helpdesk.example.com,webmail.example.com相关联。并不是全部名称都属于同一DNS域。能够经过使用所谓的虚拟主机来反映该1对N关系以服务于不一样的内容。指定咱们所指的虚拟主机的信息嵌入在HTTP 1.1 Host: header [1]中。
除了明显的www.example.com以外,人们不会怀疑是否存在其余Web应用程序,除非他们知道helpdesk.example.com和webmail.example.com。
解决问题1的方法 - 非标准URL
没法彻底肯定是否存在非标准命名的Web应用程序。做为非标准,没有固定的标准来管理命名约定,可是测试人员可使用许多技术来得到一些额外的洞察力。
首先,若是Web服务器配置错误并容许目录浏览,则能够发现这些应用程序。漏洞扫描程序可能在这方面有所帮助。
其次,这些应用程序可能被其余网页引用,而且它们有可能被网络搜索引擎抓取并编入索引。若是测试人员怀疑www.example.com上存在此类“隐藏”应用程序,他们可使用网站运营商进行搜索并检查“site:www.example.com”的查询结果。在返回的URL中,可能有一个指向这种非显而易见的应用程序。
另外一种选择是探测多是未发布应用程序候选者的URL。例如,Web邮件前端多是从的网址访问诸如https://www.example.com/webmail,https://webmail.example.com/,或https://mail.example.com/。管理界面也是如此,它能够在隐藏的URL(例如,Tomcat管理界面)上发布,但在任何地方都没有引用。所以,进行一些字典式搜索(或“智能猜想”)可能会产生一些结果。漏洞扫描程序可能在这方面有所帮助。
解决问题2的方法 - 非标准端口
很容易检查非标准端口上是否存在Web应用程序。端口扫描程序(如nmap [2])可以经过-sV选项执行服务识别,并将识别任意端口上的http [s]服务。所须要的是对整个64k TCP端口地址空间的彻底扫描。
例如,如下命令将经过TCP链接扫描查找IP 192.168.1.100上的全部开放端口,并将尝试肯定绑定到它们的服务(仅显示必要的开关 - nmap具备一组普遍的选项,其讨论超出范围):
nmap -PN -sT -sV -p0-65535 192.168.1.100
检查输出并查找http或SSL包装服务的指示(应该进行探测以确认它们是https)就足够了。例如,上一个命令的输出可能以下所示:
192.168.1.100上有趣的端口: (已扫描但未显示的65527端口处于状态:已关闭) 港口国服务版 22 / tcp open ssh OpenSSH 3.5p1(协议1.99) 80 / tcp打开http http httpd 2.0.40((Red Hat Linux)) 443 / tcp open ssl OpenSSL 901 / tcp打开http Samba SWAT管理服务器 1241 / tcp打开ssl Nessus安全扫描程序 3690 / tcp打开未知 8000 / tcp打开http-alt? 8080 / tcp打开http Apache Tomcat / Coyote JSP引擎1.1
从这个例子中,人们看到:
$ telnet 192.168.10.100 8000 试试192.168.1.100 ...... 链接到192.168.1.100。 逃脱角色是'^]'。 GET / HTTP / 1.0 HTTP / 1.0 200 OK 编译指示:无缓存 内容类型:text / html 服务器:MX4J-HTTPD / 1.0 到期:如今 缓存控制:无缓存 <HTML> ...
这证明了它其实是一个HTTP服务器。或者,测试人员可使用Web浏览器访问URL; 或使用GET或HEAD Perl命令,它们模仿HTTP交互,例如上面给出的那些(可是HEAD请求可能不被全部服务器遵照)。
漏洞扫描程序能够执行相同的任务,但首先检查所选的扫描程序是否可以识别在非标准端口上运行的http [s]服务。例如,Nessus [3]可以在任意端口上识别它们(前提是它被指示扫描全部端口),而且将针对nmap提供对已知Web服务器漏洞的大量测试,以及https服务的SSL配置。如前所述,Nessus还可以发现流行的应用程序或Web界面,不然这些应用程序或Web界面可能会被忽视(例如,Tomcat管理界面)。
解决问题3的方法 - 虚拟主机
有许多技术可用于识别与给定IP地址xyzt相关联的DNS名称。
DNS区域传输
因为区域传输在很大程度上不受DNS服务器的支持,所以如今这种技术的使用受到限制。可是,它可能值得一试。首先,测试人员必须肯定服务于xyzt的名称服务器。若是已知xyzt的符号名称(让它为www.example.com),则能够经过请求DNS NS记录,经过nslookup,host或dig等工具肯定其名称服务器。
若是xyzt没有已知的符号名称,但目标定义至少包含符号名称,则测试人员可能会尝试应用相同的进程并查询该名称的名称服务器(但愿xyzt也将由该名称服务器提供) 。例如,若是目标由IP地址xyzt和名称mail.example.com组成,请肯定域example.com的名称服务器。
如下示例显示如何使用host命令标识www.owasp.org的名称服务器:
$ host -t ns www.owasp.org www.owasp.org是owasp.org的别名。 owasp.org名称服务器ns1.secure.net。 owasp.org名称服务器ns2.secure.net。
如今能够向域example.com的名称服务器请求区域传输。若是测试人员很幸运,他们将返回该域名的DNS条目列表。这将包括明显的www.example.com和不太明显的helpdesk.example.com和webmail.example.com(以及可能还有其余人)。检查区域传输返回的全部名称,并考虑与要评估的目标相关的全部名称。
尝试从其中一个名称服务器请求owasp.org的区域传输:
$ host -l www.owasp.org ns1.secure.net 使用域服务器: 名称:ns1.secure.net 地址:192.220.124.10#53 别名: 主持人www.owasp.org未找到:5(REFUSED) ; 转移失败。
DNS反向查询
此过程与前一个过程相似,但依赖于反向(PTR)DNS记录。请尝试将记录类型设置为PTR并对给定的IP地址发出查询,而不是请求区域传输。若是测试人员很幸运,他们可能会返回DNS名称条目。这种技术依赖于IP到符号名称映射的存在,这是不能保证的。
基于Web的DNS搜索
此类搜索相似于DNS区域传输,但依赖于基于Web的服务,可在DNS上启用基于名称的搜索。其中一项服务是Netcraft搜索DNS服务,可从http://searchdns.netcraft.com/?host得到。测试人员能够查询属于您选择的域的名称列表,例如example.com。而后他们将检查他们得到的名字是否与他们正在检查的目标相关。
反向IP服务
反向IP服务相似于DNS反向查询,不一样之处在于测试人员查询基于Web的应用程序而不是名称服务器。有许多此类服务可用。因为它们倾向于返回部分(一般是不一样的)结果,所以最好使用多个服务来得到更全面的分析。
域名工具反向IP:http://www.domaintools.com/reverse-ip/ (须要免费会员资格)
MSN搜索:http://search.msn.com 语法:“ip:xxxx”(不带引号)
网站托管信息:http ://whois.webhosting.info/语法:http://whois.webhosting.info/xxxx
DNSstuff:http://www.dnsstuff.com/ (提供多种服务)
http://www.net-square.com/mspawn.html (对域和IP地址的多个查询,须要安装)
tomDNS:http://www.tomdns.net/index.php (在撰写本文时,某些服务仍然是私有的)
SEOlogs.com:http://www.seologs.com/ip-domains.html (反向IP /域查找)
如下示例显示了对上述反向IP服务之一的查询结果216.48.3.18,即www.owasp.org的IP地址。已经揭示了映射到同一地址的另外三个非显而易见的符号名称。
谷歌搜索
从之前的技术收集信息后,测试人员能够依靠搜索引擎来改进和增长他们的分析。这可能会产生属于目标的其余符号名称的证据,或者可经过非显而易见的URL访问的应用程序。
例如,考虑到以前关于www.owasp.org的示例,测试人员能够查询Google和其余搜索引擎,以查找与新发现的webgoat.org,webscarab.com和webscarab域名相关的信息(所以,DNS名称)。网。
在测试:蜘蛛,机器人和爬虫中解释了谷歌搜索技术。
不适用。不管测试人员开始使用多少信息,该方法都与Black Box测试中列出的方法相同。