cwe与sans的top25威胁翻译.docx

cwe与sans的top25威胁翻译.docx

《cwe与sans的top25威胁翻译.docx》由会员分享，可在线阅读，更多相关《cwe与sans的top25威胁翻译.docx（66页珍藏版）》请在冰豆网上搜索。

cwe与sans的top25威胁翻译

2011CWE/SANS前25个最危险的软件错误

简介

2011CWE/SANS前25个最危险的软件错误是一个可以导致严重的软件漏洞有最普遍和关键性误差的列表。

这些经常很容易找到，也很容易消减。

这些是危险的，因为经常允许攻击者完全接管软件，偷窃数据，或者组织软件工作。

前25列表是一个通过标识和避免太过寻常出现在软件装配之前的错误，来教育和帮助程序员防止各种各样折磨软件行业的漏洞。

软件客户也可以用同样的列表帮助他们寻求更多安全软件。

软件研究人员可以用前25来关注一个对于所有已知的安全漏洞狭隘的但重要的小结合。

最后，软件管理者和首席信息官可以用这前25列表作为一个进步量尺，以此来努力来保护软件的安全。

这个列表是系统网络安全协会，MITRE和许多顶级美国和欧洲的软件安全专家合作的结果。

它的影响了SANS前20攻击向量和MITRE的共同漏洞列举（CWE）的发展经验。

在国土安全部的状态网络安全部门的支持下，MITRE维护CWE网页，对前25程序错误展开详细的描述，同时包括对错误减轻与避免的权威指导。

CWE页面包括超过800个可导致可利用漏洞的程序错误，设计错误和结构错误的数据。

2011年前25在2010年列表上做了改进，但是精神和目标仍相同。

今年的前25条目有限使用从超过20个不同的组织的输入，这些组织基于普遍率，重要性和开发的可能性评估各自的漏洞。

用了前25列表的CWSS来对最后的结果进行评分和排名。

前25列表涵盖了最有效的减轻错误的一小部分，可以帮助开发者减少或消除全部前25的漏洞，同时也包括许多数百被CWE记录的漏洞。

对前25的使用指南

用户

活动

安全编程新手

阅读简短的清单，然后检查“MonsterMitigations”部分来看在实践中改变很小可以对前25有很大的影响。

最初选择少量的不足，看详细的CWE对更多不足信息的描述，包括代码示例和具体措施。

有经验的安全开发者

使用通用的25个座位检查的提醒，记录在最近变得普遍的事件。

求教的看在对其他为成为最后25不足的顶页，包括正在迅速增长或已经增长迅速的不足。

如果你对流行的漏洞已经熟悉，查询详细的CWE描述去看“相关的CWE们”，连接到你还未完全考虑的变种。

建立你自己的“MonsterMitigations”部分，因此一可以对自己的措施实践有清晰的认识，对于你的瓶颈也更有效

考虑建立一个自定义的“顶级”列表，适合需要和实践。

查询共同漏洞危险分析框架页面，用于通用创建顶级列表的框架，来看附录C对于怎样完成今年前25的描述。

发展你自己的年度25候选列表，根据你自己的普遍及重要因素，包括其他希望参考的因素，建立一个度量和对比的结果与同事相比，可能会产生一些丰富的描述。

软件工程经理

解决前25对于努力实现软件安全是一个早期的步骤。

战略性的可能在努力覆盖，包括建立安全成熟度模型，SAFECode，OpenSAMM，MicrosoftSDL，和OWASPASVS。

检查“MonsterMitigations”部分对于决定采用何种最适合的方法，或建立自己的“MonsterMitigations”及标出前25与他们的联系。

考虑建立一个自定义的“顶级”列表，适合需要和实践。

查询共同漏洞危险分析框架页面，用于通用创建顶级列表的框架，来看附录C对于怎样完成今年前25的描述。

发展你自己的年度25候选列表，根据你自己的普遍及重要因素，包括其他希望参考的因素，建立一个度量和对比的结果与同事相比，可能会产生一些丰富的描述。

软件测试人员

阅读简短的清单，考虑如何整合这些漏洞相关知识进入你的测试。

如果你处在一个开发人员友好的竞争中，你可以发现一些惊喜在风口浪尖，甚至是剩下的CWE。

对于每个CWE入门者在详细的部分，你可以从来自“技术细节”链接的检测方法获得信息。

回顾CAPEC标识对于关于攻击类型的观念，可以发起漏洞。

软件客户

认识到市场常常驱动供应商提供功能丰富的软件，但是安全可能没有郑重的考虑。

作为一个消费者，你有权利去影响供应商来提供更多的安全产品，让他们知道，安全对你来说十分重要。

用前25来帮助有行为准则的软件供应商来建立最低限度的期望。

考虑使用前25作为联系语言的部分，在软件采集语言的过程中。

SANS应用安全获得语言网站提供以用户为中心的语言，是来自于OWASP安全软件合同的附件，以此在消费者与供应商之间来提供描述期望与兑现的责任的框架。

其他信息可以从美国国土安全局的收购和外包工作组获得。

商议共同的漏洞危害分析框架页面作为通用框架，来奖励前N的列表可以满足你的需要。

对于你实用的软件产品，密切关注那些产品中被公开报道的漏洞。

看他们中是否与前25相关（或者你自己的客户清单），如果有，联系你的供应商来解决这些进程中那些里减少风险，这些漏洞继续引入到代码中。

看到其他形成前25的漏洞顶尖总结，这将包括知识开始增长到流行或者重要的漏洞，它们有可能成为未来的问题。

教育工作者

在简要的清单开始，一些训练材料也可用。

2010前25的用户

观察改变的部分，因为许多表面就改变的，今年的努力组织结构更加优化。

对前25简要的列出：

排名

分数

标号

名称

1

93.8

CWE-89

SQL命令中实用的特定特定元素处理不当（SQL注入）

2

83.3

CWE-78

OS命令中使用的特定元素处理不当（命令攻击）

3

79.0

CWE-120

没有检查输入大小对缓冲区进行复制（经典的缓冲区溢出）

4

77.7

CWE-79

网页架构保持失败（跨平台脚本攻击）

5

76.9

CWE-306

对判定函数缺少验证

6

76.8

CWE-862

缺少权威性认证

7

75.0

CWE-798

使用硬编码的证书

8

75.0

CWE-311

缺少对敏感数据的加密

9

74.0

CWE-434

对危险类型文件的上载不加限制

10

73.8

CWE-807

在安全决策中依赖不被信任的输入

11

73.1

CWE-250

执行冗余的特权

12

70.1

CWE-352

跨站点伪造请求（CSPF）

13

69.3

CWE-22

不当地将路径名限制为受限目录（路径穿透）

14

68.5

CWE-494

下载代码却不做完整性检查

15

67.8

CWE-863

错误的认证

16

66.0

CWE-829

包含来自非信任的控制范围函数

17

65.5

CWE-732

对临界资源分配的错误许可

18

64.6

CWE-676

使用具有潜在危险的函数

19

64.1

CWE-327

使用被破解或有风险的加密算法

20

62.4

CWE-131

对缓冲区大小计算错误

21

61.5

CWE-307

对过多的认证意图错误的限制

22

61.1

CWE-601

重定向到不受信任站点的URL（开放转移）

23

61.0

CWE-134

不受控制的格式字符串

24

60.3

CWE-190

整数溢出或无限循环

25

59.9

CWE-759

单一使用单向哈希函数

CWE-89-SQL注入-交付这些危害性的安全隐患在2011。

在数据丰富的软件应用，SQL注入意味着通向王国偷窃的钥匙。

CWE-78，OS命令注入，是引用与操作系统交互处。

传统的缓存溢出（CWE-120）排在第三，这些年来还是有害的。

跨站点的脚本（CWE-79）是在各处毒害网站的。

排在第5是丢失认证（CWE-306）对于判定函数。

前25名的Category-Based视图

这部分把条目到三个高级类别中使用了2009年的前25：

●安全组件之间的交互

●有风险的资源管理

●多孔防御

安全组件之间的交互

这些漏洞与不安全的方式发送和接收数据之间单独的组件，模块，程序，进程，线程，或系统有关系。

对于每一个漏洞，它的排名一般列表中在方括号中被提供。

排名

CWEID

名称

[1]

CWE-89

在SQL命令中实用的特定特定元素处理不当（SQL注入）

[2]

CWE-78

在OS命令中使用的特定元素处理不当（命令攻击）

[4]

CWE-79

网页架构保持失败（跨平台脚本攻击）

[9]

CWE-434

对危险类型文件的上载不加限制

[12]

CWE-352

跨站点请求伪造（CSRF）

[22]

CWE-601

重定向到不受信任站点的URL（开放转移）

有风险的资源管理

这个类别中的，漏洞与软件不正确管理创建，使用，转让，或破坏重要系统资源有关。

排名

CWEID

名称

[3]

CWE-120

没有检查输入大小对缓冲区进行复制（经典的缓冲区溢出）

[13]

CWE-22

不当地将路径名限制为受限目录（路径穿透）

[14]

CWE-494

下载代码却不做完整性检查

[16]

CWE-829

包含来自非信任的控制范围函数

[18]

CWE-676

使用具有潜在危险的函数

[20]

CWE-131

对缓冲区大小计算错误

[23]

CWE-134

不受控制的格式字符串

[24]

CWE-190

整数溢出或无限循环

多孔防御

这个类别中，威胁与防御技术常常被误用，滥用，或仅仅是忽略有关。

排名

CWEID

名称

[5]

CWE-306

对判定函数缺少验证

[6]

CWE-862

缺少权威性认证

[7]

CWE-798

使用硬编码的证书

[8]

CWE-311

缺少对敏感数据的加密

[10]

CWE-807

在安全决策中依赖不被信任的输入

[11]

CWE-250

执行冗余的特权

[15]

CWE-863

错误的认证

[17]

CWE-732

对临界资源分配的错误许可

[19]

CWE-327

使用被破解或有风险的加密算法

[21]

CWE-307

对过多的认证意图错误的限制

[25]

CWE-759

单一使用单向哈希函数

排名前25位的组织

为每个单独的去漏洞条目提供的额外信息。

主要受众是软件程序员和设计师。

排名

漏洞在常用表中的排名

分数总结

是对于这个漏洞的个体评级和分数的总结，包括流行，重要性和调整分数。

CWEID和名字

对于漏洞的CWE标识和简称

支持信息

关于漏洞的补充信息，可能对决策者对于未来优化条目有用。

描述

简短，非正式的描述关于漏洞和后果的特性。

描述避免太过深入的挖掘技术细节。

避免和移植

开发者可用的移植或者限制漏洞的步骤。

开发者可能选择一个或多个移植方法来适应自身需求。

记录下技术多样性的影响，多种技术可能会综合在一起，为了更好的深度防御。

关于CWE

其他CWE条目与前25有关的漏洞，注：

这个列表是说明性的，不是全面的

通常的父类

一个或多个指示对于通常的CWE条目，你可以看到深度和广度。

相关的攻击类型

CAPEC关于攻击的条目，可能成功地反击了漏洞。

注：

这个列表不是很必须。

其他指示

连接更多的详情，包括源代码示例演示漏洞，探测方法等。

支持信息

每个排名前25位的条目包括支持数据字段的普遍漏洞点，技术的影响和其他信息。

每个条目还包括以下数据字段。

字段

描述

攻击频率

漏洞多久发生一次并被攻击者利用。

检测难易

攻击者找到这个漏洞是多么的简单。

修复成本

很多努力为了适合这个漏洞。

攻击者意识

攻击者将要意识到这个特别的漏洞的可能性，探测方法和探索方法。

CWE详细描述

本节为每个单独的CWE条目提供细节，随着更多信息的链接。

看到前25的组织和各领域的解释。

1CWE-89：

SQL命令中实用的特定特定元素处理不当（SQL注入）

总结

流行程度

高

后果

数据丢失，安全绕过

修复成本

低

检测难易

容易

攻击频率

经常

攻击者意识

高

描述

最近，似乎软件都是关于数据：

取出放入数据库。

传递信息，并将其发送给其他地方为了爱好和利润。

如果攻击者可以影响SQL，是你使用与数据库通信，然后突然你所有的乐趣和利润他们都知道。

如果你使用SQL进行安全控制，例如，用户认证，攻击者可能会改变这些查询的逻辑绕过安全。

他们可以修改查询来窃取，记录，或者改变你的基础数据。

他们甚至会每次窃取一个字节的数据如果必要，他们有耐心也知道怎么做。

2011年，SQL注入对许多知名组织的妥协负责，包括索尼，PBS，MySQL.com，安全公司HBGaryFederal和许多其他公司。

预防和移植

架构和设计

使用审查库或框架为不允许这个漏洞出现提供了结构，使这个漏洞更容易避免。

例如，考虑使用持久性层，如Hibernate或EnterpriseJavabean，它可以提供重要的保护防止SQL注入，如果使用得当。

架构和设计

如果可用，使用结构化机制，自动执行数据和代码之间的分离。

这些机制可以提供相关的引用，编码，自动验证，而不是依赖开发人员在每一点上提供此功能，生成输出。

流程使用预处理语句的SQL查询，参数化查询或存储过程。

这些功能应该接受和支持强类型参数或变量。

不能动态地构建和执行查询字符串，使用“执行”或类似功能的这些特性，因为有重新引入SQL注入的可能性。

架构和设计，操作

使用所需的最低特权运行代码来完成必要的任务。

如果可能的话，创建有限的独立帐户权限，只用于一个任务。

这样，一个成功的攻击不会立即让攻击者访问其他软件和环境。

例如，数据库应用程序很少需要运行数据库管理员，特别是在日常操作。

具体来说，遵循最小特权原则是在创建SQL数据库用户帐户时候。

数据库用户应该只给使用他们的帐户必要的最低特权。

如果系统的需求表明，用户可以阅读和修改自己的数据，因此限制他们的权限，所以他们不能读/写别人的数据。

在所有数据库对象使用最严格的权限可能，例如只执行存储过程。

架构和设计

对于任何在客户端执行的安全检查，要确保这些检查复制在服务器端，为避免CWE-602。

攻击者可以绕过客户端检查，通过检查被执行后修改值，或通过改变客户端来完全删除客户端检查。

然后，这些修改的值将被提交到服务器。

实现

尽管有风险，但是如果你需要使用动态生成来查询字符串或命令，在这些参数中需要正确引用参数和任何特殊字符转义。

最保守的方法是离开或者过滤所有字符，不通过一个极其严格的白名单（如一切的不是字母数字或空白的字符）。

如果仍然需要一些特殊字符，如空格，每个参数封装在引号转义，小心参数注入。

这些特性可以在数据库或编程语言中，而不是建立自己的实现，。

例如，OracleDBMS_ASSERT包可以检查或执行参数一定的属性，使他们更容易受到SQL注入。

对于MySQL，mysql_real_escape_string（）API函数可用于C和PHP。

实现

假设所有的输入都是恶意的。

使用一个“接受已知的好的信息”，即输入验证策略，可接受的输入，使用白名单，严格遵守规范。

拒绝任何不严格符合规范的输入，或将其转换。

不完全依赖寻找恶意或不正常的输入（即，不依赖于一个黑名单）。

然而，黑名单可以用于检测潜在的攻击或确定哪些输入是不正常的，应该直接被驳回。

当执行输入验证，考虑所有可能相关的属性，包括长度，类型的输入，可接受的值，缺失或额外的输入，语法，一致性相关领域，符合业务规则。

业务规则逻辑的一个例子，“船”在语法上可能是有效的，因为它只包含字母数字字符，但它不是有效的，就像你期望的颜色，如“红色”或“蓝色”。

当构造SQL查询字符串，使用严格的白名单，基于请求中的参数的期望值限制字符集。

这将间接限制的范围攻击，但这种技术没有适当的重要输出编码和避免。

注意，尽管输入验证可能提供一些深度防护，适当的输出编码，避免和引用是防止SQL注入最有效的解决方法。

这是因为它有效地限制了将出现在输出。

输入验证不会总是阻止SQL注入，尤其是如果你需要支持自由格式的文本字段可以包含任意字符。

例如，”O'reilly”这个名字可能会通过验证步骤，因为在英语语言它是一种常见的姓氏。

但是，它不能直接插入到数据库，因为它包含了““撇号的特性，这将需要去掉或以其他方式处理。

在这种情况下，剥离撇号可能减少SQL注入的风险，但会产生不正确的行为，因为错误的名字将被记录下来。

在可行的情况下，完全禁止元字符可能是最安全的，而不是去掉它们，这将提供一些深度防御。

数据进入数据库后，后来过程可能忽视去掉元字符而使用，你可能没有控制这些流程。

架构和设计

当可接受的对象集，如文件名或url，是有限的或已知的，创建一个映射从一组固定的输入值（比如数字id）到实际的文件名或url，并拒绝所有其他输入。

实现

确保错误消息只包含最小的细节，是有用的目标受众，并没有其他。

消息需要平衡又不过于限制。

他们应该不一定揭示被用来确定错误的方法。

如此详细的信息可以用来改进原攻击以此增加成功的机会。

如果错误必须跟踪一些细节，捕捉他们的日志消息，但想想可能发生的，如果日志消息可以被攻击者得到。

避免任何形式对高度敏感信息的记录，如密码。

避免不一致的消息可能会意外地提示攻击者内部状态，如用户名是否有效。

在SQL注入的上下文中，错误消息显示SQL查询的结构可以帮助攻击者成功攻击裁剪字符串。

操作

使用应用程序防火墙，可以检测攻击这个漏洞。

它在有益的情况下，代码不能固定（因为由一个第三方提供），作为一项紧急预防措施，更全面的保证软件措施被应用，或者提供深度防御。

有效性：

温和

注：

应用程序防火墙不可能涵盖所有可能的输入向量。

此外，攻击技术可能绕过保护机制，比如使用不正常的输入，仍然可以由组件接收处理这些输入。

根据功能，应用程序防火墙可能会无意中拒绝或修改合法请求。

最后，可能需要定制一些手动工作。

操作，实现

如果你使用的是PHP，配置你的应用程序，以便它不使用register_globals。

实现期间，开发你的应用程序，以便它不依赖于这个特性，但是小心实现register_globals的模拟CWE-95等漏洞，CWE–621或类似的问题。

相关的CWE

CWE-90

在LDAP查询中特殊元素使用不当（LDAP注入）

CWE-564

SQL注入：

冬眠

CWE-566

授权旁路通过用户控制SQL主键

CWE-619

悬空数据库游标（光标注入）

相关攻击模式

CAPEC-IDs：

[查看所有]

7，66，108，109，110

2CWE-78：

OS命令中使用的特定元素处理不当（命令攻击）

总结

流行程度

中

后果

数据异常

修复成本

中

检测难易

容易

攻击频率

经常

攻击者意识

高

描述

软件在网络之间通常是一个局外人与操作系统内部的桥梁。

当你调用另一个程序上的操作系统，但你允许不受信任的输入输入的命令字符串生成执行计划，那么你就邀请攻击者穿过那座桥来执行自己的命令，而不是你的命令。

预防和移植

架构和设计

如果可能的话，使用库调用，而不是用外部流程重建所需的功能。

架构和设计操作

在一个“监视”或类似封闭环境运行代码，执行严格的流程和操作系统之间的边界。

这可能有效地限制哪些文件可以在一个特定的目录下或访问哪些命令可以执行软件。

操作系统的例子包括Unixchroot见识，AppArmor队，SELinux。

在一般情况下，托管代码可能会提供一些保护。

例如，java。

在JavaSecurityManagerFilePermission允许用户指定文件操作的限制。

这可能不是一个可行的解决方案，而且它只限制了影响操作系统的部分；应用程序的其余部分仍可能被威胁。

应该注意避免CWE-243和相关漏洞。

有效性：

有限

注：

这种能缓解的有效性取决于的预防功能所使用的特定的封闭环境或监视，只可能有助于减少攻击的范围，比如限制某些系统调用或限制攻击者可以访问文件系统的一部分。

架构和设计

对于任何将被用来生成一个命令执行的数据，保持尽可能多的从外部控制的的数据。

例如，在web应用程序中，这可能需要将数据存储在会话的状态，而不是向在一个隐藏的表单字段向客户机发送。

架构和设计

对于任何在客户端执行的安全检查，确保这些检查复制在服务器端，以避免CWE-602。

攻击者可以在检查被执行后通过修改值绕过客户端检查或通过完全删除客户端检查来改变客户端。

然后，这些修改的值将被提交到服务器。

架构和设计

使用审查库或框架为不出现这个漏洞提供了结构，使这个漏洞更容易避免。

例如，考虑使用ESAPI编码控制或类似的工具，库或框架。

这些将帮助程序员编码输出的方式不容易出错。

实现

尽管有风险，但是如果你需要使用动态生成来查询字符串或命令，在这些参数中需要正确引用参数和任何特殊字符转义。

最保守的方法是离开或者过滤所有字符，不通过一个极其严格的白名单（如一切的不是字母数字或空白的字符）。

如果仍然需要一些特殊字符，如空格，每个参数封装在引号转义，小心参数注入（CWE-88）。

实现

如果要执行的程序允许参数被指定为一个输入文件或标准输入，那么考虑使用传递参数模式，而不是命令行。

架构和设计

如果可用，使用结构化机制，自动执行数据和代码之间的分离。

这些机制可以提供相关的引用，编码，自动和验证，而不是依赖开发人员在每一点上提供此功能，生成输出。

一些语言提供多种功能，可用于调用命令。

在可能的情况下，使用一个字符串识别任何函数调用命令shell，并用个人参数编写替换函数，。

这些函数通常执行适当的引用或过滤参数。

例如，在C语言中，system（）函数接受一个字符串，该字符串包含整个执行命令，而execl（），execve（）和其他每个参数需要一个字符串数组。

在Windows中，CreateProcess（）只接受一个参数。

在Perl中，如果system（）提供了一组参数，那么它将引用的多个参数。

实现

假设所有的输入都是恶意的。

使用一个“接受已知的好的信息”，即输入验证策略，可接受的输入，使用白名单，严格遵守规范。

拒绝任何不严格符合规范的输入，或将其转换。

不完全依赖寻找恶意或不正常的输入（即，不依赖于一个黑名单）。

然而，黑名单可以用于检测潜在的攻击或确定哪些输入是不正常的，应该直接被驳回。

当执行输入验证，考虑所有可能相关的属性，包括长度，类型的输入，可接受的值，缺失或额外的输入，语法，一致性相关领域，符合业务规则。

业务规则逻辑的一个例子，“船”在语法上可能是有效的，因为它只包含字母数字字符，但它不是有效的，就像你期望的颜色，如“红色”或“蓝色”。

当构建操作系统命令字符串，使用严格的白名单，基于请求中的参数的期望值限制字符集。

这将间接限制的范围攻击，但这种技术没有适当的重要输出编码和避免。

注意，尽管输入验证可能提供一些深度防护，但是适当的输出编码，避免和引用是防止OS命令注入最有效的解决方法。

这是因为它在输出进行了有效的限制。

输入验证不会总是阻止OS命令注入，尤其是当你需要支持自由格式的文本字段时会包含任意字符。

例如，当调用一个邮件程序，你可能需要允许主题字段包含溢出微点，输入”；“和”>“字符也将需要忽略或以其他方式处理。

在这种情况下，剥离的字符可能会减少OS命令注入的风险，但会产生不正确的行为。

因为这个主题字段将不会被认为是用户的需求，这可能是一个小小的不便，但可能更重要的是程序依赖于结构良好的主题行，将消息传递给其他组件。

即使在你的验证犯了错（忘记一个输入字段），适当的编码仍可能保护你免受基于注入的攻击。

只要不是做隔离，输入验证仍然是一个