常见的弱点枚举

产品构造SQL命令的所有或部分使用externally-influenced输入从一个上游组件,但这并不中和或错误地中和特殊元素时,可以修改SQL命令发送到下游组件。

没有足够的移除或引用用户可控输入的SQL语法生成的SQL查询可能会导致那些被视为输入SQL代替普通用户数据。这可以用来改变查询逻辑绕过安全检查,或者插入额外的语句修改后端数据库,其中可能包括执行系统命令。

SQL注入与数据库驱动的网站已经成为一个常见的问题。缺陷是容易检查出来的,很容易利用,这样,任何网站或产品包连最小的用户群可能是这种企图攻击。这一缺陷取决于这一事实SQL没有实际控制和数据平面之间的区别。

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

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

语言

技术

高

示例1

2008年,大量的web服务器使用相同的SQL注入攻击入侵了字符串。这一个字符串对许多不同的程序工作。SQL注入被用来修改网站恶意代码。

示例2

下面的代码动态地构造和执行一个SQL查询,搜索条目匹配指定的名字。查询限制的物品显示给那些老板匹配当前认证的用户的用户名。

这段代码的查询执行计划如下:

然而,因为查询构造动态连接一个常数基本查询字符串和用户输入字符串时,只查询正确的行为如果itemName不包含单引号字符。如果攻击者的用户名威利进入字符串:

itemName,然后查询变成如下:

添加:

条件导致WHERE子句总是评估为true,所以查询变成了逻辑上等价于更简单的查询:

这种简化查询允许攻击者绕过查询只返回项的要求身份验证的用户所拥有的;现在查询返回所有条目存储在项目表,不管他们的指定的所有者。

示例3

这个示例检查的影响不同的恶意值传递到查询构造和执行在前面的例子。

如果攻击者的用户名威利进入字符串:

itemName,然后查询就以下两个查询:

许多数据库服务器,包括Microsoft SQL Server 2000 (R),允许多个执行SQL语句用分号分隔。虽然这种攻击字符串结果在Oracle和其他数据库服务器上的一个错误,不允许批次执行的语句用分号分隔,在数据库,允许批量执行,这种类型的攻击使攻击者可以对数据库执行任意命令。

注意到拖着双连字符(——),它指定大多数数据库服务器,其余的语句是被视为一个评论,不执行。在这种情况下,评论人物用来删除修改查询剩下的单引号。数据库上的评论是不允许以这种方式使用,一般的攻击仍然可以做出有效的使用技巧类似于前面的示例所示。

如果攻击者进入字符串

然后将创建下列三个有效语句:

防止SQL注入攻击的一种传统方法是处理它们作为输入验证问题,要么只接受字符从一个allowlist安全值或识别和逃避denylist潜在的恶意的价值观。Allowlists可以非常有效的执行严格的输入确认规则,但参数化SQL语句只需要较少的维护,可以提供更多的保证安全。几乎总是如此,denylisting充斥着漏洞,使其无效防止SQL注入攻击。例如,攻击者可以:

• 目标字段不引用
• 想办法绕过某些逃元字符的必要性
• 使用存储过程隐藏注入的元字符。

手动转义字符输入SQL查询可以帮助,但它不会使您的应用程序安全从SQL注入攻击。

另一个常见解决方案提出了处理SQL注入攻击是使用存储过程。虽然存储过程防止某些类型的SQL注入攻击,他们不防止许多其他人。例如,下面的PL / SQL过程容易受到相同的SQL注入攻击第一个示例所示。

存储过程通常有助于防止SQL注入攻击通过限制类型的语句,可以传递给它们的参数。然而,有很多方法的局限性和许多有趣的语句仍然可以传递给存储过程。存储过程可以防止一些攻击,但他们不会使您的应用程序安全对SQL注入攻击。

示例4

已建成一个MS SQL函数,使shell命令执行。一个SQL注入在这样一个背景下可能是灾难性的。例如,表单的查询:

在美元user_input取自一个不可信的来源。

如果用户提供的字符串:

查询将采取以下形式:

现在,这个查询的方法可以分为:

1. 第一个SQL查询:选择项目,从产品价格ITEM_CATEGORY = ";
2. 第二个SQL查询,执行dir命令shell:执行主. .xp_cmdshell“dir”
3. 一个MS SQL注释:——的订单价格

可以看到,恶意输入查询的语义变化到一个查询中,shell命令执行和评论。

示例5

这段代码将打印一个消息摘要消息ID。

程序员可能会跳过任何输入验证id美元假设攻击者不能修改饼干。然而,这是很容易与自定义客户机代码,甚至在web浏览器中。

虽然$ id是包裹在单引号中调用mysql_query(),攻击者可以简单地改变中期传入的饼干:

这将产生结果查询:

这不仅可以检索消息编号为1432,它将检索所有其他消息。

在这种情况下,程序员可以将一个简单的修改应用到消除SQL注入的代码:

然而,如果这段代码的目的是支持多个用户提供不同的消息框,代码可能还需要一个访问控制检查(cwe - 285),以确保应用程序允许用户看到这一信息。

例子6

这个例子试图采取一个姓由用户提供输入到数据库中。

而程序员一个allowlist适用于用户输入,它的缺点。首先,用户仍可以提供连字符,用作评论结构的SQL。如果用户指定了”——“然后剩下的语句将被视为一个评论,这可能绕过安全逻辑。此外,allowlist允许撇号,也在SQL数据/命令分隔符。如果一个用户提供一个名称和一个撇号,他们也许能够改变整个语句的结构,甚至改变程序的控制流,可能访问机密信息或修改。在这种情况下,字符和撇号为姓,允许他们是合法的字符是必需的。相反,程序员可能想要使用一份事先准备好的声明中或日常编码应用于输入,以防止任何数据/指令误解。

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