跳轉至

A10:2025 异常条件处理不当 icon

背景

异常条件处理不当是 2025 年新增类别。该类别包含 24 个 CWE，关注错误处理不当、逻辑错误、失效开放，以及系统可能遇到的异常条件所引发的其他相关场景。本类别中有一些 CWE 过去与代码质量差相关联。对我们来说，这种说法过于宽泛；我们认为，这个更具体的类别能提供更好的指导。

本类别中值得关注的 CWE 包括：CWE-209：生成包含敏感信息的错误消息、CWE-234：未处理缺失参数、CWE-274：权限不足处理不当、CWE-476：空指针解引用 和 CWE-636：未能安全失效（失效开放）。

评分表

映射的 CWE 数量 最大发生率 平均发生率 最大覆盖率 平均覆盖率 平均加权可利用性 平均加权影响 发生总数 CVE 总数
24 20.67% 2.95% 100.00% 37.95% 7.11 3.81 769,581 3,416

描述

软件中异常条件处理不当，是指程序未能预防、检测和响应异常且不可预测的情况，从而导致崩溃、意外行为，有时还会造成漏洞。这可能涉及以下三类失败中的一种或多种：应用没有阻止异常情况发生，没有在异常情况发生时识别它，和/或在事后响应不佳或完全不响应。

异常条件可能由缺失、薄弱或不完整的输入验证造成，也可能由没有在错误发生的函数处处理，而是在较晚、更高层级处理错误造成；还可能来自内存、权限或网络问题等意外环境状态、不一致的异常处理，或完全未处理的异常，使系统进入未知且不可预测的状态。任何时候，只要应用不确定下一条指令是什么，就已经对异常条件处理不当。难以发现的错误和异常可能长期威胁整个应用的安全。

当我们对异常条件处理不当时，可能出现许多不同安全漏洞，例如逻辑缺陷、溢出、竞争条件、欺诈交易，或与内存、状态、资源、时序、认证和授权有关的问题。这些类型的漏洞可能负面影响系统或其数据的机密性、可用性和/或完整性。攻击者会操纵应用有缺陷的错误处理来利用此类漏洞。

如何预防

为了正确处理异常条件，我们必须提前为这类情况做计划（预期最坏情况）。我们必须在每个可能发生系统错误的位置直接“捕获”错误，然后处理它，也就是采取有意义的行动来解决问题，并确保系统从问题中恢复。作为处理的一部分，应包括抛出错误（以用户能理解的方式告知用户）、记录事件日志，并在我们认为有必要时发出告警。还应设置全局异常处理器，以应对可能遗漏的情况。理想情况下，我们还应具备监控和/或可观测性工具或功能，用于发现重复错误或表明正在发生攻击的模式，并能触发某种响应、防御或阻断。这可以帮助我们阻止并响应专门针对错误处理弱点的脚本和机器人。

捕获并处理异常条件可以确保程序的底层基础设施不会被迫处理不可预测的情况。如果你正处于任何类型交易的中途，非常重要的一点是回滚交易的每个部分并重新开始（也称为故障关闭，failing closed）。试图从交易中途恢复，往往会造成无法恢复的错误。

在可能的情况下，尽量加入速率限制、资源配额、节流和其他限制，从源头预防异常条件。信息技术中不应存在无限制的东西，因为这会导致应用韧性不足、拒绝服务、成功的暴力破解攻击以及异常高昂的云账单。

请考虑是否应将超过一定频率的相同重复错误只输出为统计信息，显示发生次数和时间范围。该信息应追加到原始消息中，以免干扰自动化日志记录和监控，参见 A09:2025 安全日志记录和告警失效。

除此之外，我们还希望加入严格输入验证（对必须接受的潜在危险字符进行清理或转义），以及集中式错误处理、日志记录、监控、告警和全局异常处理器。一个应用不应有多个处理异常条件的函数，应在一个地方以相同方式执行。我们还应为本节所有建议创建项目安全需求，在项目设计阶段执行威胁建模和/或安全设计审查活动，执行代码审查或静态分析，并对最终系统执行压力、性能和渗透测试。

如果可能，整个组织应以同一种方式处理异常条件，因为这会让这项重要安全控制的代码审查和审计更容易。

攻击场景示例

场景 #1： 异常条件处理不当导致资源耗尽（拒绝服务）。如果应用在上传文件时捕获异常，但事后没有正确释放资源，每次新异常都会让资源保持锁定或不可用，直到所有资源耗尽。

场景 #2： 错误处理不当或数据库错误把完整系统错误暴露给用户，导致敏感数据泄露。攻击者持续制造错误，以利用敏感系统信息构造更好的 SQL 注入攻击。用户错误消息中的敏感数据成为侦察信息。

场景 #3： 攻击者通过网络中断打断多步骤交易，可能导致金融交易状态损坏。假设交易顺序为：扣减用户账户、增加目标账户余额、记录交易。如果系统在中途出错时没有正确回滚整个交易（故障关闭），攻击者可能耗尽用户账户，或可能利用竞争条件多次向目标账户转账。

参考资料

OWASP MASVS-RESILIENCE

映射的 CWE 列表