4.8.1-测试不正确的错误处理_improper error handling-CSDN博客

本文链接：https://blog.csdn.net/qq_44232452/article/details/133899161

测试不正确的错误处理

ID
WSTG-ERRH-01

所有类型的应用程序（Web 应用程序、Web 服务器、数据库等）都会由于各种原因生成错误。开发人员通常会忽略处理这些错误，或者推脱用户会故意尝试触发错误的想法（例如，发送一个需要整数的字符串）。当开发人员只考虑 happy path 时，他们会忘记代码可以接收但无法处理的所有其他可能的用户输入。

错误有时会上升为：

不正确的错误处理可让攻击者：

错误通常被视为良性错误，因为它们提供的诊断数据和消息可以帮助用户了解手头的问题，或供开发人员调试该错误。

通过尝试发送意外数据，或强制系统进入某些边缘情况和场景，系统或应用程序在大多数情况下会透露一些内部发生的事情，除非开发人员关闭所有可能的错误并返回某个自定义消息。

所有 Web 应用程序都在 Web 服务器上运行，无论是集成的还是成熟的。Web 应用程序必须处理和解析 HTTP 请求，为此，Web 服务器始终是堆栈的一部分。一些最著名的 Web 服务器是 NGINX、Apache 和 IIS。

Web 服务器具有已知的错误消息和格式。如果一个人不熟悉它们的外观，在线搜索它们将提供示例。另一种方法是查看他们的文档，或者简单地在本地设置一个服务器并通过浏览 Web 服务器使用的页面来发现错误。

为了触发错误消息，测试人员必须：

搜索找不到的随机文件和文件夹（404s）。
尝试请求存在的文件夹并查看服务器行为（403、空白页或目录列表）。
尝试发送中断 HTTP RFC 的请求。一个示例是发送非常大的路径、破坏标头格式或更改 HTTP 版本。
- 即使在应用程序级别处理了错误，破坏 HTTP RFC 也可能使集成的 Web 服务器显示自己，因为它必须处理请求，而开发人员会忘记覆盖这些错误。

应用程序最容易受到各种错误消息的影响，其中包括：堆栈跟踪、内存转储、处理不当的异常和一般错误。发生这种情况是因为应用程序大多数时候都是自定义构建的，开发人员需要观察和处理所有可能的错误情况（或具有全局错误捕获机制），而这些错误可能来自与其他服务的集成。

为了使应用程序抛出这些错误，测试人员必须：

确定应用程序需要数据的可能输入点。
分析预期的输入类型（字符串、整数、JSON、XML 等）。
根据前面的步骤对每个输入点进行模糊测试，以获得更集中的测试场景。
- 使用所有可能的注入对每个输入进行模糊测试并不是最佳解决方案，除非您有无限的测试时间并且应用程序可以处理这么多输入。
- 如果无法进行模糊测试，请精心挑选最有可能破坏特定解析器的可行输入（例如，JSON 正文的右括号、预期仅包含几个字符的大文本、带有可能由服务器和输入验证控件解析的参数的 CLRF 注入、不适用于文件名的特殊字符、等）。
- 应该为每种类型运行使用行话数据的模糊测试，因为有时解释器会在开发人员的异常处理之外中断。
了解使用错误消息响应的服务，并尝试制作更精细的模糊列表，以便从该服务（可以是数据库、独立服务等）中获取更多信息或错误详细信息。

错误消息有时是映射系统的主要弱点，尤其是在微服务架构下。如果服务没有正确设置为以通用和统一的方式处理错误，错误消息将允许测试人员识别哪个服务处理哪些请求，并允许每个服务进行更有针对性的攻击