用户工具

站点工具


cwe:cn:definition:89

差别

这里会显示出您选择的修订版和当前版本之间的差别。

到此差别页面的链接

cwe:cn:definition:89 [2013/06/08 11:49]
evan [示例 - 4]
cwe:cn:definition:89 [2014/09/04 15:00] (当前版本)
行 1: 行 1:
 ====== CWE-89:​SQL命令中使用的特殊元素转义处理不恰当(SQL注入) ====== ====== CWE-89:​SQL命令中使用的特殊元素转义处理不恰当(SQL注入) ======
 ^ID|89| ^ID|89|
-^类型|弱点|+^Type|Weakness|
 ^Abstraction|Base| ^Abstraction|Base|
-^状态|草稿|+^Status|Draft|
 ^MITRE|http://​cwe.mitre.org/​data/​definitions/​89.html| ^MITRE|http://​cwe.mitre.org/​data/​definitions/​89.html|
-^英文|http://​wiki.scap.org.cn/​cwe/​en/​definition/​89| +^English|http://​wiki.scap.org.cn/​cwe/​en/​definition/​89| 
-^中文|http://​wiki.scap.org.cn/​cwe/​cn/​definition/​89|+^Chinese|http://​wiki.scap.org.cn/​cwe/​cn/​definition/​89|
  
-===== 概要描述 ​=====+===== Description Summary ​===== 
 +The software constructs all or part of an SQL command using 
 +externally-influenced input from an upstream component, but it does not 
 +neutralize or incorrectly neutralizes special elements that could modify the 
 +intended SQL command when it is sent to a downstream 
 +component.
  
-软件使用来自一个上游组件的外部输入数据构造全部或部分的SQL命令,但它在将SQL命令发送到下游组件时,没有处理或没有正确地处理输入数据中可能会改变预期的SQL的特殊元素。 +===== Extended Description ​===== 
-===== 扩展描述 ​=====+Without sufficient removal or quoting of SQL syntax in user-controllable inputs, the generated SQL query can cause those inputs to be interpreted as SQL instead of ordinary user data. This can be used to alter query logic to bypass security checks, or to insert additional statements that modify the back-end database, possibly including execution of system commands. ​
  
-在没有充分地去除或引述用户可控的输入中的SQL语法的情况下,生成的SQL查询可能导致这些用户输入被解释为SQL语句而并非普通的用户数据。这能够被用于改变查询逻辑以绕过安全检查或者插入额外的语句修改后台数据库,甚至包括执行系统命令。+SQL injection has become a common issue with database-driven web sites. The flaw is easily detected, and easily exploited, and as such, any site or software package with even a minimal user base is likely to be subject to an attempted attack of this kind. This flaw depends on the fact that SQL makes no real distinction between the control and data planes. ​
  
-SQL注入已经成为数据驱动网站的一个普遍问题。这种缺陷容易被发现,容易被利用,正因如此,任何网站或软件包——哪怕只有很小的用户群体都有可能成为这种类型攻击的主体。这种缺陷依赖于一个事实,即SQL没有将控制层和数据层真正地区别开。 
-===== 引入方式 ===== 
  
-这种弱点通常出现在使用数据库保存用户输入的富数据(data-rich)应用程序中。 
-===== 利用要点 ===== 
  
-应用程序动态地生成包含用户输入的查询。+===== Modes of Introduction ===== 
 +This weakness typically appears in data-rich applications that save user 
 +inputs in a database.
  
  
-===== 利用可能性 ===== 
  
-非常高+===== Enabling Factors for Exploitation ===== 
 +The application dynamically generates queries that contain user input. ​
  
-===== 常见的影响 ​===== + 
-^范围 ​^技术影响 ​备注 ​+ 
-|机密性|读取应用程序数据|因为SQL数据库通常保存有敏感数据,机密性被破坏是SQL注入漏洞带来的常见问题。+===== Likelihood of Exploit ===== 
-|访问控制|绕过防御机制|如果检查用户名和口令的SQL命令设计失误,可能会导致在不知悉口令的情况下使用另外用户的身份登录到系统。+Very High 
-|访问控制|绕过防御机制|如果身份认证信息保存在SQL数据库中,那么成功利用SQL注入漏洞可能能够更改这些认证信息。+ 
-|完整性|篡改应用程序数据|同读取敏感信息一样,SQL注入攻击还能够篡改甚至删除这些信息。 ​+===== Common Consequences ​===== 
-===== 检测方法 ​===== +^Scope ^Technical Impace ​Note 
-==== 检测方法 ​- 1 ====+|Confidentiality|Read application data|Since SQL databases generally hold sensitive dataloss of confidentiality is a frequent problem with SQL injection vulnerabilities. ​
 +|Access_Control|Bypass protection mechanism|If poor SQL commands are used to check user names and passwords, it may be possible to connect to a system as another user with no previous knowledge of the password. ​
 +|Access_Control|Bypass protection mechanism|If authorization information is held in a SQL database, it may be possible to change this information through the successful exploitation of a SQL injection vulnerability. ​
 +|Integrity|Modify application data|Just as it may be possible to read sensitive information,​ it is also possible to make changes or even delete this information with a SQL injection attack. ​
 +===== Detection Methods ​===== 
 +==== Detection Method ​- 1 ====
 {{page>​cwe:​cn:​detection:​1&​noheader}} {{page>​cwe:​cn:​detection:​1&​noheader}}
  
-==== 检测方法 ​- 2 ====+==== Detection Method ​- 2 ====
 {{page>​cwe:​cn:​detection:​2&​noheader}} {{page>​cwe:​cn:​detection:​2&​noheader}}
  
-==== 检测方法 ​- 3 ====+==== Detection Method ​- 3 ====
 {{page>​cwe:​cn:​detection:​9&​noheader}} {{page>​cwe:​cn:​detection:​9&​noheader}}
  
-===== 缓解方案 ​===== +==== Detection Method - 4 ==== 
-==== 缓解方案 ​- 1 ====+=== Automated Static Analysis - Binary / Bytecode === 
 +According to SOAR, the following detection techniques may be 
 +useful:==== Detection Method - 5 ==== 
 +=== Dynamic Analysis with automated results 
 +interpretation === 
 +According to SOAR, the following detection techniques may be 
 +useful:==== Detection Method - 6 ==== 
 +=== Dynamic Analysis with manual results interpretation === 
 +According to SOAR, the following detection techniques may be 
 +useful:==== Detection Method - 7 ==== 
 +=== Manual Static Analysis - Source Code === 
 +According to SOAR, the following detection techniques may be 
 +useful:==== Detection Method - 8 ==== 
 +=== Automated Static Analysis - Source Code === 
 +According to SOAR, the following detection techniques may be 
 +useful:==== Detection Method - 9 ==== 
 +=== Architecture / Design Review === 
 +According to SOAR, the following detection techniques may be 
 +useful:​===== Potential Mitigations ​===== 
 +==== Mitigation ​- 1 ====
 {{page>​cwe:​cn:​mitigation:​4&​noheader}} {{page>​cwe:​cn:​mitigation:​4&​noheader}}
  
-==== 缓解方案 ​- 2 ====+==== Mitigation ​- 2 ====
 {{page>​cwe:​cn:​mitigation:​27&​noheader}} {{page>​cwe:​cn:​mitigation:​27&​noheader}}
  
-==== 缓解方案 ​- 3 ====+==== Mitigation ​- 3 ====
 {{page>​cwe:​cn:​mitigation:​17&​noheader}} {{page>​cwe:​cn:​mitigation:​17&​noheader}}
  
-==== 缓解方案 ​- 4 ====+==== Mitigation ​- 4 ====
 {{page>​cwe:​cn:​mitigation:​15&​noheader}} {{page>​cwe:​cn:​mitigation:​15&​noheader}}
  
-==== 缓解方案 ​- 5 ====+==== Mitigation ​- 5 ====
 {{page>​cwe:​cn:​mitigation:​28&​noheader}} {{page>​cwe:​cn:​mitigation:​28&​noheader}}
  
-==== 缓解方案 ​- 6 ====+==== Mitigation ​- 6 ====
 {{page>​cwe:​cn:​mitigation:​5&​noheader}} {{page>​cwe:​cn:​mitigation:​5&​noheader}}
  
-==== 缓解方案 ​- 7 ====+==== Mitigation ​- 7 ====
 {{page>​cwe:​cn:​mitigation:​21&​noheader}} {{page>​cwe:​cn:​mitigation:​21&​noheader}}
  
-==== 缓解方案 ​- 8 ====+==== Mitigation ​- 8 ====
 {{page>​cwe:​cn:​mitigation:​39&​noheader}} {{page>​cwe:​cn:​mitigation:​39&​noheader}}
  
-==== 缓解方案 ​- 9 ====+==== Mitigation ​- 9 ====
 {{page>​cwe:​cn:​mitigation:​29&​noheader}} {{page>​cwe:​cn:​mitigation:​29&​noheader}}
  
-==== 缓解方案 ​- 10 ====+==== Mitigation ​- 10 ====
 {{page>​cwe:​cn:​mitigation:​16&​noheader}} {{page>​cwe:​cn:​mitigation:​16&​noheader}}
  
-===== 示例 ​===== +===== Demonstrative Examples ​===== 
-==== 示例 ​- 1 ====+==== Example ​- 1 ==== 
 +In 2008, a large number of web servers were compromised using the 
 +same SQL injection attack string. This single string worked against many 
 +different programs. The SQL injection was then used to modify the web sites 
 +to serve malicious code. [1]
  
-在2008年,大量的Web服务器被同一条SQL注入攻击字符串攻陷。这一条字符串能够应用于大量不同的程序。后来这些SQL注入攻击被用于将web网站篡改为恶意代码的载体。[1] + 
-==== 示例 ​- 2 ==== + 
-下面的代码动态地创建并执行一个用来搜索符合某个特定名称条目的SQL查询。查询限定为仅显示当前已登录用户所属的条目。+==== Example ​- 2 ==== 
 +The following code dynamically constructs and executes a SQL query 
 +that searches for items matching a specified name. The query restricts the 
 +items displayed to those where owner matches the user name of the 
 +currently-authenticated user.
  
 <code csharp > <code csharp >
行 92: 行 127:
 </​code>​ </​code>​
  
-这条查询期望执行下面的SQL语句:+The query that this code intends to execute follows: ​
  
-<​code ​sql>+<​code>​
 SELECT * FROM items WHERE owner = <​userName>​ AND itemname = <​itemName>; ​ SELECT * FROM items WHERE owner = <​userName>​ AND itemname = <​itemName>; ​
 </​code>​ </​code>​
  
-但是,由于查询是由一段固化的查询语句和用户的输入组合而成的,所以查询仅在itemName不包含单引号的情况下是正确的。如果一名用户名称为wiley的攻击者输入下面的字符串:+However, because the query is constructed dynamically by concatenating a constant base query string and a user input string, the query only behaves correctly if itemName ​does not contain a single-quote character. If an attacker with the user name wiley enters the string: ​
  
-<​code ​sql>+<​code>​
 name' OR '​a'​='​a ​ name' OR '​a'​='​a ​
 </​code>​ </​code>​
  
-作为itemName,那么查询变成了下面这样:+for itemName, then the query becomes the following: ​
  
-<​code ​sql>+<​code>​
 SELECT * FROM items WHERE owner = '​wiley'​ AND itemname = '​name'​ OR '​a'​='​a'; ​ SELECT * FROM items WHERE owner = '​wiley'​ AND itemname = '​name'​ OR '​a'​='​a'; ​
 </​code>​ </​code>​
  
-添加了下面代码后+The addition of the
  
-<​code ​sql>+<​code>​
 OR '​a'​='​a' ​ OR '​a'​='​a' ​
 </​code>​ </​code>​
  
-用户输入的条件导致WHERE语句的计算结果永远为true,这样这条查询逻辑上等于下面这条简单的多的查询:+condition causes the WHERE clause to always evaluate to true, so the query becomes logically equivalent to the much simpler query: ​
  
-<​code ​sql>+<​code>​
 SELECT * FROM items; ​ SELECT * FROM items; ​
 </​code>​ </​code>​
  
-这种简单的技巧允许攻击者绕过原始查询仅返回认证用户所拥有条目的限制;修改后的查询会返回存储在数据表中的全部条目,不论这些条目的拥有者是哪个用户。+This simplification of the query allows the attacker to bypass the requirement that the query only return items owned by the authenticated user; the query now returns all entries stored in the items table, regardless of their specified owner. ​
  
-==== 示例 - 3 ==== 
-本示例在示例2的基础上,分析了另一种不同的恶意值被传递到查询中并执行会出现的后果。 
  
-如果一个用户名称为wiley的攻击者输入如下字符串: 
  
-<​code ​sql>+==== Example - 3 ==== 
 +This example examines the effects of a different malicious value 
 +passed to the query constructed and executed in the previous 
 +example. 
 + 
 +If an attacker with the user name wiley enters the string:  
 + 
 +<​code>​
 name'; DELETE FROM items; --  name'; DELETE FROM items; -- 
 </​code>​ </​code>​
  
-作为itemName的值,那么这条查询变成了下面两条查询语句:+for itemName, then the query becomes the following two queries: ​
  
 <code sql > <code sql >
行 141: 行 180:
 </​code>​ </​code>​
  
-很多数据库服务器,包括Microsoft(R) SQL Server 2000,允许一次执行多个使用分号分隔开的SQL语句。然而这条攻击字符串在Oracle或其它不允许批量执行分号分隔的SQL语句的数据库服务器中会产生一条错误。在允许批量执行的数据库系统中,这种攻击允许攻击者在数据库系统中执行任意的指令。+Many database servers, including ​Microsoft(R) SQL Server 2000, allow multiple ​SQL statements separated by semicolons to be executed at once. While this attack string results in an error on Oracle ​and other database servers that do not allow the batch-execution of statements separated by semicolons, on databases that do allow batch execution, this type of attack allows the attacker to execute arbitrary commands against the database. ​
  
-注意尾部的两个连字符(--),在大部分数据库服务器中,这两个符号表示其后的语句为注释部分而不应被执行。在此例中,注释符号把被修改的查询语句后面剩下的一个单引号给注释掉了。在数据库不允许使用这样的注释符号的情况下,上个示例中的技巧依然管用。+Notice the trailing pair of hyphens (--), which specifies to most database servers that the remainder of the statement is to be treated as a comment and not executed. In this case the comment character serves to remove the trailing single-quote left over from the modified query. On a database where comments are not allowed to be used in this way, the general attack could still be made effective using a trick similar to the one shown in the previous example. ​
  
-如果一个攻击者输入下面的字符串:+If an attacker enters the string ​
  
-<​code ​sql>+<​code>​
 name'; DELETE FROM items; SELECT * FROM items WHERE '​a'​='​a ​ name'; DELETE FROM items; SELECT * FROM items WHERE '​a'​='​a ​
 </​code>​ </​code>​
  
-那么实际上生成了如下3个语句:+Then the following three valid statements will be created: ​
  
-<​code ​sql>+<​code>​
 SELECT * FROM items WHERE owner = '​wiley'​ AND itemname = '​name'; ​ SELECT * FROM items WHERE owner = '​wiley'​ AND itemname = '​name'; ​
 DELETE FROM items; ​ DELETE FROM items; ​
行 159: 行 198:
 </​code>​ </​code>​
  
-一种防御SQL注入攻击的惯用解决方案是把它们看待为输入验证问题:可以创建白名单仅接受安全的取值,或者创建黑名单过滤具有潜在危险的取值。从执行严格的输入验证规则方面来看,白名单机制是非常有效的,但是参数化SQL语句需要更少的维护,而且能够提供更多的安全保障。而黑名单机制却总是存在千疮百孔的漏洞,它很难有效地应对SQL注入攻击。举例来说,攻击者可以做如下事情绕过黑名单的防御:+One traditional approach to preventing ​SQL injection attacks is to handle them as an input validation problem and either accept only characters from a whitelist of safe values or identify and escape a blacklist of potentially malicious values. Whitelisting can be a very effective means of enforcing strict input validation rules, but parameterized ​SQL statements require less maintenance and can offer more guarantees with respect to security. As is almost always the case, blacklisting is riddled with loopholes that make it ineffective at preventing ​SQL injection attacks. For example, attackers can: 
  
-  *定位没有进行安全处理的字段。 +  *Target fields that are not quoted ​ 
-  *找到被转义(escape)的特定元字符(meta-characters)的替代方法。 +  *Find ways to bypass the need for certain escaped ​meta-characters  
-  *使用存储过程隐藏注入原字符。+  *Use stored procedures to hide the injected meta-characters.  
 +Manually escaping characters in input to SQL queries can help, but it will not make your application secure from SQL injection attacks. ​
  
-人工地转义输入到SQL查询中的字符能够起到一定作用,但它不能保证让你的应用不受到SQL注入的攻击。+Another solution commonly proposed for dealing with SQL injection attacks is to use stored procedures. Although stored procedures prevent some types of SQL injection attacks, they do not protect against many others. For example, the following PL/SQL procedure is vulnerable to the same SQL injection attack shown in the first example. ​
  
-处理SQL注入攻击问题的另一个普遍建议的解决方案是使用存储过程。虽然存储过程能够阻止某些类型的SQL注入攻击,但是它们对于很多其它类型的攻击无能为力。举例来说,下面的PL/​SQL存储过程并不能抵御第一个例子中介绍的SQL注入攻击手段。 +<​code>​
- +
- +
-<​code ​sql>+
 procedure get_item ( itm_cv IN OUT ItmCurTyp, usr in varchar2, itm in varchar2) ​ procedure get_item ( itm_cv IN OUT ItmCurTyp, usr in varchar2, itm in varchar2) ​
 is open itm_cv for  is open itm_cv for 
行 177: 行 214:
 </​code>​ </​code>​
  
-一般来说存储过程对SQL注入攻击的抵御作用在于它们能够限制输入到参数中的数据类型。然而这种限制对很多攻击手段来说并不有效,而且有很多巧妙的攻击语句仍然能够被传递到存储过各中去。再一次强调,存储过程能够阻止某些类型的SQL注入攻击,但是它们对于很多其它类型的攻击无能为力。 +Stored procedures typically help prevent ​SQL injection attacks by limiting the types of statements that can be passed to their parameters. However, there are many ways around the limitations and many interesting statements that can still be passed to stored procedures. Again, stored procedures can prevent some exploits, but they will not make your application secure against ​SQL injection attacks. ​
-==== 示例 - 4 ==== +
-MS SQL(Microsoft SQL Server)有一个内建的功能允许在数据库服务器中执行系统命令。在这种环境中发生的SQL注入可能是灾难性的,下面这种形式的查询:+
  
-<​code ​sql>+ 
 + 
 +==== Example - 4 ==== 
 +MS SQL has a built in function that enables shell command execution. 
 +An SQL injection in such a context could be disastrous. For example, a query 
 +of the form: 
 + 
 +<​code>​
 SELECT ITEM,PRICE FROM PRODUCT WHERE ITEM_CATEGORY='​$user_input'​ ORDER BY PRICE  SELECT ITEM,PRICE FROM PRODUCT WHERE ITEM_CATEGORY='​$user_input'​ ORDER BY PRICE 
 </​code>​ </​code>​
  
-它的$user_input参数来自一个未信任的源。+Where $user_input ​is taken from an untrusted source. ​
  
-如果用户提供了如下的字符串+If the user provides the string
  
-<​code ​sql>+<​code>​
 '; exec master..xp_cmdshell '​dir'​ --  '; exec master..xp_cmdshell '​dir'​ -- 
 </​code>​ </​code>​
  
-那么查询会变成如下情况+The query will take the following form
  
-<​code ​sql>+<​code>​
 SELECT ITEM,PRICE FROM PRODUCT WHERE ITEM_CATEGORY='';​ exec master..xp_cmdshell '​dir'​ --' ORDER BY PRICE  SELECT ITEM,PRICE FROM PRODUCT WHERE ITEM_CATEGORY='';​ exec master..xp_cmdshell '​dir'​ --' ORDER BY PRICE 
 </​code>​ </​code>​
  
-现在,查询可被分割为如下几块内容+Now, this query can be broken down into
  
-  -第一条SQL查询语句: SELECT ITEM,PRICE FROM PRODUCT WHERE ITEM_CATEGORY='';​  +  -a first SQL query: SELECT ITEM,PRICE FROM PRODUCT WHERE ITEM_CATEGORY='';​  
-  -第二条SQL查询语句,它会在shell中执行dir命令: exec master..xp_cmdshell '​dir'​  +  -a second ​SQL query, which executes the dir command in the shell: exec master..xp_cmdshell '​dir'​  
-  -一条MS SQL的注释:--' ORDER BY PRICE +  -an MS SQL comment: ​--' ORDER BY PRICE  
 +As can be seen, the malicious input changes the semantics of the query into a query, a shell command execution and a comment. ​
  
-如你所见,恶意的输入将查询的语义改变为执行一条查询,运行一个shell命令和一个注释。 
  
-==== 示例 ​- 5 ====+ 
 +==== Example ​- 5 ====
 This code intends to print a message summary given the message This code intends to print a message summary given the message
 ID. ID.
行 243: 行 286:
  
  
-==== 示例 ​- 6 ====+==== Example ​- 6 ====
 This example attempts to take a last name provided by a user and This example attempts to take a last name provided by a user and
 enter it into a database. enter it into a database.
行 259: 行 302:
  
  
-===== 验证实例 ​=====+===== Observed Examples ​=====
 ^Reference ^Description ^ ^Reference ^Description ^
 |[[http://​cve.scap.org.cn/​CVE-2004-0366.html|CVE-2004-0366]]|chain:​ SQL injection in library intended for database authentication allows SQL injection and authentication bypass. | |[[http://​cve.scap.org.cn/​CVE-2004-0366.html|CVE-2004-0366]]|chain:​ SQL injection in library intended for database authentication allows SQL injection and authentication bypass. |
行 268: 行 311:
 |[[http://​cve.scap.org.cn/​CVE-2003-0377.html|CVE-2003-0377]]|SQL injection in security product, using a crafted group name. | |[[http://​cve.scap.org.cn/​CVE-2003-0377.html|CVE-2003-0377]]|SQL injection in security product, using a crafted group name. |
 |[[http://​cve.scap.org.cn/​CVE-2008-2380.html|CVE-2008-2380]]|SQL injection in authentication library. | |[[http://​cve.scap.org.cn/​CVE-2008-2380.html|CVE-2008-2380]]|SQL injection in authentication library. |
 +
cwe/cn/definition/89.1370663384.txt.gz · 最后更改: 2013/06/08 11:49 由 evan