Owasp Testing Guide v4

测试网络基础设施配置 (OTG-CONFIG-001)

综述

互相联系又多种多样的web服务器基础设施造成了内在固有的复杂情况,包括了数以百计的web应用,这使配置管理和审查变成了测试和部署每一个应用的的基础步骤。 只需要一个漏洞就能破坏整个基础设施的安全性,有时甚至一下很小的看上去不太重要的问题也可能进化成针对同一个服务器上另一个应用的严重威胁。为了找出这些问题,在已经弄清楚整个架构的情况下,做一个对已知安全问题和配置的深入审查是非常重要的。

为了保证自身应用的安全,web服务器基础设施的正确配置管理是十分重要的。如果其中一些元素,如web服务器软件,后台数据库服务器或者一些认证服务器没有被正确审查和加固,那么他们可能就会引入不希望看到的风险或者引入新的可能导致应用本身被攻破的漏洞。

举例说明,一个web服务器漏洞允许远程攻击者获得应用本身的源代码(一个在web服务器和应用服务器上发生很多次的漏洞)可能导致应用被攻破,因为匿名用户可以使用源代码中暴露出来的信息来对应用和他的用户进行攻击。

下面的步骤可能在使用在测试配置管理基础设置中:

  • 组成基础设施的不同元素应该被确定,并弄清楚他们是如何与web应用相互交互工作的以及他们会对安全造成如何影响。
  • 所有组成基础设施的元素都应该被审查,保证他们未包含任何一直漏洞。
  • 维护这些所有不同的管理员工具需要被审查。
  • 认证系统需要被审查来确保他们满足应用的需求,并且不会被外部用户恶意操作获得权限。
  • 应用程序需要使用的端口应预先形成定义列表,并纳入维护管理和变更控制措施之中。

只有当识别完成组成基础设施的所有不同元素之后(参见 Map Network and Application Architecture),才能够审查每一个元素的配置,和测试任何已知漏洞。

如何测试

已知服务器漏洞

漏洞可能在应用架构的不同区域被发现,可能在web服务器中或支撑数据库中,都能严重导致应用本身被攻破。例如,考虑一个服务器漏洞,它允许远程,未认证用户向web服务器上传文件,甚至覆盖文件。这个漏洞可能攻破应用程序,因为一个淘气的用户可能替换应用程序本身,或者引入能够影响后台服务器的代码就像其他正常应用那样运行。

如果通过盲测来审查服务器漏洞是非常困难的。在这种情况下,漏洞需要从远程站点来测试,通常使用自动化工具进行。然后,一些漏洞的测试仍然是无法预料的结果,一些取决于服务器宕机来判断测试成功与否的测试也难以操作(比如拒绝服务攻击等)。

一些自动化工具基于获取的服务器版本信息来标记漏洞情况。这可能带来误报和漏报。一方面,如果web服务器版本已经被除去或被本地管理员混淆,那么扫描器可能不会报告这个服务存在漏洞,即使事实上存在。在另一方面,生产商可能没有更新服务器版本号,但是已经修复了漏洞,扫描器可能会报告并不存在的漏洞。后一种情况往往很常见,一些操作系统开发者将一些安全漏洞补丁移植到自己的操作系统,但并没有将软件更新到最新版本。在大多数的GNU/Linux发行版中如Debian,Red Hat和SuSE中都很常见。在大多数情况下,针对应用程序架构的漏洞扫描只能发现架构中已经“暴露”出的元素的漏洞(比如web服务器),通常不能发现其他间接的元素,比如后台认证系统,支撑数据库系统或者在使用的反向代理。

最后,不是所有软件生产者公开披露漏洞情况,所以很多脆弱点并未公开在公开已知漏洞数据库中[2]。这些信息通常只披露给客户或随补丁发布,并不会发布相关建议公告。这减少了漏洞扫描工具的有用程度。通常,这些工具的漏洞覆盖率只是对通用产品比较好(如Apache服务器,微软IIS,和IBM的Lotus Domino等),针对不那么知名的产品往往不怎么理想。

这就是为什么漏洞审查在被提供了软件的内部信息后(包括版本和补丁情况)才效果最好的原因。通过这些信息,测试这可以从开发商本身获得信息,分析在架构中存在的漏洞已经这些漏洞将如何影响应用本身。如果可能,这些漏洞应该被测试来确定真实影响和查看外部元素(如入侵检测、防护系统)能否减轻或消除漏洞成功利用的可能性。测试者甚至可以确定,通过配置审查,这些漏洞可能并不存在,因为所影响的软件组件可能并没有被使用。

同样值得注意的是,开发商有时安静的修复了漏洞,包含在新软件的发布中。不同的开发商有不同的发布周期来提供支持旧的应用。拥有详细软件版本信息的测试者能分析相关旧版本软件的风险(可能不再被支持或马上要不被支持)。这是非常关键的,漏洞可能存在于不被支持的旧版本软件,系统管理人员可能不会直接注意到这一点。可能没有该版本的补丁,相关安全公告也可能不再列出该版本信息,因为不再被开发商支持。甚至在有的情况下,系统管理员意识到漏洞的存在,他们需要做一次全面的软件更新,可能需要长时间的应用宕机,甚至需要强制应用进行重新编码取决于是否和最新版本软件相容。

管理工具

任何web服务器基础设施需要管理工具来维护和更新应用。这些更新信息包括静态页面(web网页,图形文件),应用源代码,用户认证数据库等等。管理工具视不同站点、技术和使用的软件而不同。例如,有些web服务器通过管理接口进行管理,他们同时也是web服务器(如iPlanet web 服务器),或者通过明文文本配置文件进行管理(如Apache[3]),或使用操作系统图形工具(如微软IIS服务器和ASP.Net)。

在大多数情况下服务器会使用不同的文件维护工具来处理配置,可能通过FTP服务器、WebDAV、网络文件系统(NFS、CIFS)或其他机制传输。显然,组成架构的元素的操作系统也能通过这些工具来管理。应用也可能存在内嵌的管理接口来管理自身数据(用户,内容等等)。

在识别出管理架构中不同部分的管理接口后,审查这些接口是非常重要的,因为如果攻击者能够访问任一管理接口,那么他就可能攻破或破坏应用架构体系。审查时,做到下面这些是非常重要的:

  • 确定访问这些接口的控制机制。这些信息可能能在线访问到。
  • 改变默认用户名和密码。

有些公司选择不管理他们的web服务器所有部分,但是让其他机构来管理web应用发布的内容。这些外部的公司可能提供部分web内容(更新或提升新闻)或能完全管理web服务器(包括内容和代码)。通常能在互联网上发现可用的管理接口,因为使用互联网比提供专线接入应用更加便宜。在这种情况下,测试管理接口是否存在漏洞是非常重要的。

参考资料

  • [1] WebSEAL, 也叫做Tivoli Authentication Manager, 是一个来自IBM的反向代理,是Tivoli框架的一部分。
  • [2] 比如赛门铁克的Bugtraq,ISS的X-Force或NIST的国家漏洞数据库(NVD)。
  • [3] 也有一些Apache的图形管理界面(如NetLoony),但他们还没有广泛使用。