测试应用程序平台配置
总结
正确配置构成应用程序体系结构的单个元素非常重要，以防止可能危及整个体系结构安全性的错误。
审查和测试配置是创建和维护体系结构的关键任务。这是因为各种系统通常带有通用配置，这些配置可能与它们应该在安装它们的特定站点上执行的任务不一致。
虽然典型的 Web 和应用程序服务器安装将包含许多功能（如应用程序示例、文档、测试页面），但在部署之前应删除不必要的功能，以避免安装后利用。
测试目标
- 确保已删除默认文件和已知文件。
- 验证生产环境中是否没有剩余的调试代码或扩展。
- 查看为应用程序设置的日志记录机制
如何测试
黑盒测试
示例和已知文件和目录
在缺省安装中，许多 Web 服务器和应用程序服务器都为开发人员提供了示例应用程序和文件，以便测试服务器在安装后是否正常工作。但是，许多默认的 Web 服务器应用程序后来被发现容易受到攻击。例如，CVE-1999-0449（安装 Exair 示例站点时 IIS 中的拒绝服务）、CAN-2002-1744（Microsoft IIS 5.0 中 CodeBrws 中的目录遍历漏洞.asp）、CAN-2002-1630（Oracle 9iAS 中使用 sendmail.jsp）或 CAN-2003-1172（Apache Cocoon 中查看源代码示例中的目录遍历）。
CGI 扫描程序（包括由不同 Web 或应用程序服务器提供的已知文件和目录示例的详细列表）可能是确定这些文件是否存在的快速方法。但是，真正确定的唯一方法是对 Web 服务器或应用程序服务器的内容进行全面审查，并确定它们是否与应用程序本身相关。
评论评论
程序员在开发基于 Web 的大型应用程序时添加注释是很常见的。但是，HTML 代码中包含的内联注释可能会泄露攻击者不应获得的内部信息。有时，当不再需要某个功能时，源代码的一部分会被注释掉，但此注释会无意中泄漏到返回给用户的 HTML 页面。
应进行评论审查，以确定是否有任何信息通过评论泄露。只有通过分析Web服务器的静态和动态内容以及文件搜索，才能彻底完成此审查。以自动或引导方式浏览站点并存储所有检索到的内容可能很有用。然后可以搜索这些检索到的内容，以分析代码中可用的任何 HTML 注释。
系统配置
可以使用各种工具、文档或清单，使 IT 和安全专业人员详细评估目标系统是否符合各种配置基线或基准。此类工具包括但不限于以下内容：
灰盒测试
配置审查
Web 服务器或应用程序服务器配置在保护站点内容方面起着重要作用，必须仔细检查它以发现常见的配置错误。显然，建议的配置因站点策略以及服务器软件应提供的功能而异。但是，在大多数情况下，应遵循配置准则（由软件供应商或外部各方提供）来确定服务器是否已得到适当保护。
不可能笼统地说应该如何配置服务器，但是，应考虑一些常见的准则：
- 仅启用应用程序所需的服务器模块（对于 IIS 而言为 ISAPI 扩展）。这减少了攻击面，因为禁用软件模块后，服务器的大小和复杂性都会减小。它还可以防止供应商软件中可能出现的漏洞影响站点（如果这些漏洞仅存在于已禁用的模块中）。
- 使用自定义页面而不是默认 Web 服务器页面处理服务器错误（40x 或 50x）。具体要确保任何应用程序错误都不会返回给最终用户，并且不会通过这些错误泄露任何代码，因为它会帮助攻击者。忘记这一点实际上是很常见的，因为开发人员在预生产环境中确实需要这些信息。
- 确保服务器软件在操作系统中以最小化的权限运行。这可以防止服务器软件中的错误直接危害整个系统，尽管攻击者可以在将代码作为 Web 服务器运行后提升权限。
- 确保服务器软件正确记录合法访问和错误。
- 确保服务器配置为正确处理过载并防止拒绝服务攻击。确保已正确调整服务器的性能。
- 切勿授予对 applicationHost.config、redirection.config 和 administration.config（读取或写入访问权限
NT SERVICE\WMSvc）的非管理标识（除外）访问权限。这包括 Network Service, IIS_IUSRS, IUSR, 或 IIS 应用程序池使用的任何自定义标识。IIS 工作进程不应直接访问任何这些文件。
- 切勿在网络上共享 applicationHost.config、redirection.config 和 administration.config。使用共享配置时，首选将 applicationHost.config 导出到其他位置（请参阅标题为“设置共享配置的权限”的部分）。
- 请记住，默认情况下，所有用户都可以读取 .NET Framework
machine.config和根web.config文件。如果敏感信息仅供管理员查看，请不要在这些文件中存储。
- 加密应仅由 IIS 工作进程读取而不应由计算机上的其他用户读取的敏感信息。
- 不要授予对 Web 服务器用于访问共享
applicationHost.config的标识的写入访问权限。此标识应仅具有读取访问权限。
- 使用单独的标识将 applicationHost.config 发布到共享。不要使用此标识来配置 Web 服务器上的共享配置。
- 导出加密密钥以用于共享配置时使用强密码。
- 保持对包含共享配置和加密密钥的共享的受限访问权限。如果此共享遭到入侵，攻击者将能够读取和写入 Web 服务器的任何 IIS 配置，将流量从站点重定向到恶意源，并且在某些情况下通过将任意代码加载到 IIS 工作进程中来控制所有 Web 服务器。
- 请考虑使用防火墙规则和 IPsec 策略保护此共享，以仅允许成员 Web 服务器连接。
日志
日志记录是应用程序体系结构安全的重要资产，因为它可用于检测应用程序中的缺陷（用户不断尝试检索实际上不存在的文件）以及来自流氓用户的持续攻击。日志通常由 Web 和其他服务器软件正确生成。找到将其操作正确记录到日志中的应用程序并不常见，当它们这样做时，应用程序日志的主要目的是生成可供程序员用于分析特定错误的调试输出。
在这两种情况下（服务器和应用程序日志），都应根据日志内容测试和分析几个问题：
1.日志是否包含敏感信息？
2.日志是否存储在专用服务器中？
3.日志使用情况是否会生成拒绝服务情况？
4.它们是如何旋转的？日志是否保留了足够的时间？
5.如何查看日志？管理员是否可以使用这些评审来检测有针对性的攻击？
6.如何保留日志备份？
7.在记录之前，是否对正在记录的数据进行了验证（最小/最大长度、字符等）？
日志中的敏感信息
例如，某些应用程序可能会使用 GET 请求来转发表单数据，这些数据可以在服务器日志中看到。这意味着服务器日志可能包含敏感信息（如用户名和密码或银行帐户详细信息）。如果攻击者通过管理界面或已知的 Web 服务器漏洞或配置错误（如基于 Apache 的 HTTP 服务器中众所周知的 server-status错误配置）获取日志，则攻击者可能会滥用此敏感信息。
事件日志通常包含对攻击者有用的数据（信息泄露）或可直接用于攻击的数据：
- 调试信息
- 堆栈跟踪
- 用户名
- 组件名称
- 内部 IP 地址
- 不太敏感的个人数据（例如与指定个人相关的电子邮件地址、邮政地址和电话号码）
- 业务数据
此外，在某些司法管辖区，将一些敏感信息（如个人数据）存储在日志文件中，可能会迫使企业将适用于后端数据库的数据保护法应用于日志文件。如果不这样做，即使是在不知情的情况下，也可能受到适用的数据保护法的处罚。
敏感信息的更广泛列表是：
- 应用程序源代码
- 会话标识值
- 访问令牌
- 敏感个人数据和某些形式的个人身份信息 （PII）
- 身份验证密码
- 数据库连接字符串
- 加密密钥
- 银行账户或支付卡持有人数据
- 允许存储的安全等级高于日志记录系统的数据
- 商业敏感信息
- 在相关司法管辖区收集的信息是非法的
- 用户选择退出收集的信息，或不同意的信息，例如使用“请勿跟踪”，或同意收集的信息已过期
日志位置
通常，服务器将生成其操作和错误的本地日志，消耗运行服务器的系统的磁盘。但是，如果服务器遭到入侵，入侵者可以清除其日志，以清除其攻击和方法的所有痕迹。如果发生这种情况，系统管理员将不知道攻击是如何发生的或攻击源的位置。实际上，大多数攻击者工具包都包含一个“log zapper”，能够清理任何保存给定信息（如攻击者的IP地址）的日志，并且经常在攻击者的系统级根工具包中使用。
因此，明智的做法是将日志保存在单独的位置，而不是在 Web 服务器本身上。这还可以更轻松地聚合引用同一应用程序的不同源（例如 Web 服务器场的日志），还可以更轻松地执行日志分析（可能占用大量 CPU 资源），而不会影响服务器本身。
日志存储
日志存储不当可能会导致拒绝服务情况。任何具有足够资源的攻击者都可能能够生成足够数量的请求，这些请求将填满日志文件的分配空间（如果未明确阻止他们这样做）。但是，如果未正确配置服务器，日志文件将存储在与用于操作系统软件或应用程序本身的磁盘分区相同的磁盘分区中。这意味着，如果磁盘已满，操作系统或应用程序可能会由于无法在磁盘上写入而失败。
通常在 UNIX 系统中，日志将位于 /var 中（尽管某些服务器安装可能驻留在 /opt 或 /usr/local 中），确保存储日志的目录位于单独的分区中非常重要。在某些情况下，为了防止系统日志受到影响，服务器软件本身的日志目录（例如 Apache Web 服务器中的 /var/log/apache）应该存储在专用分区中。
这并不是说应该允许日志增长以填满它们所在的文件系统。应监视服务器日志的增长以检测此情况，因为它可能表示存在攻击。
测试此条件（在生产环境中可能存在风险）可以通过触发足够且持续数量的请求来查看是否记录了这些请求，以及是否有可能通过这些请求填满日志分区。在某些环境中，无论参数是通过 GET 还是 POST 请求生成的，都会记录QUERY_STRING参数，可以模拟大型查询，从而更快地填充日志，因为通常单个请求只会导致记录少量数据，例如日期和时间、源 IP 地址、 URI 请求和服务器结果
日志轮换
大多数服务器（但很少有自定义应用程序）将轮换日志，以防止它们填满它们所在的文件系统。日志轮换期间的假设是，其中的信息仅在有限的持续时间内是必需的。
应测试此功能，以确保：
- 日志保留在安全策略中定义的时间内，不多也不少。
- 日志在轮换后被压缩（这是一种便利，因为这意味着将为相同的可用磁盘空间存储更多日志）。
- 轮换日志文件的文件系统权限应与日志文件本身的文件系统权限相同（或更严格）。例如，Web 服务器需要写入它们使用的日志，但它们实际上并不需要写入轮换日志，这意味着可以在轮换时更改文件的权限，以防止 Web 服务器进程修改这些权限。
某些服务器可能会在日志达到给定大小时轮换日志。如果发生这种情况，必须确保攻击者无法强制日志轮换以隐藏其踪迹。
日志访问控制
事件日志信息永远不应对最终用户可见。即使是 Web 管理员也不应访问此类日志，因为它违反了职责分离控制。确保用于保护对原始日志的访问的任何访问控制架构以及提供查看或搜索日志功能的任何应用程序未与其他应用程序用户角色的访问控制架构链接。未经身份验证的用户也不应看到任何日志数据。
日志审查
查看日志不仅可用于提取 Web 服务器中文件的使用情况统计信息（这通常是大多数基于日志的应用程序所关注的），还可用于确定 Web 服务器上是否发生了攻击。
为了分析Web服务器攻击，需要分析服务器的错误日志文件。审查应集中在：
- 40x（未找到）错误消息。来自同一来源的大量这些可能表明CGI扫描仪工具正在用于Web服务器
- 50x（服务器错误）消息。这些可能表明攻击者滥用了意外失败的应用程序部分。例如，当 SQL 查询未正确构造且其在后端数据库上的执行失败时，SQL 注入攻击的第一阶段将生成这些错误消息。
不应在生成日志的同一服务器中生成或存储日志统计信息或分析。否则，攻击者可能会通过 Web 服务器漏洞或配置不当来访问它们并检索日志文件本身披露的类似信息。
引用
