常见的弱点枚举

CWE术语表定义

2009 CWE / SANS -最终稿修改和讨论

总结最近的前25名的讨论

日期:2009年10月29日

• CWE - 78条目更新以反映更改名称从CWE 1.6。没有其他的变化。

日期:2009年7月27日,

• 更新相关的攻击模式和名称,以反映变化CWE 1.5。还要注意,个别条目在CWE网站上被修改,以包括新示范和观察到的例子。

日期:2009年5月27日

• 更新的措施之一,相关的攻击模式,和名称反映CWE 1.4的变化。还要注意,个别条目在CWE网站上被修改,以包括新示范例子。

日期:2009年3月10日

• 在最初公布的名单,我们收到了大量来自不同社区的反馈。在接下来的几个月我们将使用此反馈,以帮助改善列表本身,以及建议如何可以在更大的上下文中使用安全软件开发生命周期。
• 更新的缓解措施,以减少重复和更一致的变化也反映在CWE 1.3。添加了一些新的缓解措施等其他阶段测试和操作。
• 添加文档和博客页面

日期:2009年1月11日,

• 改进文本可读性和可理解性的讨论
• 添加的剩余部分建议缓解措施CWE条目
• 取得了重大更新CWE条目在前25名中,重点示范例子,缓解措施,后果,引用和扩展描述。
• 添加完“尖端”的cw列表没有前25名
• 创建了一个CWE排名前25位的视图(CWE - 750)和支持PDF生成图形可视化
• 收集最终支持报价
• 写的过程文档
• 确定因素列表
• 重组主文档

日期:2009年1月8日

• 我们又收到很多评论从十几人,所以我们都无法单独应对。每个草案已经大约5到8新审查员。
• 相关的许多评论单个条目的具体措施之一。CWE条目被更新,以反映这些变化。
• 一些人提供实质性的评论的威胁模型,这是一个新成员。围绕明显矛盾的反馈和其他问题的描述。因此,这是清理有点最终稿。
• 许多贡献者最后请求条目,他们认为重要的包容。在某些情况下,从不同的人有相互矛盾的建议,特别是对患病率。相同的条目将由一个人见过广泛但更经常被另一个人。这使得最后的决策更加困难。一个单独的“尖端”文档将发表,将覆盖的问题没有最终名单。
• 许多贡献者发现列表条目包含在不同的抽象级别,如XSS从某种程度上说,在另一个层面输入验证。这是有效地避免由于不同的反馈我们收到了,但是也许明年我们能够解决这个问题。常见问题作进一步的解释。
• 一些贡献者为额外的改进提供了伟大的思想,但需要太长时间实施并提交每个人进行审查。我们将记住这些建议当2010年是时候更新列表。

排名前25位的晋升,降职

• 促进cwe - 330随机性
  • 选择在cwe - 400因为一些投票反对cwe - 400。cwe - 400也不太严重的威胁模型,这对可用性作为一个低优先级的完整性和机密性
  • 也可以部分会话处理等领域受益
• 降级cwe - 252:不返回值
  • 多个建议降级
  • 影响往往不是代码的执行,这是在其他连续波有报道。结果通常是“没有”(只有一个错误),或拒绝服务。
  • 一些倡导cwe - 248未捕获的异常。理想情况下,一个共同的父母会是有用的。最近的项目是CWE - 391, CWE团队定于弃用,因为它结合了多个问题。替代不会准备在前25名被释放之前,自CWE团队设计一个基本的错误处理模式来解决这个条目和类似相关问题CWE - 703未能处理异常情况。
• 取代cwe - 470(不安全的反射)与母公司cwe - 94代码注入
  • 允许更自然的提到eval注入等等

其他的变化

• 威胁模型简化修改和删除不一致。
• 更新的讨论对于大多数条目。一些讨论领域没有很好地描述了软弱或为什么它是非常重要的。
• 许多应对变化
• 创建“处于”部分列出的缺点,几乎到前25名
• 删除了所有评论和contributor-only部分。所有的内容在这个新的草案将被公开。
• 创造了新的介绍
• 重组部分相关的选择标准和支持数据字段;大多数人进入一个附录。
• 添加了一个常见问题部分

日期:2008年12月22日

谢谢你参与这项工作。我们收到很多评论第二稿,其中许多人还没有回顾了初稿。我们收到了很多积极的反馈表明,我们正朝着正确的方向前进。

第三个草案中提供了一个单独的消息。

安排和联系

注意:我们认为这是最重要的草案为您反馈。我们希望你的反馈在12月30日,但最好是尽快。我们将发布一个最终稿后不久30日接受最后的评论,冻结1月5日的文档。预期的官方名单的发布日期是1月12日,2009年。

反馈可以发送到任何:

排名前25位的球队(san /斜方)
史蒂夫Christey
Bob Martin

建议的活动

你可以做一个或多个活动。不管你花5分钟或两个小时,你的投入将有助于改善。

• 告诉我们如果你同意添加(删除),和我们的理由更改
• 告诉我们如果你认为这是重要的修改直接插入文档(我们正在考虑使用CWE web页面的链接)
• 审查措施之一为单独的条目,并建议修改
• 审查的威胁模型确定,半职业的攻击者,和相关数据字段的新细节”组织和选择排名前25位的部分
• 检查项目,仍在考虑推广到前25名。如果你想要这些物品被提升,然后显示一个弱点,应该从前25名中删除。
• 检查项目,正在考虑搬家的前25位。如果你同意,他们应该被删除,那么建议交替可以晋升为前25名。
• 审查相关的连续波和建议添加
• 审查任何单个条目的文本

总结收到评论稿2

• 初稿,我们收到的评论一组不同的十几人,其中许多人在第一轮没有提供反馈。一些评论一般和具体的,所以有一些可靠的反馈。每一个被认为是阅读和发表评论,但由于评论的数量,我们无法单独应对每一个。
• 我们收到一些大的软件供应商反馈积极参与改善他们自己的安全。结果,他们远远领先对一般的开发人员,这样,他们通常会解决基本问题,遇到新的弱点。这可能与许多顾问提供反馈,。我们正在努力平衡这些先进厂商的经验与日常开发人员可能会遇到什么。
• 一些人强烈推荐CWE类型转换和/或其他相关问题数据解析。在CVE,我们为这些问题没有足够的流行信息,因为大多数供应商不列出潜在原因。这种类型的问题也有一些报道,缓冲区溢出。相反,我们添加计算错误,结合输入验证和不返回值,应包括这些数据分析错误;此外,证据确凿的数字错误,至少在CVE(具体来说,整数溢出是CVE前10项,和前3操作系统供应商基于不完整的2008年的数据)。
• 有重复的建议提供更多详细的措施之一。我们将使用在CWE条目本身措施之一。CWE团队中的这将减少重复的工作,但排名前25位的用户也将有最新的访问到最新的缓解建议。CWE的然而,在当前公共版本,我们注意到,许多应对没有列出排名前25位的条目。CWE团队正在积极解决这个问题,和当前包含最新的草案文本移植。然而,我们计划从最终排名前25位的列表中移除措施之一,并指向CWE的URL。
• CVE漏洞趋势数据为2007年和2008年再生利用新CVE漏洞类型没有报道在以前趋势出版物;这包括缺陷如空指针取消引用,明文传输,公开的方法。虽然2007年和2008年的数据是不完整的,没有出现任何的新缺陷类型将进入CVE的前10名。
• 优先级根据严重程度和患病率持续在这一轮。然而,我们没有足够的数据来建立流行,尤其是对设计相关的问题。所以我们避免试图应用一个具体的公式。相反,我们使用的严重程度和患病率估计优先考虑哪些弱点应该提升到前25名中,或删除。
• 一位评论家注意到一些不一致,建议定义的值被用于患病率、修复成本,等等。这是在这一轮。

改变从第二稿、第三稿

缓解措施

这对每个条目包含许多新的缓解措施草案。我们没有资源来提供非常详细的描述每一个缓解,然而。

注意,我们将重用CWE的措施之一,而不是创建新的。这意味着我们将修改每个CWE Potential_Mitigations领域。一般来说,我们将进一步增强CWE的名单上。这已经发生。

我们计划从最后文件删除措施之一,而代之以CWE条目的链接和锚,指导用户直接移植CWE的一部分。请告诉我们如果你认为有充分的理由包括文档本身的措施之一。

考虑晋升

这些CWE条目不在评选名单之列,但他们可以考虑添加其他cw移除。

• cwe - 330:使用不够随机值
• cwe - 400:不受控制的资源消耗

考虑删除

这些连续波目前在前25名中,但是他们没有任何强有力的倡导者。他们可能会被删除的其他缺点。

• cwe - 252:不返回值
• cwe - 470:不安全的反射
  • 可以用eval注入合并和其他代码注入(cwe - 94)

删除项目几乎没有支持者

许多条目“考虑”名单上的几个草稿,但几乎没有积极倡导者和从来没有提升到前25名。这些被转移到一个底部截面,应视为永久从考虑删除。这些都是在“弱点从未添加到前25”部分。

添加条目

• cwe - 116:编码不足或转义输出
  • 重要:请参见下面的“特别注意”
  • 积极推动由多个贡献者;许多injection-related问题的一个核心方面。
• cwe - 682:不正确的计算
  • 理由:看评论总结子弹类型转换
  • 这个显式地列出CWE - 681(不正确的数值类型之间的转换)作为CWE有关
• cwe - 319:明文传输的敏感信息
  • 理由是:提升由于流行/严重性后其他条目被删除
• cwe - 642:外部控制关键用户状态数据
  • 理由是:取代了更具体的cwe - 565
• cwe - 209:信息泄露在一条错误消息
  • 理由是:提升由于流行/严重性后其他条目被删除;积极支持一些贡献者

删除条目

现在这些都是“弱点从排名前25位的降级”部分。

• cwe - 184:不完整的黑名单
  • 理由:不积极支持
  • 现在的“相关CWE”输入验证(CWE-20)
• cwe - 180:规范化之前验证
  • 理由:不积极支持
  • 现在的“相关CWE”输入验证(CWE-20)
• cwe - 98:远程文件包含
  • 现在“相关CWE”在外部控制文件名(CWE - 73)
• cwe - 565:使用cookie的安全决策
  • 现在“相关CWE”作为一个孩子的外部控制的关键用户状态数据(CWE - 642)
• cwe - 749:不安全的公开的方法
  • 合并成更一般的cwe - 285(访问控制)
  • 这些被怀疑在2008年前十CVE,但这似乎并不如此

一般修改

• 上市的威胁模型确定,半职业攻击者”。
• 提供定义的值被用于弱点患病率、修复成本,易于检测等。
• 重新排序的结果和软弱患病率最高,因为这些都是在前25名中包含的主要因素。
• 删除一些类别。
• 澄清cwe - 494适用于任何代码下载并执行,不仅仅是“移动代码。”

特别注意cwe - 116(编码不足或转义输出)

添加cwe - 116可能是一个意外的人认为SQL注入,XSS和其他注入风格问题主要是输入验证问题(CWE-20、输入验证不足)。这反映了越来越多的信仰的重要性,输出编码由web应用程序安全社区和其他如本文档的编辑。虽然注入攻击可能减轻使用输入验证,但是最终的解决方案在于输出编码,因为有时危险字符必须是输出的一部分。

cwe - 116和CWE-20有着密切的关联,因为根据结构化信息的本质,正确输入验证可以间接地阻止特殊字符改变结构化信息的意义。例如,通过确认数字ID字段应该只包含0 - 9的字符,程序员有效地防止注入攻击。然而,输入验证并不总是足够的,特别是当数据类型必须支持的那么严格。考虑一个SQL注入场景,在该场景中,一个姓是插入一个查询。“O ' reilly”这个名字可能会通过验证步骤,因为它是一种常见的姓氏在英语语言。但是,它不能直接插入到数据库,因为它包含了“”角色,这将需要逃跑或其他处理。在这种情况下,剥离”的“可能减少SQL注入的风险,但它会产生不正确的行为,因为错误的名字记录下来。

剩余的问题

以下项目是最新的,因此最需要的反馈。

• 应对审查和评论
• “半专业比赛确定攻击者”威胁模型
• 为流行建议值,易于开发、等领域

日期:2008年12月8日

谢谢你参与这项工作。我们收到很多评论的初稿。

第二稿中提供了一个单独的消息。我们愿意接收反馈,或相关问题,12月17日。我们将有一个或teo更轮评审,与1月初目标发布日期。

这一轮,你可以考虑这些活动。

• 看看你是否同意更改
• 审查和评论的突出问题
• 评审推荐条目,但尚未补充道
• 评审推荐条目删除,但不删除
• 检查条目以最小的评论——候选人删除?
• 审查任何单个条目的文本

你是否花5分钟或两个小时,你的意见对我们很重要。我们收到了一个栏目中从一个参与者的反应,帮助提高我们的信心,我们正朝着正确的方向前进,所以每一点帮助。

反馈可以发送到任何:

排名前25位的球队(san /斜方)
史蒂夫Christey
Bob Martin

总结收到评论稿1

• 我们收到的评论一组不同的十几人。一些评论一般和具体的,所以有一些可靠的反馈。每一个被认为是阅读和发表评论,但由于评论的数量,我们无法单独应对每一个。
• 虽然CWE前25名试图关注潜在的弱点,反馈经常提出脆弱性的概念和一些人建议删除更多weakness-focused连续波。这是一个困难的行业,结合趋势分析,通常weakness-focused可用。
• 总的来说,似乎有协议,非正式语气是好的,因为它听起来不太爱唠叨的“开发人员,因此更有可能被接受。
• 一些人建议指定选择标准更确切地说,和遵循这些标准。对于这个草案,我们使用了一个非正式的严重性和流行。
• 一些个人或缓解字段条目失踪的讨论。讨论字段添加到这个草案;其他领域,特别是缓解,将在接下来的几周。我们最初主要是关注应该投保CWE的。
• 一些人要求更多的表现为web应用程序,但是其他参与者不处理web应用程序。惊人的平衡可能是困难的。
• 一些建议是基于CVE漏洞趋势数据,可以追溯到2006年。有一些变化,但2008年的数据是不完整的。我们来看看2008年的粗略的数据,看看有什么明显。
• 有些人建议CWE“类别”类型的条目。与“弱点”类型CWE条目,类别往往是松散的组合多个不相关的弱点。我们试图避免这些,因为我们想要更具体的关于相关的弱点。然而,一些地区CWE没有足够的深度和weakness-focused凝聚力,所以类别节点可能是最好的选择。

改变从第一稿、第二稿

这是一个总结的最显著的变化是由第一和第二之间草稿。

“公共知识”改为“攻击者意识”。意识水平假设攻击者技术水平介于学前脚本和民族国家:一个意图伤害,能够执行一些研究已知缺陷的类型,而不是追随前沿趋势。

“孩子连续波”改为“相关连续波”

添加条目,每个条目的讨论。应对(将在稍后完成草案)。

添加新条目:

• cwe - 79 (XSS)
• cwe - 89 (SQL注入)
• cwe - 352 (CSRF)
• cwe - 119(一般界外缓冲错误)

删除条目:

• cwe - 134(格式字符串)
• cwe cwe cwe - 120 - 129 - 131 -删除,取而代之的是更一般的cwe - 119

各种各样的编辑:

• 失踪的讨论分
• 添加缺失的数据字段
• 添加/更新相关的连续波对于某些条目

选择标准:

有一些直接和间接倡导选择CWE的基于一些普遍性和严重性的组合。间接宣传的一个例子来自马克·考克斯曾经NVD CWE-based分类查看关键/重要的Red Hat的问题。Chris Wysopal Veracode的提出了一个公式:

(严重*严重性)*患病率

严重性是在1到5的范围。

我们正在认真考虑使用这个指标,或其他一些指标根据严重程度和流行,来帮助我们优先排名前25位的元素。的条目添加到草案2优先根据严重程度和流行的一个非正式的组合。(严重程度所暗示的“后果”字段)。

突出问题为现有条目

以下排名前25位的条目有冲突的观点,或其他问题,需要进一步检查。

CWE-20(输入验证)——有些人认为这是非常重要的。其他人认为它太高级,也有太多的名单上的其他问题。在我自己的意见,即使重叠,我认为这应该是# 1消息得到开发人员。它不会解决所有问题,但它将消除许多唾手可得。这可以缓解措施中引用其他排名前25位的条目,进一步加强输入验证的重要性。

cwe - 184(不完整的黑名单)——一个建议是基于流行的包容(描述关注单纯依赖黑名单的坏处)。另一个建议是为了排除(意译)以来他们已经反映为了保护软件。这总有较小的患病率比疲软的试图防止。

cwe - 259(硬编码的密码)-包含没有争议,但有一个需要澄清。最近,CWE团队意识到CWE - 259可以解释人们在两个不同的方面,我们看到它在前25名中反馈,。这两种解释是:(1)应用程序的身份验证程序比较传入密码对硬编码的密码并相应地授予访问权限;(2)应用程序连接到另一个进程/组件,它包含硬编码的证书验证该组件。排名前25位的列表和CWE 1.1,最初的意图是项(1);但这应该扩展到包括含义吗?也有一个建议扩大到包括默认密码。

cwe - 749(不公开的方法)——有些人不认为它是重要的。2008 -时代CVE数据显示显著增加在过去的2年,所以患病率高。严重程度通常是高的,比如很多ActiveX暴露方法漏洞允许任意代码执行。

cwe - 362(竞争条件)——基于CVE低流行率数据;但是有些人认为这是一个大问题。可能反映了CVE偏向研究人员公布结果(省略了最安全敏感行业如金融顾问)。

cwe - 73(外部控制文件名或路径)是一些讨论的话题。有一些倡导更多的东西一般处理外部控制输入,如参数篡改(cwe - 472)——特别是web应用程序的人。CWE - 472是重要的许多CWE的XSS和SQL注入,但CWE - 73是目前唯一领带后路径遍历和符号链接(中度流行基于CVE的数据,所以没有在前25名中)。

cwe - 250(操作与不必要的特权)没有收到直接评论,但是有几个人想捕捉特权管理有关的问题。困难之一是,CWE的特权/权限区域是不够成熟,尽管我们可以部分解决这一新的CWE条目如果必要的。

建议少量修改

这些都是一些更引人注目的建议修改前25名的列表。

评论条目添加起草2

以下条目被添加到前25名名单草案2。这些添加优先使用非正式的普遍性和严重性的组合。

• cwe - 79 (XSS)或cwe - 80(基本XSS)

  行动:添加到前25名

  • 这是项中提到的输入验证(CWE-20),但是有些人主张促进个体槽前25名。基于流行,这应该是在名单上。
• cwe - 89 (SQL注入)

  行动:添加到前25名

  • 这是项中提到的输入验证(CWE-20),但是有些人主张推广。基于发病率和严重程度(CVE和独立的数据源),这应该是在列表的顶部附近。
• cwe - 352 (CSRF)

  行动:添加到前25名

  • 使用患病率(基于CVE统计2008)和一般的严重性,可能有充分的理由包括它

从排名前25位的评论条目

• cwe - 134格式字符串。

  行动:从排名前25位

  • 多个注释并不普遍。然而,程度高。

推荐的条目,而不是添加(吗?)

以下条目被推荐的前25位,但是他们没有说由于空间或优先级的问题。

如果你坚信,这些条目应该添加到前25,然后请给你这样做的理由,并提出当前条目应该被取代。

• cwe - 319(明文传输的敏感信息)

  行动:添加到前25名

  • 这只是提到的一个人而是整个OWASP十大类别,而不仅仅适用于web应用程序。流行是未知的,但可能很高。严重程度通常是中等到高。

• cwe - 190(整数溢出)

  行动:还没有添加到前25名

  • 这是很多人提倡的,是非常流行的操作系统供应商,基于CVE的数据。严重程度可能很高,但只有在上下文与其他相关的缓冲区溢位弱点(DoS是可能通过创建无限/大型循环)。以来已经有CWE缓冲区溢出,也许CWE - 190不应包括在内。

• cwe - 209(错误消息信息泄露)

  行动:还没有添加到前25名

  • 非常高的发病率,严重程度通常低但有时高。

• cwe - 117杀毒软件(输出)

  行动:还没有添加到前25名

  • 所倡导的一些;输入验证的好伴侣,但是如果SQL注入和XSS得到自己的名单上的插槽,过度吗?

• cwe - 476 (NULL指针)

  行动:还没有添加到前25名

  • 普遍而言,这可能是2008年前15名基于CVE的数据。严重程度通常是DoS (C程序)或小infoleak (Java程序)。

• cwe - 385(会话固定)

  行动:还没有添加到前25名

  • 提到的几个人。流行是不确定的,最小的CVE数据。攻击复杂度适中,但严重程度高。

建议删除的条目,而不是从排名前25位

这些条目被推荐用于去除一些聚会,但他们没有从排名前25位由于流行,严重程度,或不一致的反馈。

• cwe - 426不可信的搜索路径。

  行动:在前25名

  • 排除基于有限的患病率。然而,严重程度通常是高的。

• cwe - 665不正确/不完整的初始化。

  行动:在前25名

  • 一个论点是,这不是一个问题与现代语言。然而,这是普遍和经常严重PHP应用程序(虽然不那么重要register_globals使用量下降),用C和未初始化的变量问题有中等程度未知的患病率。

• cwe - 184不完整的黑名单。

  行动:在前25名

  • 似乎没有人认为太强烈,流行的数据不多。较小的患病率比弱点试图防止;至少程序员尝试,这显示了一些/勤奋的安全意识。

条目没有太多评论(赞成或反对)

以下条目没有收到评论,pro或场骗局这些是否可以考虑删除,为其他被认为更重要的是——或者他们是非常重要的吗?

• 规范化之前cwe - 180(验证)
• cwe - 470反射(不安全)
• cwe - 565(使用cookie的安全决定)
• cwe - 252(未检查返回值)
• cwe - 494(下载不可信移动代码没有完整性检查)

其他建议更改

一些更多的澄清与OWASP十大可能是有用的。

考虑“方便剥削”