CWE - CWE - 754:检查不当不寻常或异常情况(4.10)

弱点ID: 754

抽象:类
结构:简单的

视图定制的信息:

描述

产品不检查或不正确检查异常或异常情况不会经常发生在日常操作的产品。

扩展描述

程序员可能会假定某些事件或条件永远不会发生或不需要担心,如低内存条件下,由于缺乏资源限制权限,或行为不端的客户或组件。然而,攻击者可能故意引发这些不寻常的条件,因此违反了程序员的假设,可能引入不稳定,不正确的行为,或一个漏洞。

注意,这个条目不仅仅是关于使用异常和异常处理,检查和处理机制的不寻常或意外情况。

的关系

此表显示了弱点和高水平类别相关的这一弱点。这些关系被定义为ChildOf、ParentOf MemberOf,并洞察类似项目可能存在的在较高和较低的抽象级别。此外,关系如PeerOf和CanAlsoBe定义显示类似的弱点,用户可能想要探索。

相关的视图”研究概念”(cwe - 1000)

自然	类型	ID	的名字
ChildOf	支柱——一个弱点是最抽象类型的弱点和代表一个主题类/基地/变体相关弱点。支柱是不同于一个类别作为支柱技术上仍然是一种弱点,描述了一个错误,而一个类别代表一个共同特征用于组相关的东西。	703年	检查或不当处理异常情况
ParentOf	Base -一个弱点,仍主要是独立的资源或技术,但有足够的细节来提供特定的检测和预防方法。基础水平的弱点通常描述问题的2或3以下维度:行为、财产、技术、语言,和资源。	252年	不返回值
ParentOf	Base -一个弱点,仍主要是独立的资源或技术,但有足够的细节来提供特定的检测和预防方法。基础水平的弱点通常描述问题的2或3以下维度:行为、财产、技术、语言,和资源。	253年	函数返回值的错误检查
ParentOf	Base -一个弱点,仍主要是独立的资源或技术,但有足够的细节来提供特定的检测和预防方法。基础水平的弱点通常描述问题的2或3以下维度:行为、财产、技术、语言,和资源。	273年	检查了不当的特权
ParentOf	Base -一个弱点,仍主要是独立的资源或技术,但有足够的细节来提供特定的检测和预防方法。基础水平的弱点通常描述问题的2或3以下维度:行为、财产、技术、语言,和资源。	354年	不当的验证完整性检查的价值
ParentOf	Base -一个弱点,仍主要是独立的资源或技术,但有足够的细节来提供特定的检测和预防方法。基础水平的弱点通常描述问题的2或3以下维度:行为、财产、技术、语言,和资源。	391年	未经检查的错误条件
ParentOf	Base -一个弱点,仍主要是独立的资源或技术,但有足够的细节来提供特定的检测和预防方法。基础水平的弱点通常描述问题的2或3以下维度:行为、财产、技术、语言,和资源。	394年	意想不到的状态代码或返回值
ParentOf	Base -一个弱点,仍主要是独立的资源或技术,但有足够的细节来提供特定的检测和预防方法。基础水平的弱点通常描述问题的2或3以下维度:行为、财产、技术、语言,和资源。	476年	空指针废弃

简化映射的相关视图”缺点漏洞发布”(cwe - 1003)

自然	类型	ID	的名字
ParentOf	Base -一个弱点,仍主要是独立的资源或技术,但有足够的细节来提供特定的检测和预防方法。基础水平的弱点通常描述问题的2或3以下维度:行为、财产、技术、语言,和资源。	252年	不返回值
ParentOf	Base -一个弱点,仍主要是独立的资源或技术,但有足够的细节来提供特定的检测和预防方法。基础水平的弱点通常描述问题的2或3以下维度:行为、财产、技术、语言,和资源。	273年	检查了不当的特权
ParentOf	Base -一个弱点,仍主要是独立的资源或技术,但有足够的细节来提供特定的检测和预防方法。基础水平的弱点通常描述问题的2或3以下维度:行为、财产、技术、语言,和资源。	476年	空指针废弃

相关视图”架构概念”(cwe - 1008)

自然	类型	ID	的名字
MemberOf	类别——CWE条目包含一组其他条目,共享一个共同的特点。	1012年	交叉剪接

背景细节

许多函数会返回一些关于他们的行动的成功的价值。这将提醒程序是否处理函数的任何错误造成的。

模式的介绍

不同模式的引入提供了信息如何以及何时可以纳入这一弱点。生命周期的阶段识别点的介绍可能发生,而相关的报告提供了一个典型的场景介绍在给定的阶段。

阶段	请注意
实现	实现:造成这一弱点在建筑安全策略的实施。

适用的平台

该清单显示了给定的弱点可以可能的地区出现。这些可能是为特定命名的语言,操作系统,架构、模式、技术、或一个类这样的平台。列出的平台是随着频率的出现疲态实例。

语言

类:不是特定于语言的患病率(待定)

常见的后果

这个表指定不同的个人相关后果的弱点。标识应用程序范围的安全领域侵犯,而影响了负面的技术影响,如果敌人成功利用这个弱点。可能提供的信息如何可能的具体结果预计将看到列表中相对于其它后果。例如,可能会有高可能性,缺点将被利用来实现一定的影响,但较低的可能性,它将被利用来实现不同的影响。

范围	影响	可能性
完整性可用性	技术的影响:DoS:崩溃,退出或重新启动;意想不到的状态产生的数据作为一个函数调用的结果可能是在一个糟糕的状态回来。如果不检查返回值,那么这个糟糕的数据可用于操作,可能导致崩溃或其他意想不到的行为。

利用的可能性

媒介

示范例子

示例1

考虑下面的代码段:

(坏的代码)

例如语言:C

char buf [10], cp_buf [10];
fgets (buf 10 stdin);
strcpy (cp_buf buf);

程序员预计,当fgets()返回,但将包含一个以null结尾的字符串长度为9的或更少。但如果发生I / O错误,fgets()不会null-terminate缓冲区。此外,如果到达文件的末尾读取任何字符之前,fgets()返回而无需编写任何缓冲区。在这两种情况下,fgets()信号,发生了一些不寻常的东西通过返回NULL,但是在这段代码中,警告不会被注意到。缺乏一个空终结者buf会导致缓冲区溢出在随后调用strcpy ()。

示例2

下面的代码不检查内存分配成功之前使用malloc()返回的指针。

(坏的代码)

例如语言:C

buf = (char *) malloc (req_size);
strncpy (buf转送,req_size);

这个编码错误的传统防御是:“如果我的程序运行的内存,它就会失败。不管我是否处理错误的或者仅仅是允许程序死一个段错误当试图废弃空指针”。This argument ignores three important considerations:

取决于应用程序的类型和大小,它可能会释放内存,在其他地方使用,以便能继续执行。
程序执行不可能如果需要体面地退出。如果程序执行一个原子操作,它可以让系统处于不一致的状态。
程序员已经失去了机会来记录诊断信息。并调用malloc()失败,因为req_size太大或因为有太多的请求被处理在同一时间吗?还是内存泄漏造成的,随着时间的推移建立?没有处理错误,就没有办法知道。

示例3

下面的示例文件读入一个字节数组。

(坏的代码)

例如语言:c#

char[]中byteArray = new char [1024];
(IEnumerator i = users.GetEnumerator ();i.MoveNext (); i.Current ()) {

字符串的用户名=(字符串)i.Current ();
字符串pFileName = PFILE_ROOT + " +用户名;
StreamReader sr = new StreamReader (pFileName);
sr.Read(中byteArray, 0, 1024); / /总是1 k字节的文件
sr.Close ();
processPFile(用户名、中byteArray);

}

(坏的代码)

例如语言:Java

FileInputStream fis;
byte[]中byteArray =新字节[1024];
迭代器(i = users.iterator ();i.hasNext ();) {

字符串的用户名=(字符串)i.next ();
字符串pFileName = PFILE_ROOT + " +用户名;
FileInputStream fis = new FileInputStream (pFileName);
fis.read(中byteArray);/ /文件总是1 k字节
fis.close ();
processPFile(用户名、中byteArray);

代码遍历一组用户,阅读一个私人数据文件为每个用户。程序员总是假设文件1 kb大小,因此忽略了阅读()的返回值。如果攻击者可以创建一个小文件,程序将回收的其余部分之前的数据用户和治疗它,好像它属于攻击者。

示例4

下面的代码并没有检查getParameter()返回的字符串为空在调用成员函数之前compareTo(),可能导致零废弃。

(坏的代码)

例如语言:Java

字符串itemName = request.getParameter (ITEM_NAME);
如果(itemName.compareTo (IMPORTANT_ITEM) = = 0) {

…

}
…

下面的代码不检查返回的字符串是否在调用成员函数之前项目属性为空=(),可能导致零废弃。

(坏的代码)

例如语言:Java

字符串itemName = request.Item (ITEM_NAME);
如果(itemName.Equals (IMPORTANT_ITEM)) {

…

}
…

传统的防御这个编码错误的方法是:“我知道请求的值将总是存在,因为....如果它不存在,程序不能执行所需的行为所以不管我处理错误的或者仅仅是允许程序死非关联化一个null值。”But attackers are skilled at finding unexpected paths through programs, particularly when exceptions are involved.

示例5

下面的代码显示了一个系统属性设置为null,后来引用时的程序员错误地假定它将总是被定义。

(坏的代码)

例如语言:Java

System.clearProperty (“os.name”);
…
字符串操作系统= System.getProperty (“os.name”);
如果(os)。equalsIgnoreCase (Windows 95)) system . out。println(“不支持”);

例子6

下面的VB。NET代码不会检查,以确保它从myfile.txt读取50字节。这可能会导致DoDangerousOperation()来操作一个意想不到的价值。

(坏的代码)

例如语言:c#

昏暗的MyFile MyFile新文件流”。txt”, FileMode。开放,FileAccess。读取、FileShare.Read)
暗MyArray(50)字节
MyFile。读(MyArray 0 50)
DoDangerousOperation (MyArray (20))

在。net,它并不少见为程序员误解读()和相关方法,许多系统的一部分。IO类。流和读者类并不认为这是不寻常的或特殊如果只有少量的数据可用。这些类只需添加少量的数据返回的缓冲区,并将返回值设置为读取的字节数或字符。没有保证返回的数据量等于请求的数据量。

例7

这个例子将IP地址从一个用户,验证它是完整的,然后查找主机名和拷贝到缓冲区。

(坏的代码)

例如语言:C

空白host_lookup (char * user_supplied_addr) {

struct hostent *惠普;
in_addr_t * addr;
char主机名[64];
in_addr_t inet_addr (const char * cp);

/ *程序确保user_supplied_addr是正确的格式转换* /

validate_addr_form (user_supplied_addr);
addr = inet_addr (user_supplied_addr);
惠普= gethostbyaddr (addr, sizeof (struct in_addr) AF_INET);
strcpy(主机名、hp - > h_name);

}

如果攻击者提供了一个地址,似乎是格式良好的,但是地址不解决一个主机名,然后调用gethostbyaddr()将返回NULL。由于代码从gethostbyaddr不会检查返回值(cwe - 252),一个空指针(cwe - 476)将发生在调用strcpy ()。

注意,这段代码也容易受到缓冲区溢出(cwe - 119)。

示例8

在接下来的C / c++示例方法outputStringToFile打开本地文件系统中的一个文件和输出一个字符串到文件。输入参数输出和文件名包含字符串输出到文件和文件的名称。

(坏的代码)

例如语言:c++

int outputStringToFile (char *输出,char *文件名){

openFileToWrite(文件名);
writeToFile(输出);
closeFile(文件名);

}

然而,这段代码并不openFileToWrite检查返回值的方法,writeToFile closeFile验证文件正常开启和关闭,字符串被成功写入文件。这些方法的返回值应该被检查来确定检测的方法是成功的,并允许错误或意想不到的条件如以下示例。

(好的代码)

例如语言:c++

int outputStringToFile (char *输出,char *文件名){

int后=成功;

int isOpen = openFileToWrite(文件名);
如果(isOpen = =失败){

printf("无法打开文件% s”,文件名);
后=失败;

}
其他{

int isWrite = writeToFile(输出);
如果(isWrite = =失败){

printf("无法写入文件% s ",文件名);
后=失败;

}

int isClose = closeFile(文件名);
如果(isClose = =失败)

后=失败;

}
返回后;

}

例9

在以下Java示例方法readFromFile使用FileReader对象读取一个文件的内容。创建FileReader对象readFile使用File对象,使用setInputFile readFile对象初始化方法。setInputFile方法在调用readFromFile之前应该被称为方法。

(坏的代码)

例如语言:Java

私人文件readFile =零;

公共空间setInputFile(字符串inputFile) {

/ /创建readFile文件对象从字符串包含文件的名字

}

公共空间readFromFile () {

尝试{

读者= new FileReader (readFile);

/ /读取输入文件

}捕捉(FileNotFoundException ex) {…}

}

然而,readFromFile方法不会检查readFile对象为空,即没有被初始化,在创建FileReader对象和阅读之前从输入文件。readFromFile方法应该验证readFile对象是否为空,输出一个错误消息并引发一个异常如果readFile对象为空,如以下代码。

(好的代码)

例如语言:Java

私人文件readFile =零;

公共空间setInputFile(字符串inputFile) {

/ /创建readFile文件对象从字符串包含文件的名字

}

公共空间readFromFile () {

尝试{

如果(readFile = = null) {

System.err。println(“输入文件没有设置,叫setInputFile方法之前调用openInputFile”);
抛出NullPointerException;

}

读者= new FileReader (readFile);

/ /读取输入文件

}捕捉(FileNotFoundException ex) {…}
捕获(NullPointerException ex) {…}

}

观察到的例子

参考	描述
cve - 2007 - 3798	检查返回值会导致合成整数溢出和代码执行。
cve - 2006 - 4447	程序不检查返回值在调用函数时放弃特权,特权可以留给用户高于预期迫使这些功能失败。
cve - 2006 - 2916	程序不检查返回值在调用函数时放弃特权,特权可以留给用户高于预期迫使这些功能失败。

潜在的缓解措施

阶段:需求

策略:语言选择

使用一种语言,不允许这个弱点或发生提供了结构,使这个弱点更容易避免的。

选择语言的特性,比如异常处理强迫程序员预测不同寻常的条件,可能会产生异常。自定义异常处理不寻常的业务逻辑可能需要开发条件。小心不要通过敏感异常返回给用户(cwe - 209,cwe - 248)。

实施阶段:

检查结果的返回值的函数,并验证预期的值。

有效性:高

注意:检查函数的返回值通常是足够的,但是当心竞态条件(cwe - 362在并发环境中)。

实施阶段:

如果使用异常处理、捕获和抛出具体的异常而不是过大的异常(cwe - 396,cwe - 397)。尽可能在本地捕获和处理异常,异常不传播太远调用堆栈(cwe - 705)。避免未经检查或未捕获的异常可行(cwe - 248)。

有效性:高

注意:使用具体的异常,确保检查异常,帮助程序员预见并妥善处理可能发生许多不寻常的事件。

实施阶段:

确保错误消息只包含最小的细节,目标受众是有用的,没有其他人。消息需要罢工之间的平衡过于神秘的(可以迷惑用户)或过于详细的(可能揭示超过预期)。不应该透露的消息的方法被用来确定错误。攻击者可以使用详细信息完善或优化他们最初的攻击,从而增加成功的机会。

如果必须捕捉到一些细节错误,记录在日志消息,但想想会发生什么,如果日志消息可以被攻击者。高度敏感的信息,如密码永远不应该被保存到日志文件中。

避免不一致的消息可能会意外地提示攻击者对内部状态,如是否存在一个用户帐户。

暴露潜在攻击者的额外信息上下文的异常条件可以帮助攻击者确定向量是最可能成功的人除了DoS攻击。

实施阶段:

策略:输入验证

假设所有的输入是恶意的。使用一个“接受良好的“输入验证策略,即。,use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.

当执行输入验证,考虑所有可能相关的属性,包括长度,类型的输入,可接受的值的全系列,缺失或额外的输入,语法,一致性相关领域,符合业务规则。作为业务规则逻辑的一个例子,在语法上“船”可能是有效的,因为它只包含字母数字字符,但它不是有效的如果输入预计仅包含颜色,如“红”或“蓝色”。

不完全依赖寻找恶意或畸形的输入。这很可能错过至少有一个不受欢迎的输入,特别是如果代码的环境变化。这可以让攻击者有足够的空间绕过验证。然而,denylists可以用于检测潜在攻击或确定哪些输入是畸形的,应该直接驳回。

注意:执行广泛的输入验证不帮忙处理一些异常情况,但它会减少他们的出现,将使攻击者更难触发。

阶段:体系结构和设计;实现

如果程序失败,必须确保它优雅地失败(失败关闭)。可能存在一种诱惑,让项目失败不佳的情况下(如低内存条件,但攻击者可以断言控制之前,软件已经完全退出。或者,一个不受控制的失败可能会导致级联问题与其他下游组件;例如,这个项目可以发送一个信号给下游工序流程立即知道问题发生,有更好的机会复苏。

阶段:体系结构和设计

使用系统的限制,这应该有助于防止资源枯竭。然而,该产品应该仍然处理低资源条件,因为他们仍然可能发生。

检测方法

自动静态分析

自动静态分析可以用于检测不寻常的条件涉及系统资源或常见的编程习语,但不违反商业规则。

有效性:温和

手动动态分析

识别错误情况不太可能发生在正常使用和触发器。例如,在低内存条件下运行程序,运行特权或权限不足,中断一个事务之前完成,或禁用连接DNS等基本网络服务。监控软件为任何意想不到的行为。如果你触发一个未处理的异常或类似的错误被发现,由应用程序的环境中,它仍可能表明意想不到的条件并不是由应用程序本身。

会员资格

这MemberOf关系表显示额外CWE类别和视图引用这个弱点作为成员。这些信息通常是有用的在理解一个弱点符合外部信息源的上下文中。

自然	类型	ID	的名字
MemberOf	类别——CWE条目包含一组其他条目,共享一个共同的特点。	742年	CERT C安全编码标准(2008)第9章-内存管理(MEM)
MemberOf	类别——CWE条目包含一组其他条目,共享一个共同的特点。	802年	2010年前25 -资源管理风险
MemberOf	类别——CWE条目包含一组其他条目,共享一个共同的特点。	867年	2011年处于25 -弱点
MemberOf	类别——CWE条目包含一组其他条目,共享一个共同的特点。	876年	CERT c++安全编码部分08 -内存管理(MEM)
MemberOf	类别——CWE条目包含一组其他条目,共享一个共同的特点。	880年	12 - CERT c++安全编码部分异常和错误处理(ERR)
MemberOf	类别——CWE条目包含一组其他条目,共享一个共同的特点。	962年	SFP二级集群:未经检查的状态情况
MemberOf	视图——CWE条目的一个子集,它提供了一种检查CWE的内容。两个主要视图结构片(列表)和图(包含条目之间的关系)。	1003年	弱点简化映射的漏洞发布
MemberOf	类别——CWE条目包含一组其他条目,共享一个共同的特点。	1141年	SEI CERT甲骨文安全编码标准Java - 07年指导方针。异常行为(错)
MemberOf	类别——CWE条目包含一组其他条目,共享一个共同的特点。	1181年	03 SEI CERT Perl编码标准,指导方针。表达式(EXP)
MemberOf	类别——CWE条目包含一组其他条目,共享一个共同的特点。	1364年	ICS通讯:区域边界的失败

笔记

的关系

有时,当返回值可以用来显示一个错误,一个未经检查的返回值是一个code-layer失踪的实例应用程序层检查异常情况。然而,返回值并不总是需要通知异常情况。例如,过期的资源,以引用的方式传递值,修改数据,异步套接字等可能表明没有使用返回值的异常情况。

分类法映射

映射分类名称	节点ID	适合	映射节点名
SEI CERT Perl编码标准	EXP31-PL	CWE更抽象	不要压制或忽视异常

引用

(ref - 62)马克·多德约翰麦克唐纳和贾斯汀Schuh。“软件安全评估的艺术”。第七章,341页“程序构建块”。1版。艾迪生卫斯理》2006。

(ref - 62)马克·多德约翰麦克唐纳和贾斯汀Schuh。“软件安全评估的艺术”。第一章,“异常情况”,22页。1版。艾迪生卫斯理》2006。

迈克尔•霍华德(REF-44)大卫·勒布朗和Viega约翰。软件安全的“24宗罪”。“罪孽11:未能正确处理错误。”Page 183. McGraw-Hill. 2010.

(ref - 622)弗兰克·金。“前25系列——排名15 -不当检查异常或异常情况”。无软件安全研究所。2010-03-15。<http://blogs.sans.org/appsecstreetfighter/2010/03/15/top-25-series-rank-15-improper-check-for-unusual-or-exceptional-conditions/>。

内容的历史

提交
提交日期	提交者	组织
2009-03-03	CWE内容团队	主教法冠
2009-03-03	重组的新条目cwe - 703。
修改
修改日期	修饰符	组织
2009-07-27	CWE内容团队	主教法冠
2009-07-27	更新的关系
2009-12-28	CWE内容团队	主教法冠
2009-12-28	更新Applicable_Platforms、Likelihood_of_Exploit Time_of_Introduction
2010-02-16	CWE内容团队	主教法冠
2010-02-16	更新Background_Details、Common_Consequences Demonstrative_Examples、描述Detection_Factors,名字,Observed_Examples, Potential_Mitigations,引用,Related_Attack_Patterns Relationship_Notes、人际关系
2010-04-05	CWE内容团队	主教法冠
2010-04-05	更新Demonstrative_Examples Related_Attack_Patterns
2010-06-21	CWE内容团队	主教法冠
2010-06-21	更新Common_Consequences Detection_Factors Potential_Mitigations,引用
2010-09-27	CWE内容团队	主教法冠
2010-09-27	更新Potential_Mitigations
2010-12-13	CWE内容团队	主教法冠
2010-12-13	更新Relationship_Notes
2011-03-29	CWE内容团队	主教法冠
2011-03-29	更新描述、人际关系
2011-06-01	CWE内容团队	主教法冠
2011-06-01	更新Common_Consequences
2011-06-27	CWE内容团队	主教法冠
2011-06-27	更新Common_Consequences Related_Attack_Patterns,关系
2011-09-13	CWE内容团队	主教法冠
2011-09-13	更新的关系,Taxonomy_Mappings
2012-05-11	CWE内容团队	主教法冠
2012-05-11	更新的关系
2012-10-30	CWE内容团队	主教法冠
2012-10-30	更新Potential_Mitigations
2013-02-21	CWE内容团队	主教法冠
2013-02-21	更新的关系
2014-07-30	CWE内容团队	主教法冠
2014-07-30	更新Demonstrative_Examples、人际关系
2015-12-07	CWE内容团队	主教法冠
2015-12-07	更新的关系
2017-01-19	CWE内容团队	主教法冠
2017-01-19	更新的关系
2017-11-08	CWE内容团队	主教法冠
2017-11-08	更新Modes_of_Introduction、引用关系,Taxonomy_Mappings
2019-01-03	CWE内容团队	主教法冠
2019-01-03	更新的关系,Taxonomy_Mappings
2019-06-20	CWE内容团队	主教法冠
2019-06-20	更新描述、人际关系
2020-02-24	CWE内容团队	主教法冠
2020-02-24	更新Potential_Mitigations、人际关系
2020-06-25	CWE内容团队	主教法冠
2020-06-25	更新Potential_Mitigations
2020-12-10	CWE内容团队	主教法冠
2020-12-10	更新Potential_Mitigations
2021-03-15	CWE内容团队	主教法冠
2021-03-15	更新Demonstrative_Examples、人际关系
2021-07-20	CWE内容团队	主教法冠
2021-07-20	更新的关系
2022-04-28	CWE内容团队	主教法冠
2022-04-28	更新的关系
2023-01-31	CWE内容团队	主教法冠
2023-01-31	更新描述,Potential_Mitigations
以前的条目名称
改变日期	以前的条目名称
2010-02-16	不适当的检查异常情况

常见的弱点枚举

cwe - 754:不当检查不寻常或异常情况


	站点地图\|使用条款\|隐私政策\|联系我们\| 使用常见的弱点枚举(CWE)和相关的引用从这个网站的使用条款。CWE赞助的美国国土安全部(DHS)网络和基础设施安全机构(CISA)和管理的国土安全系统工程和发展研究所这是由(HSSEDI)manbetx客户端首页(斜方)。版权©2006 - 2023,斜方公司。manbetx客户端首页CWE、水煤浆、CWRAF, CWE标志是斜方公司的商标。manbetx客户端首页