Web应用安全测试(基于OWASP Testing)–信息收集

OWASP 南瓜一族 2019℃ 0评论

目录

1 信息收集

在该信息收集阶段,OWASP列了以下10项(这一项在OWASP Testing Guide v3之前多了一大子类,当前的V3是9个子类):

  • 搜索引擎信息发现和侦察 (OTG-INFO-001)
  • 识别web服务器 (OTG-INFO-002)
  • web服务器元文件信息发现 (OTG-INFO-003)
  • 服务器应用应用枚举 (OTG-INFO-004)
  • 评论信息发现 (OTG-INFO-005)
  • 应用入口识别 (OTG-INFO-006)
  • 识别应用工作流程 (OTG-INFO-007)
  • 识别web应用框架 (OTG-INFO-008)
  • 识别web应用程序 (OTG-INFO-009)
  • 绘制应用架构图 (OTG-INFO-010)

2 搜索引擎信息发现和侦察 (OTG-INFO-001)

## 2.11 描述
这块的话,我相信所有知道搜索引擎可怕。通过搜索引擎去查找问题,方便有很多,大的来说,就是直接和间接。如直接搜索到账号密码,并成功登录进行。间接是可能通过论坛、新闻、或第三方的社工库等去查。
一旦搜索引擎机器人完成抓取工作,它会基于标签如或者属性来组织相关内容的索。如果robots.txt没有更新,或者也没有内联HTML标签要求不抓取,搜索引擎可能会检索到拥有者不希望包含的页面。网站管理员可以使用上面提到的robots.txt文件、HTLM元标签、认证措施或者搜索引擎提供的工具来移除这些内容。

## 2.12 测试目标
了解有多少应用/系统/组织的敏感设计和配置信息在网上公开,包括直接在组织网站公布和第三方网站间接公开。

2.13 操作

使用搜索引擎来查找:

  • 网络拓扑和配置
  • 获得管理员或者其他核心员工的发帖信息和邮件
  • 登陆流程和用户名格式
  • 用户名和密码
  • 错误消息内容
  • 开发、测试、验收和上线版本的网站

2.14 搜索选项

使用高级的”site:”搜索选项,他可以帮助检索特定域名下的内容[2]。不要局限在一种所搜索引擎,不同的引擎抓取页面有不同的算法,可能会产生不同的结果。可以考虑使用下面这些搜索引擎:

  • Baidu
  • binsearch.info
  • Bing
  • Duck Duck Go
  • ixquick/Startpage
  • Google
  • Shodan
  • PunkSpider
  • Duck Duck Go 和 ixquick/Startpage 提供关于测试者简化的泄露信息。

Google提供另一个高级的搜索选项OWASP Google Hacking ProjectGoogle Hacking Database (GHDB)


2.14 测试工具

FoundStone SiteDigger – http://www.mcafee.com/uk/downloads/free-tools/sitedigger.aspx
Google Hacker – http://yehg.net/lab/pr0js/files.php/googlehacker.zip
Stach & Liu’s Google Hacking Diggity Project – http://www.stachliu.com/resources/tools/google-hacking-diggity-project/
PunkSPIDER – http://punkspider.hyperiongray.com/

2.15 参考资料

Web
[1] “Google Basics: Learn how Google Discovers, Crawls, and Serves Web Pages” – https://support.google.com/webmasters/answer/70897
[2] “Operators and More Search Help” – https://support.google.com/websearch/answer/136861?hl=en
[3] “Google Hacking Database” – http://www.exploit-db.com/google-dorks/

3 识别web服务器 (OTG-INFO-002)

3.1 描述

对于渗透测试人员来说,识别Web服务器是一项十分关键的任务。了解正在运行的服务器类型和版本能让测试者更好去测试已知漏洞和大概的利用方法。

今天市场上存在着许多不同开发商不同版本的Web服务器。明确被测试的服务器类型能够有效帮助测试过程和决定测试的流程。这些信息可以通过发送给web服务器测定命令,分析输出结果来推断出,因为不同版本的web服务器软件可能对这些命令有着不同的响应。通过了解不同服务器对于不同命令的响应,并把这些信息保存在指纹数据库中,测试者可以发送请求,分析响应,并与数据库中的已知签名相对比。请注意,由于不同版本的服务器对于同一个请求可能有同样的响应,所以可能需要多个命令请求才能准确识别web服务器。十分罕见的,也有不同版本的服务器响应的请求毫无差别。因此,通过发送不同的命令请求,测试者能增加猜测的准确度。

3.2 测试目标

发现运行的服务器的版本和类型,来决定已知漏洞和利用方式。

3.3 操作

3.3.1 黑盒测试

最简单也是最基本的方法来鉴别web服务器就是查看HTTP响应头中的”Server”字段。下面实验中使用Netcat和Telnet:

考虑如NC下HTTP请求响应对:


考虑如Telnet下HTTP请求响应对:


在上面的例子,可以看到
从Server字段,我们可以发现服务器可能是Apache,版本1.3.3,运行在Linux系统上。

3.3.2 协议行为推断

3.3.2.1 HTTP头字段顺序

第一个方法通过观察响应头的组织顺序。每个服务器都有一个内部的HTTP头排序方法,考虑如下例子:


IIS 7.5 响应


Netscape Enterprise 4.1 响应

3.3.2.2 畸形的请求测试

另一个有用测试是发送畸形的请求或者不存在的页面请求,考虑如下HTTP响应: Consider the following HTTP responses.
Apache 1.3.23


IIS 7.5

3.4 测试工具

httprint – http://net-square.com/httprint.html
httprecon – http://www.computec.ch/projekte/httprecon/
Netcraft – http://www.netcraft.com
Desenmascarame – http://desenmascara.me

3.5 建议

使用加强的反向代理服务器来保护Web服务器的展示层。

混淆Web服务器展示层的头信息。

4 web服务器元文件信息发现 (OTG-INFO-003)

4.1 描述

从robots.txt中发现泄露的web应用路径信息。更进一步,这些应该被蜘蛛、机器人和网页抓取软件忽略的目录列表能很好地作为建立应用流程的参考。
## 4.2 测试目标

  • 1.web应用路径或者文件夹泄露信息。
  • 2.建立被蜘蛛机器人忽略的目录列表。
    ## 4.3 操作

4.3.1robots.txt

Web蜘蛛、机器人和网页抓取软件通过获取页面,递归遍历超链接来获取更多的网页内容。他们的行为应该遵循在网站根目录下robots.txt所定义的机器人排除协议。


有时候,Web蜘蛛机器人可以故意忽略robots.txt中的Disallow指令所规定的内容,robots.txt不应该当做一个强制约束机制来控制第三方访问这些web页面。
– 获取根目录下的robots.txt- 使用”wget” 或 “curl”
robots.txt文件能从web服务器根目录下获得。例如使用”wget”或”curl”获取www.google.com的robots.txt文件:


使用Google Webmaster 工具分析 robots.txt
网站拥有者们可以使用”Google Webmaster Tools”工具中的”Analyze robots.txt”功能来分析网站结构。这个工具能帮助测试,使用方式如下:

  • 使用Google帐号登陆Google Webmaster Tools;
  • 在操作面板中输入待分析网站URL;
  • 根据指示选择合适的功能。

4.3.2 元标签(META)

标签位于HTML文档的HEAD区域内,应该与网站整体内容保持一致以防蜘蛛机器人从其他地方开始抓取,并非从根页面,例如”deep link”。

4.4 工具

  • Browser (View Source function)
  • curl
  • wget
  • rockspider

5 服务器应用应用枚举 (OTG-INFO-004)

5.1 描述

测试Web应用漏洞的一个重要步骤是寻找出运行在服务器上的流行应用程序。许多应用程序存在已知漏洞或者已知的攻击手段来获取控制权限或者数据。此外,许多应用往往被错误配置,而且没有更新。他们被认为是“内部”使用,所以没有威胁存在。
随着虚拟web服务的大量使用,传统一个IP地址与一个服务器一一对应的传统形式已经失去了最初的重要意义。多个网站或应用解析到同一个IP地址并不少见。这样的场景不局限于主机托管环境,也应用在平常的合作环境。
安全专家有时候被给与了一系列IP地址作为测试目标。可能会有争议,这个场景更接近渗透测试类型的任务,但是无论何种情况,类似的任务都希望测试目标地址中所有可以访问到的应用。问题是所给IP地址在80端口运行了一个HTTP服务,但是测试者通过指定IP地址(仅有的信息)访问却得到“没有web服务器被配置”或类似的消息。当访问不相关的域名(DNS)时,系统可能拒绝访问。显而易见,一定程度的分析工作极大影响测试任务,不然只能仅仅测试他们所意识到的系统。
有时候,测试目标的描述会更加丰富。测试者给予一系列IP地址以及相关的域名。当然,这个列表可能只传递了部分信息,例如它可能忽略部分域名,客户也可能根本没意识到这个问题(这在大型组织中往往很常见)。
其他影响测试范围的问题还表现在Web应用程序发布了不明显的URL,例如(http://www.example.com/some-strange-URL) ,哪儿都访问不到这个地址。出现这样的地址可能由于偶然错误,比如错误配置,也可能是故意而为,比如不公开的管理接口。

为了发现这些问题,我们需要实施web应用发现。

5.2 测试目标

枚举web服务器上存在的应用程序

5.3 如何测试

5.3.1 黑盒测试

Web应用发现是一个在给定基础条件情况下鉴别Web应用程序的过程。一定基础条件往往是一系列IP地址(可能是一个网段),也可能是一系列DNS解析名称,也可能是两者混合。 这些信息往往是项目开始之前中最先给出的内容,无论在一个典型渗透测试或者是应用评估任务中。在这两种案例中,除非是合约条款中明确指出(例如,仅测试指定应用URL http://www.example.com/),否则测试应该力求最复杂的范围,比如应该识别出目标的所有应用访问入口。下面的例子展示了一些达成这个目标的技巧。

注意: 一些技巧是应用于互联网Web服务器、DNS服务器、反向IP搜索服务以及搜索引擎。文中例子所使用的私有ip地址(如192.168.1.100)仅仅是为了匿名需要指代表示 通用 IP地址。

应用的数量与所给的域名或IP的关系受到三个因素的影响:

5.3.1.1 不同的基本 URL

一个web应用明显的入口是 www.example.com, 也就是说,这个缩写表明我们认为这个Web应用最初的入口在http://www.example.com/ (HTTPS也一样)。然而即使这是常见情况,但是也没任何强制的措施要求应用程序一定要从“/”开始。

例如,下面这些相同域名下的链接可能表示了三个不同的应用:

http://www.example.com/url1
http://www.example.com/url2
http://www.example.com/url3
在这个例子中,URL地址 http://www.example.com/ 并没有分配到一个有意义的页面,有三个应用被“隐藏”了,除非测试者明确清楚如何访问他们,就是说需要明确知道url1, url2 和 url3。往往不会像这样发布web应用,除非拥有者不希望他们被正常访问,只将特定的地址通知特定的用户。这不意味着这些地址是秘密的,只是他们存在的确切地址没有被明确公布而已。

5.3.1.2 非标准端口

Web应用常常使用80端口(http)和443端口(https),但是这些端口号没有什么特殊之处。事实上,web应用可以关联任意TCP端口,能通过如下方式为http[s]:www.wxample.com:port/指定端口。比如,http://www.example.com:20000/。

5.3.1.3 虚拟主机

DNS允许单个IP地址被关联多个域名。例如,IP地址 192.168.1.100 可能关联 www.example.com, helpdesk.example.com, webmail.example.com 等域名。没有必要所有名字都属于相同的DNS域名。这个一对多的关系来提供不同的网页内容的技术叫做虚拟主机。识别虚拟主机的信息涵在HTTP 1.1标准的 Host: 头中[1]。

一个人可能不会意识到除了明显的www.example.com 之外还存在其他web应用,除非他们知道 helpdesk.example.com 和 webmail.example.com。

对抗因素1 – 非标准URL地址

没有完全确定非标准命名的URL的web应用的方法。因为不是标准化,没有固定的规范来指导命名规则,但是有一些技巧能帮助测试者获取额外的信息。
首先如果web服务器被错误配置成允许目录浏览,,可以通过这点来发现其他应用。漏洞扫描器可以在这里提供帮助。
其次,这些应用可能被其他web页面引用,就有机会被蜘蛛机器人和搜素引擎收录。如果测试者怀疑有隐藏的应用存在在www.example.com中,可以使用 site 操作符来搜索结果,“site: www.example.com”。在返回结果中可以能存在指向这些不明显的应用。

另一个发现未发布的应用的方法是提供一个候选列表。例如,一个web邮件应用前端往往能通过类似 https://www.example.com/webmail, https://webmail.example.com/, 或 https://mail.example.com/ 之类的URL进行访问。这种方法也能应用于管理界面,它也可能作为隐藏页面发布(比如Tomcat管理接口),没有被其他地方链接。所以使用一些基于字典的查找方法(或“聪明的猜测”)能获得一些结果。漏洞扫描器也能在这方面提供帮助。

** 对抗因素2 – 非标准端口**

发现非标准端口上的应用是非常简单的。一个端口扫描器,比如namp[2]就能通过-sV选项胜任这项服务识别工作,它也能识别任意端口上的http[s]服务。这可能需要完整扫描64k的TCP端口地址空间。
下面例子中的命令会使用TCP连接扫描技术寻找IP 192.168.1.100 的所有TCP端口,并识别这些端口上的服务。(nmap有着许多选项,我们只列出了必需的选择,其他内容超出了本章范围。)


检查输出寻找http或者潜在的SSL包装服务(这些往往能被确认为https)就十分足够了。下面是上一个命令输出的例子:


从这个例子中我们发现:

80端口运行这Apache Http服务器;
443端口可能运行Https服务(但是无法确定,可以通过浏览器访问https://192.168.1.100 验证);
901端口运行着Samva SWAT web界面;
1241端口运行的不是Https服务,而是SSL包装下的Nessus守护进程;The service on port 1241 is not https, but is the SSL-wrapped Nessus daemon.
3690显示一个未知的服务(nmap给出了它的指纹情况,在这里为了显示清晰,我们忽略了这项内容。通过文档指导,可以将这些内容提交去合并入nmap的指纹数据库,来查找到底运行着什么服务)。
8000上显示另一个未知的服务,他有可能是Http服务,因为在这个端口上Http服务很常见。下面让我们来仔细查看这个:


可以确定它是一个HTTP服务器。此外,测试这也能使用web浏览器或者使用Perl命令来模仿HTTP交互情况发送上面的GET或HEAD请求(注意HEAD请求可能不被所有浏览器支持)。

  • 8080端口运行着Apache Tomcat服务。
    漏洞扫描器也能完成同样的工作,但是扫描器的第一选择是识别非标准端口上是否运行http[s]服务。例如,Nessus能鉴别任意端口上的服务(设定扫描所有端口的任务),与nmap相比,还能提供一系列服务器已知漏洞,包括https服务的SSL配置问题。就如前面提到的,Nessus也能发现没有提到的流行的应用程序和web入口,比如Tomcat管理接口。
    ** 对抗因素3 – 虚拟主机**
    有一系列的技巧来识别给定IP x.y.z.t 下的DNS域名。

  • DNS 区域传输
    这个技巧在现在已经被限制,DNS服务器很可能拒绝区域传输。但是仍然值得一试。首先,测试者需要确定x.y.z.t的域名服务器(name server)。如果这个IP的一个域名已经已知(比如www.example.com),那么可以使用nslookup,host或者dig工具来查询DNS的NS记录来确定域名服务器。

如果不知道任何x.y.z.t的相关域名,但是测试目标定义中存在至少一个域名,测试者仍应尝试通过相同的办法来查询域名服务器(希望x.y.t.z也是被同一个域名服务器提供)。例如测试目标包括IP地址x.y.z.t和一个域名mail.example.com,可以考虑查询域名example.com的域名服务器。

下面的例子展示了如何使用host命令查询www.owasp.org的域名服务器:


区域传送可以通过向example.com的域名服务器发出请求完成。如果足够幸运,测试者能得到该域名的一系列DNS条目。这里面会包含明显的www.example.com和不明显的helpdesk.example.com与webmail.example.com(还包括其他域名)。检查所有得到的域名,并对需要评估的目标进行分析。

试着对owasp.org的一个域名服务器请求区域传输:

  • DNS 反向查询
    过程和前面类似,只不过依赖于反向(PTR)DNS记录。区别与区域传输,将记录类型设置成PTR,为IP地址发送请求。幸运的话,我们可以得到一系列DNS域名的记录。这个技巧需要服务器存在IP到域名的映射,有时无法保证这一点。

  • 基于web的DNS搜索DNS
    这种搜索更类似于DNS区域传输,但是是依赖于提供DNS查询的Web服务。比如像Netcraft Search DNS的服务,地址在 http://searchdns.netcraft.com/?host 。测试者能提交一系列域名查询请求,如example.com,会返回一系列他们获得的相关目标域名。

  • 反向IP查询服务
    反向IP查询服务类似DNS反向查询,不同之处在于测试者向web应用查询,而不是DNS服务器。有许多这样的服务网站存在,由于他们一般都返回部分结果(通常都不同),所以使用不同的服务查询会得到一个更加完善的结果。

Googling
通过之前的信息收集的技巧介绍,测试者可以通过搜索引擎精炼和加强他们的结果分析。比如证明其他目标的其他域名存在或者可以通过隐藏URL访问应用。

灰盒测试

不适用。无论从哪里开始,基本方法和黑盒测试相同。

测试工具

DNS查询工具如 nslookup, dig 等等;
搜索引擎 (Google, Bing 和其他主要搜索引擎);
定制化的DNS相关web搜索服务:见上文;
Nmap – http://www.insecure.org
Nessus Vulnerability Scanner – http://www.nessus.org
Nikto – http://www.cirt.net/nikto2

6 评论信息发现 (OTG-INFO-005)

6.1 描述

在源代码中加入详细的注释和元数据非常常见,甚至是推荐行为。但是包含在HTML代码中的这些注释往往会揭露一些内部信息,这些信息本来不应该被潜在攻击者所查阅到。注释和元数据应该被审核来确定是否有信息泄露。

6.2 测试目标

审核页面注释和元数据来更了解应用情况和发现信息泄露。

6.3 如何测试

HTML注释常用于开发者进行应用调试。有时候他们忘了了注释这件事,并将他们留到了发布环境中。测试者应该查看以<!– 开始,以–>结束的HTML注释。
黑盒测试

检查HTML源代码中的注释获得敏感信息能更好的帮助攻击者加深对应用的理解。这些信息可能是SQL语句,用户名和密码,内部IP地址或者调试信息。


测试者甚至能发现下面这些信息:


检查HTML版本信息来发现合法版本信息和数据类型定义(DTD)链接


“strict.dtd” — 默认严格的 DTD

“loose.dtd” — 宽松的 DTD

“frameset.dtd” — 框架页面的 DTD

有些元标签不能提供主动的攻击向量,但是允许攻击者获得档案信息

有些元标签改变了HTTP回应头,比如 http-equiv 设置了基于页面属性的HTTP响应头,如下所示:

</META http-equiv=”Expires” content=”Fri, 21 Dec 2012 12:34:56 GMT”>

这会导致 HTTP 头加入如下信息:

又如

会产生下面结果:

当测试页面是否执行注入漏洞时(比如CRLF攻击),这些元标签也能通过浏览器缓存来帮助决定信息泄露程度。

一个常见(但不是Web内容无障碍指南(WCAG)兼容版本)元标签就是刷新:


另一个常见元标签的使用是指定关键字给搜索引擎提高搜索结果的质量:


尽管大多数web服务器通过robots.txt来管理搜索引擎索引范围,但是也能通过元标签管理。这些标签会建议机器人不要索引和跟踪页面链接:

因特网内容选择平台 (Platform for Internet Content Selection PICS) 和 网站描述资源协议(Protocol for Web Description Resources POWDER) 提供元数据如何关联因特网页面内容的基础内容。
灰盒测试

不适用。

6.4测试工具

  • Wget
  • Browser “view source” function
  • Eyeballs
  • Curl

7 应用入口识别 (OTG-INFO-006)

7.1 描述

枚举应用和他的攻击面是一个关键的前期准备工作,应该在完全测试开展前进行,他为测试者识别了可能的弱点范围。这部分目标是一旦完成枚举映射工作,帮助识别和筹划应用中应该被详细调查的区域。

7.2 测试目标

理解请求是如何组织的,和典型的应用响应

7.3 测试

在任何测试开始前,测试者总是应该对应用程序有足够的理解,明白用户和浏览器是如何与应用通信的。随着测试者在应用中遨游,他应当特别关注于所有的HTTP请求(GET和POST方法,也叫做谓词)以及每个传递给应用的参数和表单。此外也应该注意在传参数给应用时,什么时候使用的是GET请求,什么时候又使用了POST请求。通常情况下大多数使用GET请求,但是当传送敏感信息时,往往包含在POST请求的主体中。

注意为了查看POST请求中参数,测试这可能需要使用数据劫持代理工具(比如OWASP的Zed Attack Proxy (ZAP))或者一些浏览器插件。在POST请求中,测试者应当特别注意传递给应用的任何表单隐藏域,往往他们包含一些敏感信息,这些信息可能是开发者不希望你看见或者修改的,如信息状态、物品数量、物品价格信息等等。

根据作者的经验,在这个阶段使用一个数据劫持代理和电子表格是非常有用的。代理工具能记录和追踪每一个测试者和应用之间的请求和响应。此外,测试者通常能捕获每一个请求和响应,能够清楚看到每一个发出的和返回的头、参数等等信息。这些可能有时十分乏味特别是大型交互网站(想一想银行应用)。但是经验积累会告诉你该看什么,这个过程将极大地减轻。

当测试者在漫游应用的时候,也应当注意在URL中、自定义HTTP头中或请求响应中的有趣的参数,并在电子表格中记录下来。表格中应当包含被请求的页面(或许加入代理中的请求序号来做引用会更好),有趣的参数,请求类型(POST/GET),访问是否需要认证,是否使用SSL,以及其他相关备注(如果有多个过程)。一旦每一个应用区域都被映射完成,测试者应该测试每一个他们识别出来的地方,记录是否如预期一样工作。指南剩下的部分会指导如何测试这些有趣的区域,但是这章的工作必须在任何测试正式开始前完成。

下面是通用的请求和响应中有意思的点,在请求部分,关注GET和POST方法,他往往是请求的主要部分。注意其他方法如PUT和DELETE也可能被使用。这些更加罕见的请求如果被接受,经常会产生漏洞。在指南中有特别的一个章节描述如何测试HTTP方法。

请求:

  • 识别GET请求和POST请求使用的地方。
  • 识别所有使用在POST请求中的参数(这些参数在请求主体中)。
  • 在POST请求中,特别注意隐藏参数。POST请求会在HTTP消息的主体中发送所有的表单域(包括隐藏参数)给应用。这些往往不可见,除非使用代理或者查看页面源代码。此外,隐藏属性 的值可能导致不同的后续页面、数据和访问级别。
  • 识别所有GET请求中的参数(如URL),特别是查询字符串(一般跟着?标记后)。
  • 识别查询字符串中的所有参数。这些参数往往成对出现,如foo=bar。注意一下,许多参数也能在一个查询字符串中,用&, ~, :或者其他特殊字符或编码分割。
  • 注意如果在查询字符串或POST请求中存在多个参数,需要识别执行攻击中真正需要的一些或所有参数。测试者需要识别所有参数(甚至编码过或加密过的),识别出哪些是被应用程序处理的。指南后面章节会指导你如何测试这些参数,在这里,我们只需要确认识别出每一个参数即可。
  • 注意有些附加或自定义的头不是正常情况能发现的(比如debug=False)。

响应:

识别在哪里新cookies被设置(Set-Cookie头),修改或新增。
识别出在正常访问过程中(未修改正常请求)。重定向跳转发生的地方(3xx HTTP 状态码),400 状态码,特别是403 禁止访问,和500 内部服务器错误。
也注意有些有趣的HTTP头。比如, “Server: BIG-IP” 表明这个站点被负载均衡。因此,如果一个站点是负载均衡的,而且有一个服务器没有被正确配置,那么测试者需要请求多次来访问有漏洞的服务器,取决于使用了何种负载均衡设备。
黑盒测试

测试应用入口点
下面是如何测试应用入口点的两个例子。

例1

这个例子展现一个从在线商店购买东西的GET请求。


期望结果:

这里测试者可能注意到了所有在请求中的参数如CUSTOMERID,ITEM,PRICE,IP和Cookie(用于会话状态,经过编码的参数)。

灰盒测试

通过灰盒方法来测试应用入口点包括我们已经识别出来的上文部分,再加上另外一点。在从外部数据源获取数据并处理的情况中(如SNMP捕获,syslog消息,SMTP或其他服务器的SOAP信息)。与应用开发者进行一次会谈,来识别处理功能函数,用户输入期望和输入格式。例如,开发者能帮助理解如何编写一个应用接受的正确的SOAP请求,这些web服务或其他功能可能是我们没在黑盒测试中考虑到和识别出来的。

7.4 测试工具

劫持代理:

OWASP: Zed Attack Proxy (ZAP)
OWASP: WebScarab
Burp Suite
CAT
浏览器插件:

TamperIE for Internet Explorer
Tamper Data for Firefox

8 识别应用工作流程 (OTG-INFO-007)

8.1 描述

在正式开始安全测试以前,理解应用程序的结构是非常重要的。如果没有通透地理解应用的布局情况,往往也无法彻底完成测试。

8.2 测试目标

建立目标应用程序结构图,并理解其主要工作流程

8.3 如何测试

知道,测试所有的代码路径也是非常耗时的。一直折中的办法是将发现的和测试的代码路径记录下来。

有一些办法来实施测试和测量代码覆盖率:

路径 – 测试每个应用路径,包括对决策路径进行组合测试和边界值分析测试。尽管这个方法提过了完全性,但是测试路径的数量会在每个决策分支上呈指数型增长。
数据流 (或者污点分析) – 测试外部交互(通常是用户)发生的变量赋值。专注于映射贯穿应用的数据流、数据转换和数据的使用。

竞争 – 测试多个应用并发实例操作同一个数据的情况。
权衡使用哪种测试方法应该和应用所有者进行协商。更简单的方法应该被采纳,包括询问应用所有者他们特别关心的是什么功能或代码段以及如何到达这些代码段。

  • 黑盒测试

为了向应用所有者证明代码覆盖率,测试者可以使用数据表来记录所有发现的链接(手动或自动)。然后测试者可以更仔细观察应用的决策点,并调查发现了多少重要的代码路径。把发现的这些路径的URL,截图描述等也记录进数据表。

  • 灰盒/白盒测试

在灰盒/白盒盒测试中向应用所有者保证有效的代码覆盖率要容易得多。提供和被询问到的信息足以保证代码覆盖最小要求被满足。

8.4 测试工具

Zed Attack Proxy (ZAP)

List of spreadsheet software

Diagramming software

9 识别web应用框架 (OTG-INFO-008)

9.1 描述

别是信息收集过程简单重要的子任务。知道一个已知类型的框架而且被渗透测试过,这自然而然是一个巨大的优势。除了发现在未打补丁版本中的已知漏洞,还有了解在框架中特定的错误配置和已知文件目录框架使这一识别过程变得非常重要。

一些不同开发商不同版本的web框架被广泛使用。了解框架的信息对测试过程有极大帮助,也能帮助改进测试方案。这些信息可以从一些常见的地方仔细分析推断出来。大多数的web框架有几处特定的标记,能帮助攻击者识别他们。这也是基本上所有自动化工具做的事情,他们在定义好的位置搜寻标记,与数据库已知签名做比较。通常使用多个标记来增强准确程度。

9.2 测试目标

定义使用的web框架来获得对安全测试方法论更好的理解。

9.3 如何测试

  • 黑盒测试

有好几个常见的地方来寻找当前框架:

HTTP 头
Cookies
HTML 源代码
特别的文件和目录
HTTP 头

最基本识别web框架的方式是查看HTTP响应头中的X-Powered-By字段。许多工具可以用来识别目标,最简单一个是netcat。

考虑如下HTTP请求响应对:

从X-Powered-By字段中,我们能发现web应用框架很可能是Mono。尽管这个方法简单迅速,但是不会再100%的案例中有效。很有可能,X-Powered-By头被正确的配置禁用了。还有一些技巧使网站混淆HTTP头(参见下文整改措施章节的例子)。

所以在同样的例子中,测试者可能错过X-Powered-By头,或者得到其他消息,如下所示:


有时候有更多的HTTP头指向某个确定的web框架。在下面的例子中,根据HTTP响应的头,我们能发现X-Powered-By头包含PHP版本。然而X-Generator头指出使用的实际框架是Swiftlet,这能帮助渗透测试人员扩充他的攻击向量。在实施识别的过程中,总是应该仔细调查每一个HTTP头来寻找类似信息。

9.4 整改措施

通用的建议是使用上面描述的工具并查看日志理解攻击者如何暴露web框架。通过多次扫描修改隐藏框架操作,达到一个较好的安全等级和保证框架不会被自动化扫描检测出来。下面是一些关于框架标志位置的特定建议和一些额外的有趣的方法。

HTTP 头

检查配置和禁止或者混淆所有会暴露信息的HTTP头。这里有一篇有趣的文章关于使用NetScaler混淆HTTP头的文章: http://grahamhosking.blogspot.ru/2013/07/obfuscating-http-header-using-netscaler.html

Cookies

推荐通过修改相关配置文件来改变cookie名称。

HTML 源代码

手动检查HTML代码内容,移除所有明显指向框架的内容。

通用指南:

确保没有暴露框架可视标记;
移除不需要的注释(版权,bug信息,特定框架注释);
移除生成的元标签;
使用公司自己的css和js脚本文件,不要存放在框架相关的目录;
不要使用页面默认的脚本,如果必须使用,混淆他们。
特定文件和目录

通用指南:

在服务器上移除所有不需要的和无用的文件。这意味着也包括会暴露版本信息的文本文件和安装文件。
使用404错误响应来限制从外部访问其他文件。例如这可以通过修改htaccess文件,加入重写规则 RewriteCond 和 RewriteRuleRestrict。例如,限制两个常见的WordPress文件夹的例子如下:


当然,这不是唯一限制访问的方法,有相关特定框架的插件存在来自动化这个过程。一个WordPress的例子是StealthLogin (http://wordpress.org/plugins/stealth-login-page)。
其他措施

通用指南:

  • 校验和管理
    这个措施的目的是打败基于校验和的扫描器以及不让他们通过哈希值暴露文件。通常有两个方法进行校验和管理:
    改变这些文件存在的位置(就是将他们移动到另一个文件夹,或者重命名文件夹)
    修改文件内容 – 甚至细微的修改就能导致完全不同的哈希值,所以在文件末尾添加单个字节应该不是一个大问题。
  • 制造混乱
    有个有趣且有效的方法需要从添加其他框架的伪装文件来愚弄工具盒混乱攻击者。但需要注意不要覆盖存在的文件和目录破坏现有框架。

10 识别web应用程序 (OTG-INFO-009)

10.1 描述

在世界上存在着巨大数量的免费和开源软件项目正在被积极开发和部署,很有可能一个应用安全测试将面对一个目标站点是完全或者部分依赖这些知名的应用程序(如Wedpress,phpBB,Mediawiki等等)。了解即将被测试的web应用组件将极大帮助测试过程,也会减少测试开销。这些知名的web应用程序拥有已知的HTML头,cookies,和目录结构可以被枚举来鉴别这些应用。

10.2 测试目标

鉴别Web应用程序和其版本来确定已知漏洞和可能的利用方式。

10.3 如何测试

Cookies

一个相当可靠的方法来测试web应用是检查应用特定的cookies。

考虑如下HTTP请求:


cookie CAKEPHP 被自动设置,指明了我们框架信息。在常见应用识别章节我们会列举一系列常见的cookies名称。不过,cookie名称还是有可能被改变的。

HTML 源代码
这个技巧基于在HTLM页面源代码中搜寻特征模式。通常我们能找到许多能帮助测试者识别特定web应用的信息。一个常见的地方是HTML注释直接暴露了应用信息。更常见的是应用相关的路径信息,比如链接特定应用css或者js目录。最后,特定的脚本变量也能指明特定的应用信息。

从下面的元标签,我们能轻易发现网站使用的应用程序和其版本。注释、特定路径和脚本变量都能帮助攻击者快速确定应用实例。

特定文件和路径
除了从HTML源代码里面收集到的信息,还有个方法能极大帮助攻击者确定应用程序。每个应用都有自己特定的文件和目录结构。事实表明我们能从HTML页面源代码中找到特定的路径信息,有时候他们并没有在代码中明显出现,但是仍然遗留在服务器上。

为了发现他们,一个叫dirbusting的技巧被使用。Dirbusting是通过预测目录和文件名称并监视HTTP相应来暴力破解一个目标枚举服务内容。这些信息也可以用在发现默认文件和攻击系统以及识别web应用之中。Dirbusting可以通过很多方法实现,下面的例子展示了一个成功的攻击,通过Burp Suite的intruder功能和预先定义的列表来攻击一个基于WordPress的站点。

10.4 测试工具

下面展示了一系列通用和知名的测试工具列表。出了框架识别外他们还有许多其他功能。

WhatWeb

网站: http://www.morningstarsecurity.com/research/whatweb
现在市场上最好的识别工具之一。默认包括在[Kali Linux]之中。 语言: Ruby 使用下面技巧匹配指纹库:

字符串 (大小写敏感)
正则表达式
Google Hack数据库查询(有限关键字组)
MD5哈希值
URL 识别
HTML 标签模式
自定义ruby代码,被动和主动操作.

11 绘制应用架构图 (OTG-INFO-010)

11.1 描述

错综复杂相互连通的web网络环境可能包括数以百计的web应用,这也使得配置管理和审查变成测试中的一个基本步骤,需要在每个应用中实施。事实上,只需一个漏洞就能破坏整个基础设施的安全。甚至于一个微小的,看似不重要的问题能在相同服务器上的另一个应用中演化成严重的风险。

为了定位这些问题,实施深入的配置和已知安全问题审查时极其重要的。在实施深入评审之前,有必要映射网络和应用架构。每一个构成整个网络架构的不同元素都需要了解,并弄清楚他们是如何与web应用交互的,以及他们将对安全造成何种影响。

11.2 如何测试

11.2.1 映射应用架构

映射应用架构需要通过测试来发现不同的构成应用的元件。在一些小型结构中,比如简单的基于CGI的应用,是单个服务器被用来运行web服务器,可能在上面会执行C、perl或者Shell CGI脚本,也许也有认证机制。

在一些更加复杂的结构中,比如一个在线银行系统,可能涉及到多个服务器。他们可能包括一个反向代理服务器,一个前端web服务器,一个应用程序服务器和一个数据库服务器或LDAP服务器。每个服务器都有不同的用途,可能被划分成不同网络,之间还存在着防火墙。这创建了不同DMZ区域以便获得web服务器的权限也不能获得认证服务器的远程用户权限。如此不同元素即使被攻破沦陷也会被孤立,不会造成整个架构被控制。

获得应用架构的知识可能会很简单,如果这些信息已经在应用开发者用文档形式或访谈方式提供给测试团队。但是这些信息往往在一无所知的渗透测试中很难获得。

在后一种情况中,测试者往往从一个简单的架构开始做假设(比如单个服务器)。接着,从其他测试中接收信息并推断出不同的元素,质疑先前的假设,拓展架构图。测试者可能从询问简单的问题开始,如“服务器是否有防火墙保护?”。这些问题的结果可能基于网络扫描结果和分析网络边界服务器端口过滤情况(无应答或ICMP不可达),或者服务器直接接入互联网的结果(如向所有非开放端口返回RST包)得出。这些分析也能通过网络数据包测试加强来判断防火墙类型。如这是否是一个状态防火墙或者只是路由器上的接入过滤策略?如何被配置?是否能绕过?

检测在web服务器前面的反向代理可以通过分析web服务器标志来判断,这可能直接暴露反向代理的存在(例如,返回 “WebSEAL0″[1])。这也能通过向服务器发送请求并对比服务器应答和期望应答来判断。例如,一些反向代理会充当入侵防护系统(IPS)或网络防火墙角色,来阻挡针对服务器的一些已知攻击手段。使用一些常见的Web攻击,就像一些CGI扫描器发送的一些请求,如果已知web服务器应该对这些不可用资源的请求做出404消息应答,但是事实上却返回了一个不同的错误信息,这暗示了可能有反向代理的存在(或者应用层防火墙WAF存在),他们往往会过滤请求,并返回另一个不同的错误页面。另一个例子是,如果web服务器返回一系列可用的HTTP方法(包括TRACE),但是这些方法请求却发生了错误,这可能意味着中间有设备阻挡了他们。

Check Point Firewll-1 NG 安全服务器正在保护web服务器的例子

反向代理也能作为代理缓存服务器来增加后台应用的性能。可以通过服务器头来发现这些代理。也能通过请求时间来判断,比较一系列缓存的请求和最初的请求响应时间来发现反向代理。

另一个能被检测到的系统是网络负载均衡设备。通常情况下,这些系统会通过不同的算法来将TCP/IP端口请求分配给多个服务器(轮询,web服务器负载情况,请求数量等算法)。因此检测这种架构需要检查多个请求是否被发送到相同或不同服务器上。例如,如果服务器时钟不同步可以基于Data头来判断。在一些案例中,网络负载设备可能会在HTTP头上加入新的信息来帮助他区分请求,比如AltomP cookie被Nortel的Alteon WebSystems负载均衡引入。

应用服务器通常是最容易检测的。一些资源的请求被应用服务器自己处理(不是web服务器),返回的请求头往往不同(包括不同或者额外的应答头部的值)。另一个探测这些服务器的方法是检测web服务器是否设置暗示应用服务器的cookies值(比如一些J2EE服务器提供的JSESSIONID),或者检测是否有重写URL情况来自动进行会话追踪。

认证后台(比如LDAP目录,相关数据库,或者RADIUS服务器)往往很难从外部简单检测到,因为他们往往被应用本身隐藏。

判断后端数据库可以通过浏览应用简单实现。如果有任意即时生成的动态页面,那么他们往往是应用从通过数据库排序中抓取出来的。有时候这样的信息可能揭示出后段数据库的存在。例如一个在线商店应用使用序号鉴别(id)不同的文章。但是在对应用进行盲测时,后台数据库的情况往往是能够获得的,往往通过应用中的某些漏洞接口,比如糟糕的异常处理或者对于SQL注入的反馈。

转载请注明:猫头鹰工作室 » Web应用安全测试(基于OWASP Testing)–信息收集

喜欢 (1)or分享 (0)
发表我的评论
取消评论

表情

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址