How to Avoid SQL Injection Vulnerabilities

最新推荐文章于 2024-08-07 14:12:54 发布

kezhen

最新推荐文章于 2024-08-07 14:12:54 发布

阅读量1.1k

点赞数

分类专栏：渗透测试相关

渗透测试相关专栏收录该内容

37 篇文章 0 订阅

订阅专栏

https://www.owasp.org/index.php/Guide_to_SQL_Injection

There are two complementary and successful methods of mitigating SQL Injection attacks:

有两种互为补充的方法可以缓解SQL注入攻击：

Parameterized queries using bound, typed parameters
使用绑定、类型参数进行参数化查询
Careful use of parameterized stored procedures.
注意使用参数的储存过程

Parameterized queries are the easiest to adopt, and work in fairly similar ways among most web technologies in use today, including:

在现在大多数web技术中，参数化查询较容易使用，且运行过程相似：

Java
.NET
Perl
PHP

Parameterized Queries with Bound Parameters

Parameterized queries keep the query and data separate through the use of placeholders known as "bound" parameters. For example in Java, this looks like this:

参数化查询使用占位符（称之为绑定参数）使查询和数据分开。例如在Java中：

"select * from table where columna=? and columnb=?"

The developer must then set values for the two ? placeholders. Note that using this syntax without actually using the placeholders and setting values provides no protection against SQL injection.

开发这必须为两个问号占位符进行复制。注意：不使用占位符或者不设定值的语法不能提供SQL注入保护。

Parameterized Stored Procedures

The use of parameterized stored procedures is an effective mechanism to avoid most forms of SQL Injection. In combination with parameterized bound queries, it is very unlikely that SQL injection will occur within your application. However, the use of dynamic code execution features can allow SQL Injection as shown below:

参数化存储过程能够有效的应对多种SQL注入。结合参数化绑定查询，你的应用程序几乎可以避免出现SQL注入的问题。但是，使用动态代码执行的特点可以导致SQL注入问题，如下代码所示：

create proc VulnerableDynamicSQL(@userName nvarchar(25))as

 declare @sql nvarchar(255)
 set @sql = 'select * from users where UserName =  
   + @userName + '
 exec sp_executesql @sql

(MS SQL example from http://dotnetjunkies.com/WebLog/chris.taylor/archive/2004/10/13/28370.aspx)

The above example still allows SQL Injection as it allows dynamic injection of arbitrary string data. This is also true of Java / PL/SQL and MySQL's stored procedure support.

Least privilege connections

Always use accounts with the minimum privilege necessary for the application at hand, never “sa”, “dba”, “admin”, or the equivalent.

使用尽可能小的权限连接数据库，尽量不适用“sa”, “dba”, “admin”等

WARNING: Escaping table names

You must be very vigilant about mitigating SQL Injection when users supply table names, so in general it is best never to allow them to do so free-form. Allowing users to supply table names in free form seems to be a common issue with PHP forum software.

当用户提供数据表名字时，必须谨慎的处理SQL注入问题，所以一般情况下，尽可能避免允许用户随意提供数据表名。PHP论坛软件中普遍存在随意提供数据表名的问题。

$tablename = mysql_real_escape_string($tablename)

is simply not safe and cannot be made so.

In general:

Avoid using dynamic table names if at all possible.
尽可能的避免动态表名
If you have to use dynamic table names, do not accept them from the user if at all possible.
如果不得不使用动态表名，尽可能的不让用户提供
If you have to allow user-supplied table names, use your database management system's functionality for quoting identifiers. PostgreSQL, for example, supplies a quote_ident() function for this purpose. If your database management system does not have such functionality, you must assume that its other countermeasures against attacks from outside are insufficient to fend off anything, and should migrate off that database management system as soon as you can.
如果不得不让用户提供表名，对于引用标示符使用数据库管理系统函数。例如，PostgreSQL提供了quote_ident()函数。如果数据库管理系统没有这样的函数，并且数据库管理系统的其他防护措施缺乏的话，尽可能的迁移数据库管理系统。