 描述
产品接收输入,预计将是格式良好的。,遵守一定的语法,但它不验证或不正确验证输入符合语法。
扩展描述
通常,复杂的输入将遵循一个特定的语法,这是假设由输入本身,或宣布在元数据,比如标题。可以用于数据交换格式,语法标记语言,甚至编程语言。当不可信的输入不正确验证预期的语法,攻击者可能会导致解析失败,引发意想不到的错误,或暴露潜在的漏洞,可能不是直接利用如果输入符合语法。
的关系
 此表显示了弱点和高水平类别相关的这一弱点。这些关系被定义为ChildOf、ParentOf MemberOf,并洞察类似项目可能存在的在较高和较低的抽象级别。此外,关系如PeerOf和CanAlsoBe定义显示类似的弱点,用户可能想要探索。
模式的介绍
不同模式的引入提供了信息如何以及何时可以纳入这一弱点。生命周期的阶段识别点的介绍可能发生,而相关的报告提供了一个典型的场景介绍在给定的阶段。
常见的后果
这个表指定不同的个人相关后果的弱点。标识应用程序范围的安全领域侵犯,而影响了负面的技术影响,如果敌人成功利用这个弱点。可能提供的信息如何可能的具体结果预计将看到列表中相对于其它后果。例如,可能会有高可能性,缺点将被利用来实现一定的影响,但较低的可能性,它将被利用来实现不同的影响。
示范例子
示例1
下面的代码加载并解析一个XML文件。
/ /读DOM
尝试{
…
DocumentBuilderFactory工厂= DocumentBuilderFactory.newInstance ();
工厂。setValidating(假);
....
c_dom = factory.newDocumentBuilder ()。解析(xmlFile); }捕捉(例外的前女友){
… }
加载XML文件没有验证它与一个已知的XML模式或DTD。
观察到的例子
| 参考 |
描述 |
|
|
|
|
|
HTTP请求与失踪的协议版本号会导致崩溃 |
潜在的缓解措施
实施阶段:
假设所有的输入是恶意的。使用一个“接受良好的“输入验证策略,即。,使用一个可接受的输入列表,严格遵守规范。拒绝任何不严格符合规范的输入,或将其转换为一些。
当执行输入验证,考虑所有可能相关的属性,包括长度,类型的输入,可接受的值的全系列,缺失或额外的输入,语法,一致性相关领域,符合业务规则。作为业务规则逻辑的一个例子,在语法上“船”可能是有效的,因为它只包含字母数字字符,但它不是有效的如果输入预计仅包含颜色,如“红”或“蓝色”。
不完全依赖寻找恶意或畸形的输入。这很可能错过至少有一个不受欢迎的输入,特别是如果代码的环境变化。这可以让攻击者有足够的空间绕过验证。然而,denylists可以用于检测潜在攻击或确定哪些输入是畸形的,应该直接驳回。
|
笔记
维护
这个条目仍处于开发阶段,将继续看到更新和内容的改进。
|
