cwe - 637:不必要的复杂性在保护机制(不使用“经济机制”)
描述
比必要的产品使用更复杂的机制,这可能导致合成缺陷机制不正确理解时,建模、配置,实现,或使用。
扩展描述
安全机制应该尽可能简单。复杂的安全机制可能产生部分实现和兼容性问题,导致不匹配的假设和实现安全。这个原理的一个推论是,数据规范应该尽可能的简单,因为复杂的数据规范导致复杂的验证代码。复杂的任务和系统可能也需要有复杂的安检,守卫如此简单系统应优先。
替代条款
的关系
模式的介绍
不同模式的引入提供了信息如何以及何时可以纳入这一弱点。生命周期的阶段识别点的介绍可能发生,而相关的报告提供了一个典型的场景介绍在给定的阶段。
常见的后果
这个表指定不同的个人相关后果的弱点。标识应用程序范围的安全领域侵犯,而影响了负面的技术影响,如果敌人成功利用这个弱点。可能提供的信息如何可能的具体结果预计将看到列表中相对于其它后果。例如,可能会有高可能性,缺点将被利用来实现一定的影响,但较低的可能性,它将被利用来实现不同的影响。
示范例子
示例1
IPSEC规范很复杂,导致错误,部分实现,和供应商之间的不兼容问题。
示例2
HTTP请求走私(cwe - 444)攻击是可行的因为没有严格的要求,应该如何处理非法或不一致的HTTP标头。这可能导致不一致的实现一个代理或防火墙解释相同的数据流作为一组不同的请求流比终点。
观察到的例子
参考 |
描述 |
|
|
|
文件名扩展和一个内容类型头可以用来推断文件类型,但开发人员只检查内容类型,允许无限制的文件上传( cwe - 434)。 |
|
在Apache环境中,一个“filename.php。gif”可以被重定向到PHP解释器,而不是作为gif图像/直接发送给用户。不知道这一点,开发商只检查最后提交的文件名的扩展,使任意代码执行。 |
|
开发人员净化$ _REQUEST superglobal数组,但是PHP也填充$ _GET,允许攻击者绕过保护机制,开展使用$ _GET SQL注入攻击代码。 |
潜在的缓解措施
阶段:体系结构和设计
避免复杂的安全机制,简单的将满足需求。避免复杂的数据模型,和不必要的复杂的操作。采用体系结构提供担保,通过优雅和抽象简化理解,同样可以实现。模块化,隔离和不相信复杂的代码,和其他安全编程原则适用于这些模块(例如,最小特权)减少漏洞。 |
弱点Ordinalities
Ordinality |
描述 |
主 |
(其他弱点的弱点存在独立的) |
引用
|