OWASP-CM-004

Application configuration management testing (OWASP-CM-004)应用配置管理测试

 

应用结构中的任何元素的正确配置都是重要的，因为这可以阻止可能危害整个架构安全的错误。

配置审查和测试在创造和维护应用结构的过程中是一个关键任务，因为如果对不同的系统使用通用配置，拿这些通用配置可能不适用于特定的网站。

典型的web和应用服务器安装保留很多设计功能（比如应用例子、文档、测试网页），这不一定为了防止安装后的注入，就在配置完后删除。

 

Black Box Testing and Examples黑盒测试和示例

Sample/known files and directories例子、已知文件和目录

许多Web服务器和应用服务器在默认安装中提供示例程序和文件。这些提供的示例有利于开发者，目的是测试在安装完成后是否正确的工作。然而，许多默认的web服务应用程序被后来证明是脆弱的。

这是个例子，CVE-1999-0449（当Exair示例安装，IIS中有拒绝服务的漏洞），CAN-2002-1744（IIS5.0 版本CodeBrws.asp中有目录遍历漏洞），CAN-2002-1630（在Oracle 9iAS 中使用sendmail.jsp），CAN-2003-1172（Apache’s Cocoon的view-source示例有目录遍历漏洞）。

 

 

CGI扫描器包含一个不同web或应用服务器提供的已知文件和目录示例的详细列表，使用CGI扫描器可以较快知道这些文件存不存在。但是，真正确定文件唯一的方法是做web服务器或者/和应用服务器的内容全面检查，确定某些文件是否与应用本身相关。

 

Comment review注释审查

在源代码中加上注释是为了编程者更好的理解一个函数的功能，这是被提倡的。当开发大型基于web的应用，编程者也会这样做。但是，在HTML中的注释可能将内部的信息暴露给潜在的攻击者。有时，甚至源代码并不再具有代码功能，而仅用于注释。但是这样的注释将泄露给非内部的用户。

注释审查应该做，目的是确定是否有任何信息通过注释被泄露了。这个检查只能通过web服务器静态的分析、动态内容检查和文件搜索实现。保存找到的内容，分析可用的HTML注释内容。

Gray Box Testing and Examples灰盒测试和示例

Configuration review配置审查

在保护网站内容中，Web服务器或者应用服务器配置很重要，必须认真审查。显然，对于不同网站策略来说，推荐配置应该是不同的，

在大多数情况下，遵循配置指南（软件供应商或外部各方提供）以确定服务器是否已被正确保护。不可能对多个特定的服务器笼统的说，服务器应该如何进行配置，但是，一些常见的准则应考虑到：

• 只需要对应用可能的服务器模块。减少攻击面。
• 处理服务器错误（40x or 50x），使用自定义页面而不是web服务器默认页面。
• 确认服务器软件在操作系统上以最小权限运行。
• 确认服务器软件记录通过合法途径正确的访问和错误的访问。
• 确保该服务器配置为正确处理超负载，禁止拒绝服务攻击。确保该服务器已表现正确调校。

 

Logging日志

记录日志是应用程序的体系结构安全的重要资产，因为它可用于检测应用程序缺陷（用户不断尝试检索不存在的文件），以及来自恶意用户的持续的攻击。

在所有的例子中（服务器和应用日志），需要测试一些项以及基于下述内容分析日志：

 

 

 

1. Do the logs contain sensitive information? 日志包含敏感信息么？
2. Are the logs stored in a dedicated server? 日志是否被保存在专用服务器上？
3. Can log usage generate a Denial of Service condition? 日志的使用是否产生一个拒绝服务攻击的条件？
4. How are they rotated? Are logs kept for the sufficient time? 日志如何轮换？是否日志被保存足够长的时间？
5. How are logs reviewed? Can administrators use these reviews to detect targeted attacks? 日志怎样被检查？管理员检查日志能够检测到有针对性的攻击？
6. How are log backups preserved? 如何保存日志备份?
7. Is the data being logged data validated (min/max length, chars etc) prior to being logged? 是否数据验证优先日志被记录？

Sensitive information in logs日志中的 敏感信息

有些应用程序可能是日志包含敏感信息，例如使用GET请求转发形式的数据将在服务器日志可见。这意味着服务器日志可能包含敏感信息（如用户名和密码，或银行账户细节）。如果该日志被攻击者获得，此敏感信息可能被攻击者滥用。例如，通过管理界面或已知的Web服务器的漏洞或错误配置（如在基于Apache的HTTP服务器中的著名server-status错误配置）

Log location日志位置

通常情况下，服务器将生成关于操作和错误的本地日志，消耗服务器运行的磁盘。但是，如果服务器被攻破，入侵者可以修改日志以清除所有的攻击和方法的痕迹。如果这种情况发生，系统管理员就没有可靠的依据获知攻击是如何发生的或攻击的来源所在。其实，大多数攻击工具都包括log zapper，log zapper是用于清理日志的，并且常常被系统级的rootkit使用。

因此，将日志保存在分离的位置而不是在Web服务器本身是明智的。

Log storage日志存储

如果日志未得到正确存储，可能引入拒绝服务攻击的条件。如果服务器没有被正确配置，日志文件将存储在操作系统的软件或应用程序本身所使用的同一个磁盘分区。这意味着，如果磁盘被填满，操作系统或应用程序可能会无法响应操作，因为它无法写在磁盘上。

通常，在UNIX系统中，日志位于/ var（虽然有些服务器可能安装在/ opt或/ usr /local）。确保包含日志的目录在单独的分区中。在某些情况下，为了防止系统日志免受影响，服务器软件本身的日志目录（比如/ var /log/在Apache web服务器）应在专用的分区存储。

这并不是说，应当允许日志填满它所在的文件系统。日志的增长应当监控，这可能会发现一个隐藏的攻击。

维持足够多的请求以测试是否日志所在的分区会被填满。在一些环境里，无论是否是GET或者POST请求都记录QUERY_STRING参数。通常，一个单独的请求只会产生少量的日志：日期、时间、源IP地址、请求的URL和服务器的结果。

Log rotation日志轮换

大部分服务器（很少的客户端应用程序）为了使其所在的文件系统不被填满而轮换日志文件。轮换日志文件基于这样一个假设——日志在有限的时间里有用。

测试这项以确保：

• Logs are kept for the time defined in the security policy, not more and not less. 基于安全策略，所需的日志被刚好保留，不多不少
• Logs are compressed once rotated (this is a convenience, since it will mean that more logs will be stored for the same available disk space) 日志仅被轮换一次，即在同一空间里，原来的日志被新的日志替换
•  文件系统对轮换日志的权限控制一致，或更严厉，以避免对轮换日志的更改影响到web服务器进程。

  当一些服务器达到一定容量的时候可能轮换日志。如果是这样，必须防止出现攻击者轮换日志以隐藏攻击的情况。

  Log review日志审查

  日志审查的目的是：检查web服务器上静态文件的使用，更是为了检查是否有攻击发生。

  需要分析错误日志文件以分析web服务器上的攻击。

  审查需要注意：

  • 大量的40x（未找到）错误消息可能标志着有人使用CGI扫描器工具对web服务器进行扫描
  • 50x（服务器错误）消息。可能标志着攻击者滥用应用的某部分导致了不可预期的错误。比如，一个SQL注入攻击可能会引起这类错误消息，当SQL查询未被正确构成并且在后端的数据库执行失败了。

  日志的统计和分析不应该在产生日志的服务器上进行。否则，攻击者可能利用web服务器的脆弱点或不正确的配置，访问它们，或者产生一些相似的信息以掩盖真实的日志。