2.渗透测试指南-配置与部署管理测试

已于 2025-04-27 16:27:11 修改
阅读量591 收藏 11
点赞数 24
分类专栏： 渗透测试指南 文章标签： web安全
于 2025-04-20 11:01:42 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_44232452/article/details/147362305
版权

测试网络基础设施配置

ID
WSTG - CONF - 01

总结

相互连接且异构的Web服务器基础设施本质上十分复杂，其中可能包含数百个Web应用程序，因此配置管理和审查是测试和部署每个应用程序的基本步骤。只要存在一个漏洞，就可能破坏整个基础设施的安全性，即使是看似微不足道的小问题，也可能演变成同一服务器上其他应用程序的严重风险。为了解决这些问题，在绘制出整个架构之后，对配置和已知的安全问题进行深入审查至关重要。

为了确保应用程序本身的安全，对Web服务器基础设施进行适当的配置管理非常重要。如果诸如Web服务器软件、后端数据库服务器或认证服务器等元素没有得到适当的审查和保护，它们可能会引入不必要的风险或新的漏洞，从而危及应用程序本身。

例如，一个允许远程攻击者泄露应用程序源代码的Web服务器漏洞（这种漏洞在Web服务器和应用程序服务器中都多次出现过）可能会危及应用程序，因为匿名用户可以利用源代码中泄露的信息对应用程序或其用户发起攻击。

测试配置管理基础设施需要采取以下步骤：

  • 确定构成基础设施的不同元素，以便了解它们如何与Web应用程序交互以及如何影响其安全性。
  • 审查基础设施的所有元素，确保它们不包含任何已知的漏洞。
  • 审查用于维护所有不同元素的管理工具。
  • 审查认证系统，确保它们满足应用程序的需求，并且不能被外部用户操纵以获取访问权限。
  • 维护一份应用程序所需的定义端口列表，并对其进行变更控制。

在绘制出构成基础设施的不同元素之后（参见[映射网络和应用程序架构](…/01 - Information_Gathering/10 - Map_Application_Architecture.md)），就可以审查每个找到的元素的配置，并测试是否存在任何已知的漏洞。

测试目标

  • 审查网络中设置的应用程序配置，并验证它们不存在漏洞。
  • 验证所使用的框架和系统是安全的，不会因软件未维护、默认设置和凭据而容易受到已知漏洞的影响。

测试方法

已知的服务器漏洞

应用程序架构各个方面的漏洞，无论是在Web服务器还是后端数据库中，都可能严重危及应用程序。例如，考虑一个允许远程未认证用户向Web服务器上传文件甚至替换现有文件的服务器漏洞。这个漏洞可能会危及应用程序，因为恶意用户可能能够替换应用程序本身或引入会影响后端服务器的代码，因为其应用程序代码将像其他任何应用程序一样运行。

如果需要通过盲渗透测试来进行服务器漏洞审查，这可能会很困难。在这些情况下，通常需要使用自动化工具从远程站点测试漏洞。然而，测试某些漏洞可能会对Web服务器产生不可预测的结果，而测试其他漏洞（如直接涉及拒绝服务攻击的漏洞）可能由于测试成功后会导致服务停机而无法进行。

一些自动化工具会根据它们检索到的Web服务器版本标记漏洞。这会导致误报和漏报。一方面，如果本地站点管理员删除或隐藏了Web服务器版本，即使服务器存在漏洞，扫描工具也不会将其标记为易受攻击。另一方面，如果软件供应商在修复漏洞时不更新Web服务器版本，扫描工具会标记实际上不存在的漏洞。后一种情况实际上非常常见，因为一些操作系统供应商会将安全漏洞补丁反向移植到他们在操作系统中提供的软件中，但不会完全更新到最新的软件版本。这种情况在大多数GNU/Linux发行版中都会发生，如Debian、Red Hat和SuSE。在大多数情况下，对应用程序架构进行漏洞扫描只能发现与架构中“暴露”元素（如Web服务器）相关的漏洞，通常无法发现与未直接暴露的元素（如认证后端、后端数据库或反向代理[1]）相关的漏洞。

最后，并非所有软件供应商都会公开披露漏洞，这意味着这些弱点可能不会在已知的漏洞数据库[2]中注册。这些信息仅会披露给客户，或者通过没有附带公告的修复程序发布。这降低了漏洞扫描工具的有效性。通常，这些工具对常见产品（如Apache Web服务器、Microsoft IIS或IBM的Lotus Domino）的漏洞覆盖情况会很好，但对不太知名的产品则会有所欠缺。

因此，当测试人员获得有关软件的内部信息（包括版本、发布版本和应用的补丁）时，进行漏洞审查是最好的方法。有了这些信息，测试人员可以从供应商那里获取数据，分析架构中潜在的漏洞以及它们对应用程序的潜在影响。在可能的情况下，可以测试这些漏洞以确定它们的实际影响，并检测是否存在任何外部元素（如入侵检测或预防系统）可能会降低或消除成功利用漏洞的可能性。测试人员甚至可以通过配置审查确定漏洞实际上并不存在，因为它影响的是未使用的软件组件。

还值得注意的是，供应商有时会默默地修复漏洞，并在新的软件版本中提供这些修复。不同的供应商有不同的发布周期，这决定了他们对旧版本的支持程度。了解架构所使用软件版本详细信息的测试人员可以分析使用短期内可能不受支持或已经不受支持的旧软件版本所带来的风险。这一点至关重要，因为如果不受支持的旧软件版本中出现漏洞，系统人员可能不会直接意识到这一点。不会有针对该漏洞的补丁可用，公告也可能不会将该版本列为易受攻击，因为它已经不再受支持。即使他们意识到了漏洞和相关的系统风险，也需要完全升级到新的软件版本，这可能会导致应用程序架构出现重大停机时间，或者由于与最新软件版本不兼容而需要对应用程序进行重新编码。

管理工具

任何Web服务器基础设施都需要存在管理工具来维护和更新应用程序使用的信息。这些信息包括静态内容（网页、图形文件）、应用程序源代码、用户认证数据库等。所使用的管理工具类型可能因具体站点、技术或软件而异。例如，一些Web服务器将使用本身就是Web服务器的管理界面进行管理（如iPlanet Web服务器），或者通过纯文本配置文件进行管理（如Apache的情况[3]），或者使用操作系统的图形用户界面（GUI）工具（如使用Microsoft的IIS服务器或ASP.Net时）。

在大多数情况下，服务器配置由各种文件维护工具管理，通过FTP服务器、WebDAV、网络文件系统（NFS、CIFS）或其他机制进行管理。显然，构成应用程序架构的元素的操作系统也将使用其他工具进行管理。应用程序可能还包含用于管理应用程序数据（用户、内容等）的嵌入式管理界面。

在绘制出用于管理架构不同部分的管理界面之后，对其进行审查非常重要。如果攻击者获得了对这些界面的访问权限，他们可能会危及或破坏应用程序架构。为了实现这一点，重要的是：

  • 确定控制对这些界面访问的机制及其相关的易受攻击点。这些信息可能可以在网上获取。
  • 确保更改默认的用户名和密码。

一些公司选择不管理其Web服务器应用程序的所有方面，可能会将内容管理委托给其他方。这个外部公司可能只提供部分内容（如新闻更新或促销活动），或者可能完全管理Web服务器（包括内容和代码）。在这些情况下，通常可以从互联网访问管理界面，因为使用互联网比通过仅用于管理的界面为外部公司提供一条连接到应用程序基础设施的专用线路更便宜。在这种情况下，测试管理界面是否容易受到攻击至关重要。

参考资料

  • [1] WebSEAL，也称为Tivoli认证管理器，是IBM的一种反向代理，是Tivoli框架的一部分。
  • [2] 如Symantec的Bugtraq、ISS的X - Force或NIST的国家漏洞数据库（NVD）。
  • [3] 有一些基于GUI的Apache管理工具（如NetLoony），但它们尚未广泛使用。

测试应用平台配置

编号
WSTG - CONF - 02

总结

构成应用程序架构的各个单一元素的正确配置非常重要，可防止出现可能危及整个架构安全的错误。

审查和测试配置是创建和维护架构的关键任务。这是因为各种系统通常带有通用配置，这些配置可能与它们在特定安装站点上要执行的任务不太匹配。

典型的 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 扩展）。这样可以减少攻击面，因为随着软件模块被禁用，服务器的规模和复杂性会降低。同时，也可以防止仅存在于已禁用模块中的供应商软件漏洞影响站点。
  • 使用自定义页面处理服务器错误（40x 或 50x），而不是使用默认的 Web 服务器页面。特别要确保任何应用程序错误不会返回给最终用户，并且不会通过这些错误泄露代码，因为这会帮助攻击者。实际上，开发人员在预生产环境中确实需要这些信息，因此很容易忘记这一点。
  • 确保服务器软件在操作系统中以最小化的权限运行。这可以防止服务器软件中的错误直接危及整个系统，尽管攻击者在以 Web 服务器身份运行代码时可能会提升权限。
  • 确保服务器软件正确记录合法访问和错误。
  • 确保服务器配置为正确处理过载情况，并防止拒绝服务攻击。确保服务器已进行适当的性能调优。
  • 除 NT SERVICE\WMSvc 外，切勿授予非管理员身份对 applicationHost.config、redirection.config 和 administration.config 的访问权限（读取或写入）。这包括 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）
  • 认证密码
  • 数据库连接字符串
  • 加密密钥
  • 银行账户或支付卡持有人数据
  • 安全级别高于日志记录系统允许存储级别的数据
  • 商业敏感信息
  • 在相关司法管辖区非法收集的信息
  • 用户选择不收集或未同意收集的信息（例如使用“请勿跟踪”功能，或同意收集的期限已过）

日志位置

通常，服务器会在本地生成其操作和错误日志，占用服务器运行所在系统的磁盘空间。然而，如果服务器被攻破，入侵者可能会清除其日志，以消除攻击的所有痕迹和方法。如果发生这种情况，系统管理员将无法了解攻击是如何发生的，也不知道攻击源在哪里。实际上，大多数攻击者工具包都包含一个“日志清除器”，能够清除包含给定信息（如攻击者的 IP 地址）的任何日志，并且通常会在攻击者的系统级根工具包中使用。

因此，明智的做法是将日志存储在单独的位置，而不是 Web 服务器本身。这也使得聚合来自不同源但与同一应用程序相关的日志（如 Web 服务器群集的日志）更加容易，并且在不影响服务器本身的情况下进行日志分析（可能会占用大量 CPU 资源）也更加方便。

日志存储

日志存储不当可能会导致拒绝服务情况。任何有足够资源的攻击者都可能能够产生足够多的请求，从而填满分配给日志文件的空间，除非有专门的预防措施。然而，如果服务器配置不当，日志文件将存储在与操作系统软件或应用程序本身相同的磁盘分区上。这意味着如果磁盘空间被填满，操作系统或应用程序可能会因无法在磁盘上写入而失败。

通常在 UNIX 系统中，日志会位于 /var 目录（尽管某些服务器安装可能位于 /opt 或 /usr/local），确保日志存储的目录位于单独的分区非常重要。在某些情况下，为了防止系统日志受到影响，服务器软件本身的日志目录（如 Apache Web 服务器的 /var/log/apache）应存储在专用分区中。

这并不是说应该允许日志增长到填满它们所在的文件系统。应监控服务器日志的增长，以检测这种情况，因为这可能表明存在攻击。

在生产环境中测试这种情况可能存在风险，可以通过发送足够多且持续的请求来进行测试，以查看这些请求是否被记录，以及是否有可能通过这些请求填满日志分区。在某些环境中，无论查询字符串参数是通过 GET 还是 POST 请求产生的都会被记录，此时可以模拟大查询，这样可以更快地填满日志，因为通常单个请求只会记录少量数据，如日期和时间、源 IP 地址、URI 请求和服务器结果。

日志轮转

大多数服务器（但很少有自定义应用程序）会轮转日志，以防止它们填满所在的文件系统。日志轮转的假设是其中的信息仅在有限的时间内是必要的。

应测试此功能，以确保：

  • 日志按照安全策略中定义的时间保存，不多也不少。
  • 日志轮转后进行压缩（这很方便，因为这意味着在相同的可用磁盘空间内可以存储更多的日志）。
  • 轮转后日志文件的文件系统权限应与日志文件本身的权限相同（或更严格）。例如，Web 服务器需要写入它们使用的日志，但实际上不需要写入轮转后的日志，这意味着可以在轮转时更改文件的权限，以防止 Web 服务器进程修改这些文件。

某些服务器可能会在日志达到给定大小时进行轮转。如果发生这种情况，必须确保攻击者无法强制日志轮转以隐藏其踪迹。

日志访问控制

事件日志信息绝不应该对最终用户可见。即使是 Web 管理员也不应访问此类日志，因为这违反了职责分离控制。确保用于保护对原始日志的访问的任何访问控制方案，以及任何提供查看或搜索日志功能的应用程序，都不与其他应用程序用户角色的访问控制方案相关联。任何日志数据也不应向未经过身份验证的用户可见。

日志审查

审查日志不仅可用于提取 Web 服务器中文件的使用统计信息（这通常是大多数基于日志的应用程序关注的重点），还可用于判断 Web 服务器是否正在遭受攻击。

为了分析 Web 服务器攻击情况，需要对服务器的错误日志文件进行分析。审查应重点关注以下方面：

  • 40x（未找到）错误消息。如果大量此类消息来自同一来源，可能表明有攻击者正在使用 CGI 扫描工具对 Web 服务器进行扫描。
  • 50x（服务器错误）消息。这些消息可能意味着攻击者正在利用应用程序中某些意外出错的部分。例如，在 SQL 注入攻击的初始阶段，如果 SQL 查询构造不当，在后端数据库执行失败时就会产生此类错误消息。

日志统计信息或分析结果不应在生成日志的同一台服务器上生成或存储。否则，攻击者可能会通过 Web 服务器漏洞或配置不当获得对这些信息的访问权限，并获取与日志文件本身所披露的相似信息。

参考资料

测试敏感信息的文件扩展名处理

编号
WSTG - CONF - 03

概述

Web 服务器通常使用文件扩展名来确定需要使用哪些技术、语言和插件来处理 Web 请求。虽然这种行为符合 RFC 标准和 Web 规范，但使用标准文件扩展名会为渗透测试人员提供有关 Web 应用底层技术的有用信息，并且大大简化了确定针对特定技术的攻击场景的任务。此外，Web 服务器的配置错误很容易泄露有关访问凭证的机密信息。

在将文件上传到服务器之前，通常会进行文件扩展名检查以验证文件。无限制的文件上传可能会导致不可预见的结果，因为文件内容可能并非预期的内容，或者是由于操作系统对文件名的意外处理。

了解 Web 服务器如何处理不同扩展名的文件请求，可以根据所访问的文件类型来明确服务器的行为。例如，这有助于了解哪些文件扩展名会以文本或纯文本形式返回，哪些会导致服务器端执行。后者表明了 Web 服务器或应用服务器所使用的技术、语言或插件。这些信息可能会进一步揭示 Web 应用的设计方式。例如，“.pl”扩展名通常与服务器端 Perl 支持相关联，但仅文件扩展名可能会产生误导，不能完全代表底层技术。例如，用 Perl 编写的服务器端资源可能会被重命名以掩盖 Perl 的使用。有关识别服务器端技术和组件的更多信息，请参阅下一节“Web 服务器组件”。

测试目标

  • 暴力破解可能包含原始数据（如脚本、凭证等）的敏感文件扩展名。
  • 验证是否不存在绕过已设置规则的系统框架漏洞。

测试方法

强制浏览

提交具有不同文件扩展名的请求，并验证服务器如何处理这些请求。验证应按 Web 目录进行。验证允许脚本执行的目录。可以使用扫描工具来识别 Web 服务器目录，这些工具会查找已知目录的存在。此外，镜像网站结构有助于测试人员重建应用程序所提供的目录树。

如果 Web 应用程序架构采用负载均衡，那么评估所有 Web 服务器就很重要。此任务的难易程度取决于负载均衡基础设施的配置。在具有冗余组件的基础设施中，各个 Web 服务器或应用服务器的配置可能会有细微差异。如果 Web 架构采用异构技术（例如，在负载均衡配置中同时使用 IIS 和 Apache Web 服务器，这可能会导致它们之间出现轻微的不对称行为，并可能存在不同的漏洞），就可能会出现这种情况。

示例

测试人员发现存在一个名为 connection.inc 的文件。直接访问该文件会返回其内容，如下所示：

<?
    mysql_connect("127.0.0.1", "root", "password")
        or die("Could not connect");
?>

测试人员由此确定存在一个 MySQL 数据库管理系统后端，以及 Web 应用程序用于访问该数据库的弱凭证。

以下文件扩展名绝不应由 Web 服务器返回，因为它们对应的文件可能包含敏感信息，或者没有合理的理由对外提供这些文件：

  • .asa
  • .inc
  • .config

以下文件扩展名对应的文件在被访问时，会由浏览器显示或下载。因此，必须检查这些扩展名的文件，以验证它们确实应该被提供（而不是遗留文件），并且不包含敏感信息：

  • .zip、.tar、.gz、.tgz、.rar 等：（压缩）存档文件
  • .java：没有理由提供对 Java 源文件的访问权限
  • .txt：文本文件
  • .pdf：PDF 文档
  • .docx、.rtf、.xlsx、.pptx 等：办公文档
  • .bak、.old 以及其他表示备份文件的扩展名（例如，Emacs 备份文件的 ~）

上面列出的只是一些示例，因为文件扩展名太多，无法在此全面涵盖。有关更全面的扩展名数据库，请参考 FILExt。

为了识别具有给定扩展名的文件，可以采用多种技术。这些技术包括使用漏洞扫描器、爬虫和镜像工具，以及查询搜索引擎（请参阅 测试：爬虫和谷歌搜索）。手动检查应用程序也很有帮助，因为它可以克服自动爬虫的局限性。另请参阅 测试旧文件、备份文件和未引用文件，该文档讨论了与“被遗忘”文件相关的安全问题。

文件上传

Windows 8.3 旧版文件处理有时可用于绕过文件上传过滤器。

使用示例：

  1. file.phtml 会被作为 PHP 代码处理。
  2. FILE~1.PHT 会被提供，但不会由 PHP ISAPI 处理程序处理。
  3. shell.phPWND 可以被上传。
  4. SHELL~1.PHP 会被操作系统外壳展开并返回，然后由 PHP ISAPI 处理程序处理。

灰盒测试

对文件扩展名处理的白盒测试包括检查 Web 应用程序架构中的服务器配置，并验证提供不同文件扩展名的规则。

如果 Web 应用程序依赖于负载均衡的异构基础设施，要确定这是否会导致不同的行为。

工具

漏洞扫描器（如 Nessus 和 Nikto）可检查已知 Web 目录的存在。它们可能允许测试人员下载网站结构，这在确定 Web 目录的配置以及各个文件扩展名的提供方式时很有帮助。其他可用于此目的的工具包括：

  • wget
  • curl
  • 在 Google 上搜索“Web 镜像工具”

审查旧备份文件和未引用文件中的敏感信息

编号
WSTG - CONF - 04

概述

虽然Web服务器中的大多数文件由服务器直接处理，但找到未引用或被遗忘的文件并不罕见，这些文件可能会泄露有关基础设施或凭证的重要信息。

最常见的情况包括：存在被重命名的旧版本修改文件、被加载到所选编程语言中并作为源代码下载的包含文件，甚至是以压缩存档形式存在的自动或手动备份文件。应用程序所托管的底层文件系统也可能自动生成备份文件，这种功能通常被称为“快照”。

所有这些文件可能会让测试人员了解到应用程序的内部工作机制、后门、管理界面，甚至是连接到管理界面或数据库服务器的凭证。

一个重要的漏洞来源是与应用程序无关的文件。这些文件可能在编辑应用程序文件时创建，生成临时备份副本，或者在Web目录树中遗留旧的或未引用的文件。在生产Web服务器上进行就地编辑或其他管理操作时，可能会无意中留下备份副本，这些副本可能是编辑器在编辑文件时自动生成的，也可能是管理员将一组文件压缩成备份时创建的。

很容易忘记这些文件，这可能会对应用程序构成严重的安全威胁。这是因为备份副本的文件扩展名可能与原始文件不同。我们创建（并可能遗忘）的 .tar、.zip 或 .gz 存档文件显然具有不同的扩展名，许多编辑器创建的自动副本也是如此（例如，Emacs在编辑 file 时会生成一个名为 file~ 的备份副本）。手动复制文件也可能产生类似的效果，比如将 file 复制为 file.old。应用程序所在的底层文件系统可能会在你不知情的情况下，在不同时间点为你的应用程序创建“快照”，这些快照也可能通过Web访问，从而对应用程序构成类似但不同的“备份文件”式威胁。

因此，这些操作会生成应用程序不需要的文件，Web服务器可能会以与原始文件不同的方式处理这些文件。例如，如果我们复制 login.asp 并将其命名为 login.asp.old，而没有采取适当的安全措施，那么用户可能会下载 login.asp 的源代码。这是因为 login.asp.old 通常会以文本或纯文本形式提供，而不是因为其扩展名而被执行。换句话说，访问 login.asp 会执行 login.asp 的服务器端代码，而访问 login.asp.old 会将 login.asp.old 的内容（同样是服务器端代码）直接返回给用户，并在浏览器中显示。这可能会带来安全风险，因为敏感信息可能会被泄露。

一般来说，暴露服务器端代码是个糟糕的做法。这不仅会不必要地暴露业务逻辑，还可能在不知不觉中泄露与应用程序相关的信息，这些信息可能会帮助攻击者（如路径名、数据结构等）。更不用说有太多脚本以明文形式嵌入了用户名和密码（这是一种粗心且极其危险的做法）。

未引用文件的其他原因与设计或配置选择有关，这些选择允许将各种与应用程序相关的文件（如数据文件、配置文件、日志文件）存储在Web服务器可以访问的文件系统目录中。这些文件通常没有理由存放在可以通过Web访问的文件系统空间中，因为它们应该仅在应用程序层面由应用程序本身访问（而不是由随意浏览的普通用户访问）。

威胁

旧的、备份的和未引用的文件对Web应用程序的安全构成了各种威胁：

  • 敏感信息泄露：未引用的文件可能会泄露敏感信息，从而便于对应用程序进行有针对性的攻击。例如，包含数据库凭证的包含文件、包含对其他隐藏内容引用的配置文件、绝对文件路径等。
  • 隐藏功能被利用：未引用的页面可能包含强大的功能，可用于攻击应用程序。例如，一个未在公开内容中链接的管理页面，但任何知道其位置的用户都可以访问。
  • 旧漏洞仍可利用：旧文件和备份文件可能包含在较新版本中已修复的漏洞。例如，viewdoc.old.jsp 可能包含一个目录遍历漏洞，该漏洞在 viewdoc.jsp 中已修复，但任何找到旧版本的人仍可利用它。
  • 源代码泄露：备份文件可能会泄露为在服务器上执行而设计的页面的源代码。例如，请求 viewdoc.bak 可能会返回 viewdoc.jsp 的源代码，可以对其进行审查，以发现通过盲目请求可执行页面可能难以发现的漏洞。虽然这种威胁适用于Perl、PHP、ASP、shell脚本、JSP等脚本语言，但并不局限于此，下一点中的示例将说明这一点。
  • 应用信息被枚举：备份存档可能包含Web根目录内（甚至外部）所有文件的副本。这使得攻击者可以快速枚举整个应用程序，包括未引用的页面、源代码、包含文件等。例如，如果你忘记了一个名为 myservlets.jar.old 的文件，其中包含你的Servlet实现类的备份副本，那么你就暴露了大量敏感信息，这些信息可以被反编译和逆向工程。
  • 旧逻辑引发错误：在某些情况下，复制或编辑文件会修改文件名，但保留文件扩展名。这在Windows环境中很常见，文件复制操作会生成以“Copy of ”或其本地化版本开头的文件名。由于文件扩展名未改变，这不是Web服务器将可执行文件作为纯文本返回的情况，因此不属于源代码泄露。然而，这些文件也很危险，因为它们可能包含过时和不正确的逻辑，当调用这些逻辑时，可能会触发应用程序错误，如果启用了诊断消息显示，攻击者可能会从中获取有价值的信息。
  • 日志文件泄露信息：日志文件可能包含有关应用程序用户活动的敏感信息，例如，URL参数中传递的敏感数据、会话ID、访问的URL（可能会泄露其他未引用的内容）等。其他日志文件（如FTP日志）可能包含有关系统管理员维护应用程序的敏感信息。
  • 快照文件存在旧漏洞：文件系统快照可能包含在较新版本中已修复的代码副本。例如，/.snapshot/monthly.1/view.php 可能包含一个目录遍历漏洞，该漏洞在 /view.php 中已修复，但任何找到旧版本的人仍可利用它。

测试目标

  • 查找并分析可能包含敏感信息的未引用文件。

测试方法

黑盒测试

对未引用文件的测试同时使用自动化和手动技术，通常包括以下几种方法的组合：

  1. 根据已发布内容的命名方案进行推断
    • 枚举应用程序的所有页面和功能。这可以使用浏览器手动完成，也可以使用应用程序爬虫工具完成。大多数应用程序使用可识别的命名方案，并使用描述其功能的词语将资源组织到页面和目录中。通常可以从已发布内容的命名方案推断出未引用页面的名称和位置。例如，如果发现了一个名为 viewuser.asp 的页面，那么还应该查找 edituser.asp、adduser.asp 和 deleteuser.asp。同样，如果发现了一个目录 /app/user，那么还应该搜索 /app/admin 和 /app/manager。
  2. 从已发布内容中寻找其他线索
    • 许多Web应用程序会在已发布内容中留下线索，这些线索可以帮助发现隐藏的页面和功能。这些线索通常可以在HTML和JavaScript文件的源代码中找到。应该手动审查所有已发布内容的源代码，以识别有关其他页面和功能的线索。例如：
      • 程序员注释：程序员的注释和源代码中被注释掉的部分可能会引用隐藏内容。
<!-- <A HREF="uploadfile.jsp">Upload a document to the server</A> -->
<!-- Link removed while bugs in uploadfile.jsp are fixed          -->

    - **JavaScript链接**：JavaScript可能包含仅在特定情况下在用户界面中呈现的页面链接。

var adminUser=false;
if (adminUser) menu.add (new menuItem ("Maintain users", "/admin/useradmin.jsp"));

    - **隐藏表单**：HTML页面可能包含通过禁用提交元素而隐藏的表单。

<form action="forgotPassword.jsp" method="post">
    <input type="hidden" name="userID" value="123">
    <!-- <input type="submit" value="Forgot Password"> -->
</form>

    - **robots.txt文件**：另一个关于未引用目录的线索来源是 `/robots.txt` 文件，该文件用于向网络爬虫提供指令。

User - agent: *
Disallow: /Admin
Disallow: /uploads
Disallow: /backup
Disallow: /~jbloggs
Disallow: /include
  1. 盲目猜测
    • 最简单的形式是，通过请求引擎运行一个常见文件名列表，尝试猜测服务器上存在的文件和目录。以下是一个netcat包装脚本，它将从标准输入读取一个单词列表，并执行基本的猜测攻击：
#!/bin/bash

server=example.org
port=80

while read url
do
echo -ne "$url\t"
echo -e "GET /$url HTTP/1.0\nHost: $server\n" | netcat $server $port | head -1
done | tee outputfile

- 根据服务器的不同，可以将 `GET` 替换为 `HEAD` 以获得更快的结果。可以对指定的输出文件进行 `grep` 操作，查找“有趣的”响应代码。响应代码200（OK）通常表示找到了有效的资源（前提是服务器不会使用200代码返回自定义的“未找到”页面）。但也要注意301（永久移动）、302（临时移动）、401（未授权）、403（禁止访问）和500（内部错误），这些代码也可能表示值得进一步调查的资源或目录。
- 基本的猜测攻击应该针对Web根目录进行，也应该针对通过其他枚举技术识别出的所有目录进行。可以按以下方式进行更高级/有效的猜测攻击：
    - **根据已知文件扩展名生成列表**：识别应用程序已知区域中使用的文件扩展名（例如JSP、ASPX、HTML），并使用附加了每个扩展名的基本单词列表（如果资源允许，也可以使用更长的常见扩展名列表）。
    - **根据已知文件名生成自定义列表**：对于通过其他枚举技术识别出的每个文件，根据该文件名创建一个自定义单词列表。获取一个常见文件扩展名列表（包括 `~`、`bak`、`txt`、`src`、`dev`、`old`、`inc`、`orig`、`copy`、`tmp`、`swp` 等），并在实际文件名的扩展名之前、之后和替换扩展名时使用每个扩展名。
- **注意事项**：Windows文件复制操作会生成以“Copy of ”或其本地化版本开头的文件名，因此它们不会更改文件扩展名。虽然“Copy of ”文件在访问时通常不会泄露源代码，但如果它们在调用时导致错误，可能会产生有价值的信息。
  1. 利用服务器漏洞和配置错误获取信息
    • 目录列表泄露：配置错误的服务器最明显的泄露未引用页面的方式是通过目录列表。请求所有枚举到的目录，以识别哪些目录提供了目录列表。
    • 服务器漏洞利用：在各个Web服务器中发现了许多漏洞，这些漏洞允许攻击者枚举未引用的内容，例如：
      • Apache的 ?M=D 目录列表漏洞。
      • 各种IIS脚本源代码泄露漏洞。
      • IIS WebDAV目录列表漏洞。
  2. 利用公开信息
    • 面向互联网的Web应用程序中未在应用程序内部引用的页面和功能，可能会在其他公共领域的来源中被引用。这些引用有多种来源：
      • 搜索引擎存档：曾经被引用过的页面可能仍然会出现在互联网搜索引擎的存档中。例如，1998results.asp 可能不再在公司网站上链接，但可能仍然存在于服务器上和搜索引擎数据库中。这个旧脚本可能包含可以用来破坏整个网站的漏洞。可以使用Google的 site: 搜索运算符仅针对所选域名运行查询，例如：site:www.example.com。以这种方式使用搜索引擎催生了一系列有用的技术，这些技术在本指南的“Google Hacking”部分有描述。备份文件不太可能被其他文件引用，因此可能没有被Google索引，但如果它们位于可浏览的目录中，搜索引擎可能会知道它们的存在。
      • 搜索引擎缓存：此外，Google和Yahoo会保留其爬虫找到的页面的缓存版本。即使 1998results.asp 已从目标服务器上删除，这些搜索引擎可能仍然存储着其输出的一个版本。缓存版本可能包含对仍然存在于服务器上的其他隐藏内容的引用或线索。
      • 第三方网站链接：目标应用程序内部未引用的内容可能会被第三方网站链接。例如，一个代表第三方交易商处理在线支付的应用程序可能包含各种定制功能，通常只能通过跟随其客户网站中的链接才能找到这些功能。
  3. 绕过文件名过滤
    • 由于拒绝列表过滤器基于正则表达式，测试人员有时可以利用操作系统中一些不常见的文件名扩展特性，这些特性的工作方式可能超出了开发人员的预期。测试人员有时可以利用应用程序、Web服务器和底层操作系统解析文件名的方式差异及其文件名约定。
    • 示例：Windows的8.3文件名扩展将 c:\\program files 变为 C:\\PROGRA\~1。
      • 去除不兼容字符
      • 将空格转换为下划线
      • 取基本名称的前六个字符
      • 添加 ~<数字> 以区分前六个字符相同的文件
      • 在前三次名称冲突后，此约定会发生变化
      • 将文件扩展名截断为三个字符
      • 将所有字符转换为大写

灰盒测试

对旧文件和备份文件进行灰盒测试时，需要检查属于构成Web应用程序基础设施的Web服务器所提供服务的Web目录集合中的文件。从理论上讲，为了保证全面性，应该手动进行检查。然而，由于大多数情况下，文件副本或备份文件往往是按照相同的命名约定创建的，因此可以轻松编写脚本来进行搜索。例如，编辑器在保存备份副本时会使用易于识别的扩展名或后缀，而人们通常会留下带有 .old 或类似可预测扩展名的文件。一个有效的策略是定期安排一个后台任务，检查那些具有可能被识别为副本或备份文件的扩展名的文件，同时在较长的时间间隔内进行手动检查。

修复措施

为了制定有效的保护策略，应将测试与明确禁止危险操作的安全策略相结合，这些危险操作包括：

  • 直接在Web服务器或应用程序服务器的文件系统上就地编辑文件。这是一个特别糟糕的习惯，因为编辑器很可能会生成备份文件或临时文件。令人惊讶的是，即使在大型组织中，这种情况也经常发生。如果你确实需要在生产系统上编辑文件，请确保不会留下任何非预期的文件，并记住这样做需要自行承担风险。
  • 仔细检查在Web服务器所暴露的文件系统上执行的任何其他操作，例如临时管理操作。例如，如果你偶尔需要对几个目录进行快照（不建议在生产系统上这样做），你可能会想先将它们压缩成ZIP文件。请注意不要留下这样的存档文件。
  • 适当的配置管理策略有助于防止出现过时和未引用的文件。
  • 应用程序的设计应避免在Web服务器所提供服务的Web目录树中创建（或依赖）文件。数据文件、日志文件、配置文件等应存储在Web服务器无法访问的目录中，以防止信息泄露，更不用说如果Web目录权限允许写入时可能存在的数据修改风险。
  • 如果文档根目录位于使用文件系统快照技术的文件系统上，则不应通过Web访问这些文件系统快照。配置你的Web服务器以拒绝访问此类目录，例如，在Apache中，应使用如下的位置指令：
<Location ~ ".snapshot">
    Order deny,allow
    Deny from all
</Location>

工具

漏洞评估工具通常会检查具有标准名称的Web目录（如 “admin”、“test”、“backup” 等），并报告任何允许索引的Web目录。如果测试人员无法找到目录列表，他们应该尝试检查可能的备份文件扩展名。以下是一些有助于完成此任务的工具：

网络爬虫工具：

其中一些工具也包含在标准的Linux发行版中。Web开发工具通常具备识别断链和未引用文件的功能。

枚举基础设施和应用程序管理接口

编号
WSTG - CONF - 05

概述

应用程序或应用程序服务器中可能存在管理接口，允许特定用户在网站上执行特权活动。应进行测试，以揭示未授权用户或普通用户是否能够以及如何访问此特权功能。

应用程序可能需要管理接口，以便特权用户能够访问可能更改网站功能的功能。此类更改可能包括：

  • 用户账户配置
  • 网站设计和布局
  • 数据操作
  • 配置更改

在许多情况下，此类接口没有足够的控制措施来防止未经授权的访问。测试的目的是发现这些管理接口，并访问专为特权用户设计的功能。

测试目标

  • 识别隐藏的管理接口和功能。

测试方法

黑盒测试

以下部分介绍了可用于测试管理接口是否存在的方法。这些技术也可用于测试相关问题，包括权限提升，本指南的其他部分（例如，绕过授权方案测试和不安全直接对象引用测试）对这些内容有更详细的描述。

  • 目录和文件枚举：管理接口可能存在，但测试人员无法直接看到。可以通过简单的请求（如 /admin 或 /administrator）来猜测管理接口的路径。在某些情况下，使用高级谷歌搜索技术（谷歌语法）可以在几秒钟内揭示这些路径。有许多工具可用于对服务器内容进行暴力枚举，更多信息请参阅下面的工具部分。测试人员可能还需要识别管理页面的文件名。强行浏览到已识别的页面可能会获得对该接口的访问权限。
  • 源代码中的注释和链接：许多网站使用为所有用户加载的通用代码。通过检查发送给客户端的所有源代码，可能会发现指向管理功能的链接，并应进行调查。
  • 审查服务器和应用程序文档：如果应用程序服务器或应用程序以默认配置部署，则可以使用配置或帮助文档中描述的信息访问管理接口。如果找到管理接口且需要凭证，则应查阅默认密码列表。
  • 公开可用信息：许多应用程序（如 WordPress）默认情况下就有管理接口。
  • 备用服务器端口：管理接口可能位于主机上与主应用程序不同的端口上。例如，Apache Tomcat 的管理接口通常在端口 8080 上可见。
  • 参数篡改：可能需要一个 GET 或 POST 参数，或者一个 cookie 来启用管理功能。相关线索包括存在隐藏字段，例如：
<input type="hidden" name="admin" value="no">

或者在 cookie 中：
Cookie: session_cookie; useradmin = 0

一旦发现了管理接口，可以结合使用上述技术尝试绕过身份验证。如果失败，测试人员可能希望尝试进行暴力攻击。在这种情况下，测试人员应注意，如果存在账户锁定功能，则可能会导致管理账户被锁定。

灰盒测试

应更详细地检查服务器和应用程序组件，以确保进行了安全加固（即通过使用 IP 过滤或其他控制措施，使管理页面不是所有人都可以访问），并在适用的情况下，验证所有组件不使用默认凭证或配置。
应审查源代码，以确保授权和身份验证模型能明确区分普通用户和网站管理员的职责。应审查普通用户和管理员用户共享的用户界面功能，以确保这些组件的渲染和此类共享功能的信息泄露之间有明确的区分。

每个 Web 框架可能都有自己的默认管理页面或路径，例如：

PHP：

/phpinfo
/phpmyadmin/
/phpMyAdmin/
/mysqladmin/
/MySQLadmin
/MySQLAdmin
/login.php
/logon.php
/xmlrpc.php
/dbadmin

WordPress：

wp - admin/
wp - admin/about.php
wp - admin/admin - ajax.php
wp - admin/admin - db.php
wp - admin/admin - footer.php
wp - admin/admin - functions.php
wp - admin/admin - header.php

Joomla：

/administrator/index.php
/administrator/index.php?option = com_login
/administrator/index.php?option = com_content
/administrator/index.php?option = com_users
/administrator/index.php?option = com_menus
/administrator/index.php?option = com_installer
/administrator/index.php?option = com_config

Tomcat：

/manager/html
/host - manager/html
/manager/text
/tomcat - users.xml

Apache：

/index.html
/httpd.conf
/apache2.conf
/server - status

Nginx：

/index.html
/index.htm
/index.php
/nginx_status
/index.php
/nginx.conf
/html/error

工具

有几种工具可以帮助识别隐藏的管理接口和功能，包括：

  • ZAP - 强制浏览是 OWASP 之前的 DirBuster 项目的当前维护版本。
  • THC - HYDRA是一个允许对许多接口进行暴力破解的工具，包括基于表单的 HTTP 身份验证。
  • 当使用一个好的字典（如 Netsparker 字典）时，暴力破解工具会更有效。

参考资料

测试HTTP方法

ID
WSTG - CONF - 06

概述

HTTP提供了多种方法（或谓词），可用于在Web服务器上执行操作。虽然GET和POST是迄今为止用于访问Web服务器提供的信息时最常用的方法，但也有其他各种方法可能被支持，并且有时可能会被攻击者利用。

RFC 7231定义了主要的有效HTTP请求方法（或谓词），尽管其他RFC中也添加了额外的方法，例如RFC 5789。其中一些谓词在RESTful应用程序中被重新用于不同的目的，如下表所示：

方法原始用途RESTful用途
GET请求一个文件。请求一个对象。
HEAD请求一个文件，但仅返回HTTP头。
POST提交数据。
PUT上传一个文件。创建一个对象。
DELETE删除一个文件删除一个对象。
CONNECT建立与另一个系统的连接。
OPTIONS列出支持的HTTP方法。执行一个CORS预检请求。
TRACE为调试目的回显HTTP请求。
PATCH修改一个对象。

测试目标

  • 枚举支持的HTTP方法。
  • 测试访问控制绕过。
  • 测试HTTP方法覆盖技术。

测试方法

发现支持的方法

要执行此测试，测试人员需要一种方法来识别被检查的Web服务器支持哪些HTTP方法。最简单的方法是向服务器发送一个OPTIONS请求：

OPTIONS / HTTP/1.1
Host: example.org

然后服务器应该响应一个支持的方法列表：

HTTP/1.1 200 OK
Allow: OPTIONS, GET, HEAD, POST

然而，并非所有服务器都会响应OPTIONS请求，有些服务器甚至可能返回不准确的信息。还值得注意的是，服务器可能对不同的路径支持不同的方法。这意味着即使某个方法在根/目录不被支持，也不一定表示该方法在其他地方也不被支持。

一种更可靠的测试支持方法的方式是简单地发送一个该类型的请求，并检查服务器响应。如果该方法不被允许，服务器应该返回一个405 Method Not Allowed状态码。

请注意，有些服务器将未知方法视为等同于GET，因此它们可能会响应任意方法，如下所示的请求。这有时可能有助于绕过Web应用防火墙或任何其他阻止特定方法的过滤机制。

FOO / HTTP/1.1
Host: example.org

也可以使用curl的-X选项发送带有任意方法的请求：

curl -X FOO https://example.org

还有各种自动化工具可以尝试确定支持的方法，例如[http - methods](https://nmap.org/nsedoc/scripts/http - methods.html) Nmap脚本。然而，这些工具可能不会测试危险方法（即可能导致更改的方法，如PUT或DELETE），或者如果这些方法被支持，可能会无意中对Web服务器造成更改。因此，应该谨慎使用这些工具。

PUT和DELETE

PUT和DELETE方法的效果取决于它们是由Web服务器还是在其上运行的应用程序来解释。

旧版Web服务器

一些旧版Web服务器允许使用PUT方法在服务器上创建文件。例如，如果服务器配置为允许这样做，下面的请求将在服务器上创建一个名为test.html的文件，其内容为<script>alert(1)</script>。

PUT /test.html HTTP/1.1
Host: example.org
Content - Length: 25

<script>alert(1)</script>

使用cURL也可以进行类似的请求：

curl https://example.org --upload-file test.html

这允许攻击者向Web服务器上传任意文件，如果允许上传可执行代码（如PHP文件），可能会导致整个系统被攻陷。然而，这种配置非常罕见，在现代系统中不太可能出现。

同样，DELETE方法可用于从Web服务器删除文件。请注意，这是一个破坏性操作；因此，在测试此方法时应格外小心。

DELETE /test.html HTTP/1.1
Host: example.org

或者使用cURL：

curl https://example.org/test.html -X DELETE

RESTful API

相比之下，现代RESTful应用程序通常使用PUT和DELETE方法来创建和删除对象。例如，下面的API请求可用于创建一个名为“foo”，角色为“user”的用户：

PUT /api/users/foo HTTP/1.1
Host: example.org
Content - Length: 34

{
    "role": "user"
}

使用DELETE方法的类似请求可用于删除一个对象。

DELETE /api/users/foo HTTP/1.1
Host: example.org

虽然自动化扫描工具可能会报告这些方法的存在，但RESTful API上存在这些方法并不是一个安全问题。然而，此功能可能存在其他漏洞（如弱访问控制），应该进行彻底测试。

TRACE

TRACE方法（或微软的等效TRACK方法）会使服务器回显请求的内容。这导致了在2003年[发布](https://www.cgisecurity.com/whitehat - mirror/WH - WhitePaper_XST_ebook.pdf)（PDF）了一个名为跨站追踪（XST）的漏洞，该漏洞可用于访问设置了HttpOnly标志的cookie。多年来，所有浏览器和插件都已阻止了TRACE方法；因此，这个问题不再可利用。然而，自动化扫描工具可能仍然会标记此问题，并且Web服务器上启用TRACE方法表明该服务器没有得到适当的加固。

CONNECT

CONNECT方法会使Web服务器打开一个到另一个系统的TCP连接，然后将客户端的流量传递到该系统。这可能允许攻击者通过服务器代理流量，以隐藏其源地址、访问内部系统或访问绑定到本地主机的服务。下面是一个CONNECT请求的示例：

CONNECT 192.168.0.1:443 HTTP/1.1
Host: example.org

PATCH

PATCH方法在RFC 5789中定义，用于提供如何修改对象的指令。该RFC本身并未定义这些指令应采用的格式，但其他标准中定义了各种方法，例如RFC 6902 - JavaScript对象表示法（JSON）补丁。

例如，如果我们有一个名为“foo”的用户，具有以下属性：

{
    "role": "user",
    "email": "foo@example.org"
}

下面的JSON PATCH请求可用于将该用户的角色更改为“admin”，而不修改电子邮件地址：

PATCH /api/users/foo HTTP/1.1
Host: example.org

{ "op": "replace", "path": "/role", "value": "admin" }

虽然RFC规定它应该包含如何修改对象的指令，但PATCH方法通常（错误地）用于包含更改后的内容，如下所示。与前面的请求类似，这将把“role”值更改为“admin”，而不修改对象的其余部分。这与PUT方法不同，PUT方法会覆盖整个对象，因此会导致一个没有“email”属性的对象。

PATCH /api/users/foo HTTP/1.1
Host: example.org

{
    "role": "admin"
}

与PUT方法一样，此功能可能存在访问控制弱点或其他漏洞。此外，应用程序在修改对象时可能不会像创建对象时那样进行相同级别的输入验证。这可能会允许注入恶意值（如在存储型跨站脚本攻击中），或者可能会允许创建损坏或无效的对象，从而导致与业务逻辑相关的问题。

测试访问控制绕过

如果应用程序中的一个页面在用户尝试直接访问时使用302代码将用户重定向到登录页面，那么通过使用不同的HTTP方法（如HEAD、POST或甚至是自定义方法（如FOO））发送请求，可能会绕过此重定向。如果Web应用程序响应的是HTTP/1.1 200 OK而不是预期的HTTP/1.1 302 Found，那么就有可能绕过身份验证或授权。下面的示例展示了一个HEAD请求如何可能导致页面设置管理cookie，而不是将用户重定向到登录页面：

HEAD /admin/ HTTP/1.1
Host: example.org

HTTP/1.1 200 OK
[...]
Set - Cookie: adminSessionCookie=[...];

或者，也可以直接向导致操作的页面发送请求，例如：

HEAD /admin/createUser.php?username=foo&password=bar&role=admin HTTP/1.1
Host: example.org

或者：

FOO /admin/createUser.php
Host: example.org
Content - Length: 36

username=foo&password=bar&role=admin

测试HTTP方法覆盖

一些Web框架提供了一种覆盖请求中实际HTTP方法的方式。它们通过模拟缺失的HTTP谓词并在请求中传递一些自定义头来实现这一点。这样做的主要目的是绕过中间件应用程序（如代理或Web应用防火墙），这些应用程序会阻止特定的方法。以下替代HTTP头可能会被使用：

  • X-HTTP-Method
  • X-HTTP-Method-Override
  • X-Method-Override

为了测试这一点，考虑受限谓词（如PUT或DELETE）返回405 Method not allowed的情况。在这种情况下，重新发送相同的请求，但添加用于HTTP方法覆盖的替代头。然后，观察系统的响应。如果支持方法覆盖，应用程序应该以不同的状态码响应（例如200 OK）。

在下面的示例中，Web服务器不允许DELETE方法并阻止了它：

DELETE /resource.html HTTP/1.1
Host: example.org

HTTP/1.1 405 Method Not Allowed
[...]

添加X-HTTP-Method头后，服务器以200状态码响应请求：

GET /resource.html HTTP/1.1
Host: example.org
X - HTTP - Method: DELETE

HTTP/1.1 200 OK
[...]

修复建议

  • 确保只允许所需的方法，并且这些方法已正确配置。
  • 确保没有实现绕过用户代理、框架或Web服务器实施的安全措施的变通方法。

工具

参考资料

测试 HTTP 严格传输安全

ID
WSTG - CONF - 07

概述

HTTP 严格传输安全（HSTS）功能允许 Web 服务器通过特殊的响应头告知用户的浏览器，永远不要与指定的域名服务器建立未加密的 HTTP 连接。相反，浏览器应自动将所有访问该网站的连接请求通过 HTTPS 建立。这也能防止用户忽略证书错误。

鉴于此安全措施的重要性，谨慎起见，需要验证网站是否使用了此 HTTP 头，以确保所有数据在 Web 浏览器和服务器之间以加密方式传输。

HTTP 严格传输安全头使用三个特定指令：

  • max-age：指示浏览器应自动将所有 HTTP 请求转换为 HTTPS 的秒数。
  • includeSubDomains：表示所有相关子域名必须使用 HTTPS。
  • preload（非官方）：表示域名已列入预加载列表，浏览器应始终使用 HTTPS 进行连接。
    • 虽然所有主流浏览器都支持该指令，但它并非规范的官方部分。（更多信息请参阅 hstspreload.org）

以下是 HSTS 头实现的示例：
Strict-Transport-Security: max-age = 31536000; includeSubDomains

必须检查此头是否存在，因为缺少该头可能会导致以下安全问题：

  • 攻击者拦截并访问通过未加密网络通道传输的信息。
  • 攻击者利用用户接受不可信证书的情况，实施中间人（MITM）攻击。
  • 用户在浏览器中错误地使用 HTTP 而非 HTTPS 输入地址，或者用户点击 Web 应用程序中错误使用 HTTP 协议的链接。

测试目标

  • 检查 HSTS 头及其有效性。

测试方法

  • 通过拦截代理检查服务器响应，确认 HSTS 头是否存在。
  • 使用如下 curl 命令：
$ curl -s -D- https://owasp.org | grep -i strict-transport-security:
Strict-Transport-Security: max-age=31536000

参考资料

测试文件权限

编号
WSTG-CONF-09

概述

当为资源设置的权限允许比所需范围更广泛的参与者访问时，可能会导致敏感信息泄露，或者被非预期的一方修改该资源。当资源与程序配置、执行或敏感用户数据相关时，这种情况尤其危险。

一个明显的例子是可执行文件能被未授权用户运行。再举个例子，考虑用于访问 API 的账户信息或令牌值。在现代 Web 服务和微服务中，这类信息越来越常见，并且在安装时默认存储在具有全局可读权限的配置文件中。此类敏感数据可能会被主机系统内的恶意内部人员或远程攻击者泄露。后者可能通过其他漏洞入侵了服务，但仅获得了普通用户权限。

测试目标

  • 审查并识别任何异常的文件权限。

测试方法

在 Linux 系统中，使用 ls 命令检查文件权限。此外，也可以使用 namei 递归列出文件权限。

$ namei -l /要检查的路径/

需要进行文件权限测试的文件和目录包括但不限于以下几种：

  • Web 文件/目录
  • 配置文件/目录
  • 敏感文件（加密数据、密码、密钥）/目录
  • 日志文件（安全日志、操作日志、管理员日志）/目录
  • 可执行文件（脚本、EXE、JAR、类文件、PHP、ASP）/目录
  • 数据库文件/目录
  • 临时文件/目录
  • 上传文件/目录

修复措施

正确设置文件和目录的权限，使未授权用户无法访问关键资源。

工具

参考资料

子域名接管测试

编号
WSTG - CONF - 10

概述

成功利用此类漏洞后，攻击者可以声明并控制受害者的子域名。这种攻击依赖于以下两点：

  1. 受害者的外部 DNS 服务器子域名记录被配置为指向一个不存在或非活动的资源、外部服务或端点。随着各种即服务（XaaS，Anything as a Service）产品和公共云服务的普及，可供攻击的潜在目标众多。
  2. 托管该资源、外部服务或端点的服务提供商没有正确处理子域名所有权验证。

如果子域名接管成功，攻击者可以实施多种攻击，如提供恶意内容、钓鱼攻击、窃取用户会话 cookie 和凭据等。此漏洞可通过多种 DNS 资源记录进行利用，包括：A、CNAME、MX、NS、TXT 等。就攻击的严重程度而言，NS 子域名接管（虽然可能性较小）的影响最大，因为成功的攻击可能导致攻击者完全控制整个 DNS 区域和受害者的域名。

GitHub 场景示例

  1. 受害者（victim.com）使用 GitHub 进行开发，并配置了一个 DNS 记录（coderepo.victim.com）来访问它。
  2. 受害者决定将其代码仓库从 GitHub 迁移到一个商业平台，但没有从其 DNS 服务器中删除 coderepo.victim.com 记录。
  3. 攻击者发现 coderepo.victim.com 托管在 GitHub 上，并使用 GitHub Pages 和自己的 GitHub 账户声明该子域名。

过期域名场景示例

  1. 受害者（victim.com）拥有另一个域名（victimotherdomain.com），并使用 CNAME 记录（www）引用该域名（www.victim.com --> victimotherdomain.com）。
  2. 某个时候，victimotherdomain.com 域名过期，任何人都可以注册该域名。由于 victim.com 的 DNS 区域中未删除 CNAME 记录，因此任何注册 victimotherdomain.com 的人都可以完全控制 www.victim.com，直到该 DNS 记录被删除或更新。

测试目标

  • 枚举所有可能的域名（包括历史和当前的域名）。
  • 识别任何被遗忘或配置错误的域名。

测试方法

黑盒测试

第一步是枚举受害者的 DNS 服务器和资源记录。有多种方法可以完成此任务，例如使用常见子域名字典进行 DNS 枚举、DNS 暴力破解，或使用网络搜索引擎和其他开源情报（OSINT）数据源。

测试人员使用 dig 命令查找以下需要进一步调查的 DNS 服务器响应消息：

  • NXDOMAIN
  • SERVFAIL
  • REFUSED
  • no servers could be reached.
测试 DNS A、CNAME 记录子域名接管

使用 dnsrecon 对受害者的域名（victim.com）进行基本的 DNS 枚举：

$ ./dnsrecon.py -d victim.com
[*] Performing General Enumeration of Domain: victim.com
...
[-] DNSSEC is not configured for victim.com
[*]      A subdomain.victim.com 192.30.252.153
[*]      CNAME subdomain1.victim.com fictioussubdomain.victim.com
...

识别哪些 DNS 资源记录已失效并指向非活动或未使用的服务。使用 dig 命令查询 CNAME 记录：

$ dig CNAME fictioussubdomain.victim.com
; <<>> DiG 9.10.3 - P4 - Ubuntu <<>> ns victim.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<< - opcode: QUERY, status: NXDOMAIN, id: 42950
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

以下 DNS 响应需要进一步调查：NXDOMAIN。

为了测试 A 记录，测试人员进行 whois 数据库查询，并确定 GitHub 是服务提供商：

$ whois 192.30.252.153 | grep "OrgName"
OrgName: GitHub, Inc.

测试人员访问 subdomain.victim.com 或发送 HTTP GET 请求，若返回 “404 - File not found” 响应，则明确表明存在漏洞。

在这里插入图片描述
图 4.2.10 - 1：GitHub 404 文件未找到响应

测试人员使用 GitHub Pages 声明该域名：

在这里插入图片描述

图 4.2.10 - 2：GitHub 声明域名

测试 NS 记录子域名接管

识别目标域名的所有名称服务器：

$ dig ns victim.com +short
ns1.victim.com
nameserver.expireddomain.com

在这个虚构的示例中，测试人员通过域名注册商查询来检查 expireddomain.com 域名是否活跃。如果该域名可以购买，则该子域名存在漏洞。

以下 DNS 响应需要进一步调查：SERVFAIL 或 REFUSED。

灰盒测试

如果测试人员可以获取 DNS 区域文件，则无需进行 DNS 枚举。测试方法与黑盒测试相同。

修复建议

为了降低子域名接管的风险，应从 DNS 区域中删除存在漏洞的 DNS 资源记录。建议将持续监控和定期检查作为最佳实践。

工具

参考资料

测试云存储

编号
WSTG - CONF - 11

概述

云存储服务允许 Web 应用程序和服务在存储服务中存储和访问对象。然而，访问控制配置不当可能会导致敏感信息泄露、数据篡改或未经授权的访问。

一个已知的例子是 Amazon S3 存储桶配置错误，不过其他云存储服务也可能面临类似的风险。默认情况下，所有 S3 存储桶都是私有的，只有被明确授予访问权限的用户才能访问。用户不仅可以向存储桶本身授予公共访问权限，还可以向存储在该存储桶内的单个对象授予公共访问权限。这可能会导致未经授权的用户能够上传新文件、修改或读取已存储的文件。

测试目标

  • 评估存储服务的访问控制配置是否正确设置。

测试方法

首先，确定用于访问存储服务中数据的 URL，然后考虑进行以下测试：

  • 读取未授权的数据
  • 上传一个新的任意文件

你可以使用 curl 进行测试，使用以下命令并查看是否可以成功执行未经授权的操作。

测试读取对象的能力

curl -X GET https://<cloud-storage-service>/<object>

测试上传文件的能力

curl -X PUT -d 'test' 'https://<cloud-storage-service>/test.txt'

在上述命令中，当在 Windows 机器上运行该命令时，建议将单引号（'）替换为双引号（"）。

测试 Amazon S3 存储桶配置错误情况

Amazon S3 存储桶的 URL 遵循两种格式之一，即虚拟主机样式或路径样式。

虚拟主机样式访问
https://bucket-name.s3.Region.amazonaws.com/key-name

在以下示例中，my-bucket 是存储桶名称，us-west-2 是区域，puppy.png 是键名：

https://my-bucket.s3.us-west-2.amazonaws.com/puppy.png
路径样式访问
https://s3.Region.amazonaws.com/bucket-name/key-name

同样，在以下示例中，my-bucket 是存储桶名称，us-west-2 是区域，puppy.png 是键名：

https://s3.us-west-2.amazonaws.com/my-bucket/puppy.png

对于某些区域，可以使用不指定特定区域端点的旧版全局端点。其格式也可以是虚拟主机样式或路径样式。

虚拟主机样式访问
https://bucket-name.s3.amazonaws.com
路径样式访问
https://s3.amazonaws.com/bucket-name
识别存储桶 URL

对于黑盒测试，可以在 HTTP 消息中找到 S3 URL。以下示例展示了在 HTTP 响应的 img 标签中发送了一个存储桶 URL。

...
<img src="https://my-bucket.s3.us-west-2.amazonaws.com/puppy.png">
...

对于灰盒测试，你可以从 Amazon 的 Web 界面、文档、源代码以及任何其他可用来源获取存储桶 URL。

使用 AWS - CLI 进行测试

除了使用 curl 进行测试外，你还可以使用 AWS 命令行工具进行测试。在这种情况下，使用 s3:// URI 方案。

列出对象

以下命令用于列出配置为公共访问的存储桶中的所有对象：

aws s3 ls s3://<bucket-name>
上传文件

以下是上传文件的命令：

aws s3 cp arbitrary-file s3://bucket-name/path-to-save

此示例展示了上传成功时的结果：

$ aws s3 cp test.txt s3://bucket-name/test.txt
upload: ./test.txt to s3://bucket-name/test.txt

此示例展示了上传失败时的结果：

$ aws s3 cp test.txt s3://bucket-name/test.txt
upload failed: ./test2.txt to s3://bucket-name/test2.txt An error occurred (AccessDenied) when calling the PutObject operation: Access Denied
删除对象

以下是删除对象的命令：

aws s3 rm s3://bucket-name/object-to-remove

工具

参考资料

测试内容安全策略

编号
WSTG - CONF - 12

概述

内容安全策略（Content Security Policy，CSP）是一种声明式的白名单策略，通过 Content-Security-Policy 响应头或等效的 <meta> 元素来实施。它允许开发者限制诸如 JavaScript、CSS、图像、文件等资源的加载来源。CSP 是一种有效的纵深防御技术，可降低跨站脚本攻击（Cross - Site Scripting，XSS）和点击劫持等漏洞的风险。

内容安全策略支持多种指令，这些指令能够对策略的实施进行精细控制（更多详细信息请参阅参考资料）。

测试目标

  • 审查内容安全策略头或元元素，以识别配置错误。

测试方法

要测试内容安全策略（CSP）的配置错误，可通过代理工具检查 Content-Security-Policy HTTP 响应头或 CSP meta 元素，查找不安全的配置：

  • unsafe-inline 指令允许内联脚本或样式，这会使应用程序容易受到跨站脚本攻击。
  • unsafe-eval 指令允许在应用程序中使用 eval() 函数，并且容易受到常见的绕过技术（如数据 URL 注入）的攻击。
  • unsafe - hashes 指令允许使用内联脚本/样式，前提是它们与指定的哈希值匹配。
  • 使用通配符 (*) 源可以允许从任何来源加载脚本等资源。
    • 同时也要考虑基于部分匹配的通配符，例如：https://* 或 *.cdn.com。
    • 考虑白名单中的源是否提供 JSONP 端点，这些端点可能被用于绕过 CSP 或同源策略。
  • 在 frame - ancestors 指令中使用通配符 (*) 源可以为所有来源启用框架嵌入。如果 frame - ancestors 指令未在内容安全策略头中定义，应用程序可能容易受到[点击劫持](…/11 - 客户端测试/09 - 点击劫持测试.md)攻击。
  • 关键业务应用程序应使用严格的策略。

修复建议

配置强大的内容安全策略，以减少应用程序的攻击面。开发者可以使用在线工具（如谷歌 CSP 评估器）来验证内容安全策略的强度。

严格策略

严格策略是一种能够防范经典的存储型、反射型和部分 DOM 型 XSS 攻击的策略，应该是任何试图实施 CSP 的团队的最佳目标。

谷歌制定了一份基于随机数（nonce）采用严格 CSP 的指南。根据在 LocoMocoSec 上的一次演讲，以下两种策略可用于应用严格策略：

适度严格策略：

script-src 'nonce-r4nd0m' 'strict-dynamic';
object-src 'none'; base-uri 'none';

严格锁定策略：

script-src 'nonce-r4nd0m';
object-src 'none'; base-uri 'none';
  • script-src 指令用于限制脚本的加载和执行来源。
  • object-src 指令用于限制对象的加载和执行来源。
  • base-uri 指令指定页面中解析相对 URL 的基础 URL。如果没有这个指令，页面可能容易受到 HTML 基础标签注入攻击。

工具

参考资料

路径混淆测试

编号
WSTG - CONF - 13

概述

应用程序路径的正确配置至关重要，因为若路径配置有误，攻击者可在后续阶段利用这一配置错误来实施其他漏洞攻击。

例如，若路由配置不正确，且目标网站使用了内容分发网络（CDN），攻击者就能够利用该配置错误来实施Web缓存欺骗攻击。

因此，为防止其他攻击，测试人员应对此配置进行评估。

测试目标

  • 确保应用程序路径配置正确。

测试方法

黑盒测试

在黑盒测试场景中，测试人员应将所有现有路径替换为不存在的路径，然后检查目标的行为和状态码。

例如，应用程序中有一个指向仪表盘的路径，用于显示用户账户余额（如金钱、游戏积分等）。

假设该路径为 https://example.com/user/dashboard，测试人员应测试开发人员可能为该路径考虑的不同模式。对于Web缓存欺骗漏洞，分析人员应考虑类似 https://example.com/user/dashboard/non.js 这样的路径。如果仪表盘信息可见，并且目标使用了CDN（或其他Web缓存），那么很可能存在Web缓存欺骗攻击的风险。

白盒测试

检查应用程序的路由配置。大多数情况下，开发人员会在应用程序路由中使用正则表达式。

在下面这个示例中，我们可以看到一个Django框架应用程序的 urls.py 文件里存在路径混淆的情况。开发人员没有使用正确的正则表达式，从而导致了漏洞：

    from django.urls import re_path
    from . import views

    urlpatterns = [

        re_path(r'.*^dashboard', views.path_confusion ,name = 'index'),

    ]

如果用户在浏览器中打开 https://example.com/dashboard/none.js 路径，也能显示用户仪表盘信息，并且目标使用了CDN或Web缓存，那么就可以实施Web缓存欺骗攻击。

工具

修复建议

  • 避免基于文件扩展名或路径对缓存进行分类/处理（应利用内容类型）。
  • 确保缓存机制遵循应用程序指定的缓存控制头。
  • 实现符合RFC标准的文件未找到处理和重定向机制。

参考资料

测试其他HTTP安全头配置错误

ID
WSTG-CONF-14

概述

安全头在保护Web应用程序免受各种攻击（包括跨站脚本攻击（XSS）、点击劫持和数据注入攻击）方面起着至关重要的作用。这些头信息指示浏览器如何处理网站通信的安全相关方面，从而减少已知攻击向量的暴露。然而，配置错误可能会导致漏洞，削弱预期的安全保护，甚至使其失效。本节概述了常见的安全头配置错误、相关风险以及如何正确测试这些问题。

测试目标

  • 识别配置不当的安全头。
  • 评估配置错误的安全头的影响。
  • 验证所需安全头的正确实现。

常见的安全头配置错误

  • 值为空的安全头：存在但没有值的头信息可能会被浏览器忽略，从而使其无效。
  • 值或名称无效（拼写错误）的安全头：不正确的头名称或拼写错误会导致头信息不被识别或强制执行。
  • 过度宽松的安全头：配置过于宽泛的头信息（例如，使用通配符 * 或过度宽松的指令）可能会泄露信息或允许访问超出预期范围的资源。
  • 重复的安全头：同一头信息多次出现且值相互冲突，可能会导致浏览器行为不可预测，甚至可能完全禁用安全措施。
  • 遗留或已弃用的头：包含过时的头信息（例如，HPKP）或指令（例如，X-Frame-Options 中的 ALLOW-FROM），而现代浏览器不再支持这些内容，可能会带来不必要的风险。
  • 安全头放置位置不当：某些头信息仅在特定条件下有效。例如，像 HSTS 这样的头信息必须通过 HTTPS 传输；如果通过 HTTP 发送，它们将无效。
  • META 标签处理错误：在通过 HTTP 头和 META 标签（使用 http-equiv）同时强制执行安全策略（如内容安全策略（CSP））的情况下，存在 META 标签值可能会覆盖或与 HTTP 头中定义的安全逻辑冲突的风险。这可能会导致不安全的策略无意中优先执行，从而削弱整体安全态势。

安全头配置错误的风险

  • 有效性降低：配置错误的头信息可能无法提供预期的保护，使应用程序容易受到 XSS、点击劫持或 CORS 相关漏洞等攻击。
  • 安全措施失效：重复的头信息或冲突的指令可能会导致浏览器完全忽略 HTTP 安全头，从而禁用预期的保护措施。
  • 引入新的攻击向量：使用遗留或已弃用的头信息，如果现代浏览器不再支持预期的安全措施，可能会引入风险而不是减轻风险。

如何测试

获取并审查 HTTP 安全头

要检查应用程序使用的安全头，可以采用以下方法：

  • 拦截代理：使用诸如 Burp Suite 之类的工具来分析服务器响应。
  • 命令行工具：执行 curl 命令来检索 HTTP 响应头：curl -I https://example.com
    • 有时 Web 应用程序会重定向到新页面，为了跟随重定向，请使用以下命令：curl -L -I https://example.com
    • 一些防火墙可能会阻止 curl 的默认用户代理，并且一些 TLS/SSL 错误也会阻止其返回正确的信息，在这种情况下，你可以尝试使用以下命令：
      curl -I -L -k --user-agent "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/94.0.4606.81 Safari/537.36" https://example.com
  • 浏览器开发者工具：打开开发者工具（F12），导航到 网络 选项卡，选择一个请求，然后查看 头信息 部分。

检查过度宽松的安全头

  • 识别有风险的头：查找可能允许过度访问的头信息，例如：
  • 评估指令：验证是否强制执行了严格的指令。例如，过度宽松的配置可能如下所示：
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
X-Permitted-Cross-Domain-Policies: all
Referrer-Policy: unsafe-url

安全的配置如下所示：

Access-Control-Allow-Origin: {theallowedoriginurl}
X-Permitted-Cross-Domain-Policies: none
Referrer-Policy: no-referrer

检查重复、已弃用或过时的头

  • 重复的头：确保同一头信息不会多次定义且值相互冲突。
  • 过时的头：识别并移除已弃用的头信息（例如，HPKP）和过时的指令（例如，X-Frame-Options 中的 ALLOW-FROM）。参考 Mozilla 开发者网络：X-Frame-Options 等来源获取最新标准。

确认安全头的正确放置

  • 特定协议要求：验证用于安全上下文的头信息（例如，HSTS）仅在适当的条件下（即通过 HTTPS）传输。
  • 条件性传输：某些头信息可能仅在特定情况下有效。验证这些条件是否满足，以使头信息按预期工作。

评估 META 标签处理

  • 双重强制执行检查：当通过 HTTP 头和使用 http-equiv 的 META 标签同时应用 CSP 等安全策略时，确认 HTTP 头（通常被认为更具权威性）不会被 META 标签无意中覆盖。
  • 审查浏览器行为：在各种浏览器中测试应用程序，查看是否因存在冲突的指令而出现差异。在可能的情况下，避免使用双重定义，以防止意外的安全漏洞。

修复措施

  • 正确配置头信息：确保头信息正确实现，具有正确的值且无拼写错误。
  • 强制执行严格的指令：使用最安全的设置配置头信息，同时仍允许所需的功能。例如，除非绝对必要，否则避免在 CORS 策略中使用 *。
  • 移除已弃用的头：用现代等效的头信息替换遗留的安全头，并移除任何不再支持的头信息。
  • 避免冲突的定义：防止重复的头定义，并确保 META 标签不会与安全策略的 HTTP 头冲突。

工具

参考资料

检查重复、已弃用或过时的头

  • 重复的头：确保同一头信息不会多次定义且值相互冲突。
  • 过时的头：识别并移除已弃用的头信息（例如，HPKP）和过时的指令（例如，X-Frame-Options 中的 ALLOW-FROM）。参考 Mozilla 开发者网络：X-Frame-Options 等来源获取最新标准。

确认安全头的正确放置

  • 特定协议要求：验证用于安全上下文的头信息（例如，HSTS）仅在适当的条件下（即通过 HTTPS）传输。
  • 条件性传输：某些头信息可能仅在特定情况下有效。验证这些条件是否满足，以使头信息按预期工作。

评估 META 标签处理

  • 双重强制执行检查：当通过 HTTP 头和使用 http-equiv 的 META 标签同时应用 CSP 等安全策略时，确认 HTTP 头（通常被认为更具权威性）不会被 META 标签无意中覆盖。
  • 审查浏览器行为：在各种浏览器中测试应用程序，查看是否因存在冲突的指令而出现差异。在可能的情况下，避免使用双重定义，以防止意外的安全漏洞。

修复措施

  • 正确配置头信息：确保头信息正确实现，具有正确的值且无拼写错误。
  • 强制执行严格的指令：使用最安全的设置配置头信息，同时仍允许所需的功能。例如，除非绝对必要，否则避免在 CORS 策略中使用 *。
  • 移除已弃用的头：用现代等效的头信息替换遗留的安全头，并移除任何不再支持的头信息。
  • 避免冲突的定义：防止重复的头定义，并确保 META 标签不会与安全策略的 HTTP 头冲突。

工具

参考资料

评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值