本文参考自owasp，重点是提供清晰，简单，可操作的指导，以防止应用程序中的SQL注入漏洞。不幸的是，SQL注入攻击很常见，这是由于两个因素：

SQL注入漏洞的显着流行目标的吸引力（即数据库通常包含应用程序的所有有趣/关键数据）。

发生了如此多的成功SQL注入攻击有点可耻，因为在代码中避免SQL注入漏洞非常简单。

当软件开发人员创建包含用户提供的输入的动态数据库查询时，会引入SQL注入漏洞。为了避免SQL注入缺陷很简单。开发人员需要：

a）停止编写动态查询;

b）防止用户提供的包含恶意SQL的输入影响所执行查询的逻辑。

本文提供了一组通过避免这两个问题来防止SQL注入漏洞的简单技术。这些技术几乎可以与任何类型的数据库一起使用。还有其他类型的数据库，如XML数据库，可能有类似的问题（例如，XPath和XQuery注入），这些技术也可用于保护它们。

主要防御：

选项1：使用准备好的语句（带参数化查询）选项2：使用存储过程选项3：白名单输入验证选项4：转义所有用户提供的输入

额外防御：

另外：强制执行最低权限另外：执行白名单输入验证作为辅助防御

不安全的例子：

SQL注入漏洞通常如下所示：

以下（Java）示例是UNSAFE，并允许攻击者将代码注入将由数据库执行的查询中。简单地附加到查询的未经验证的“customerName”参数允许攻击者注入他们想要的任何SQL代码。不幸的是，这种访问数据库的方法太常见了。

String query = "SELECT account_balance FROM user_data WHERE user_name = "              + request.getParameter("customerName");try {    Statement statement = connection.createStatement( ... );    ResultSet results = statement.executeQuery( query );}...

使用带有变量绑定的预准备语句（也就是参数化查询）是所有开发人员应该首先学习如何编写数据库查询的方法。它们比动态查询更易于编写，更易于理解。参数化查询强制开发人员首先定义所有SQL代码，然后将每个参数传递给查询。这种编码风格允许数据库区分代码和数据，无论提供什么用户输入。

准备好的语句可确保攻击者无法更改查询的意图，即使攻击者插入了SQL命令也是如此。在下面的安全示例中，如果攻击者输入的是userID tom' or '1'='1，则参数化查询不会受到攻击，而是会查找与字符串完全匹配的用户名tom' or '1'='1。

特定语言的建议：

Java EE - PreparedStatement()与绑定变量一起使用.NET - 使用参数化查询，如绑定变量SqlCommand()或OleDbCommand()使用绑定变量PHP - 将PDO与强类型参数化查询一起使用（使用bindParam（））Hibernate - createQuery()与绑定变量一起使用（在Hibernate中称为命名参数）SQLite - 用于sqlite3_prepare()创建语句对象

在极少数情况下，准备好的陈述会损害绩效。遇到这种情况时，最好是a）强烈验证所有数据或b）使用特定于数据库供应商的转义例程来转义所有用户提供的输入，如下所述，而不是使用预准备语句。

安全JavaSQL语句示例

以下代码示例使用PreparedStatementJava的参数化查询实现来执行相同的数据库查询。

// 一定要验证String custname = request.getParameter("customerName"); String query = "SELECT account_balance FROM user_data WHERE user_name = ? ";PreparedStatement pstmt = connection.prepareStatement( query );pstmt.setString( 1, custname); ResultSet results = pstmt.executeQuery( );

安全C＃.NET SQL语句示例

使用.NET，它更加直接。查询的创建和执行不会更改。您所要做的就是使用Parameters.Add()此处所示的调用将参数传递给查询。

String query = "SELECT account_balance FROM user_data WHERE user_name = ?";try {  OleDbCommand command = new OleDbCommand(query, connection);  command.Parameters.Add(new OleDbParameter("customerName", CustomerName Name.Text));  OleDbDataReader reader = command.ExecuteReader();  // …} catch (OleDbException se) {  // error handling} 

我们已经在Java和.NET中展示了示例，但实际上所有其他语言（包括Cold Fusion和Classic ASP）都支持参数化查询接口。甚至SQL抽象层，如Hibernate查询语言（HQL）也有相同类型的注入问题（我们称之为HQL注入）。HQL也支持参数化查询，因此我们可以避免这个问题：

Hibernate查询语言（HQL）准备语句（命名参数）示例

//First is an unsafe HQL StatementQuery unsafeHQLQuery = session.createQuery("from Inventory where productID='"+userSuppliedParameter+"'");//Here is a safe version of the same query using named parametersQuery safeHQLQuery = session.createQuery("from Inventory where productID=:productid");safeHQLQuery.setParameter("productid", userSuppliedParameter);

开发人员倾向于喜欢Prepared Statement方法，因为所有SQL代码都保留在应用程序中。这使您的应用程序相对数据库独立。

防御选项2：存储过程#

SQL注入并不总是安全的存储过程。但是，某些标准存储过程编程结构与安全实现时使用参数化查询具有相同的效果，这是大多数存储过程语言的标准。

它们要求开发人员只使用自动参数化的参数构建SQL语句，除非开发人员在很大程度上超出了标准。预准备语句和存储过程之间的区别在于，存储过程的SQL代码已定义并存储在数据库本身中，然后从应用程序中调用。这两种技术在防止SQL注入方面具有相同的效果，因此您的组织应该选择哪种方法对您最有意义。

注意：'安全实现'意味着存储过程不包含任何不安全的动态SQL生成。开发人员通常不会在存储过程中生成动态SQL。但是，它可以做到，但应该避免。如果无法避免，则存储过程必须使用输入验证或本文所述的正确转义，以确保不能使用所有用户提供的存储过程输入将SQL代码注入动态生成的查询中。审计人员应始终在SQL Server存储过程中查找sp_execute，execute或exec的用法。类似的审计指南对于其他供应商的类似功能是必要的。

在某些情况下，存储过程可能会增加风险。例如，MS SQL服务器上，你有3个主要的默认角色：db_datareader，db_datawriter和db_owner。在存储过程开始使用之前，DBA会根据要求为webservice的用户提供db_datareader或db_datawriter权限。但是，存储过程需要执行权限，默认情况下该角色不可用。用户管理已集中在一些设置，但仅限于这3个角色，导致所有Web应用程序在db_owner权限下运行，因此存储过程可以正常工作。当然，这意味着如果服务器遭到破坏，攻击者拥有数据库的完全权限，以前他们可能只具有读访问权限。

安全Java存储过程示例

以下代码示例使用CallableStatementJava的存储过程接口实现来执行相同的数据库查询。该sp_getAccountBalance存储过程将在数据库中被预先定义和执行相同的功能与上述定义的查询。

// This should REALLY be validatedString custname = request.getParameter("customerName"); try {  CallableStatement cs = connection.prepareCall("{call sp_getAccountBalance(?)}");  cs.setString(1, custname);  ResultSet results = cs.executeQuery();        // … result set handling } catch (SQLException se) {             // … logging and error handling}

安全的VB .NET存储过程示例

以下代码示例使用SqlCommand.NET的存储过程接口实现来执行相同的数据库查询。该sp_getAccountBalance存储过程将在数据库中被预先定义和执行相同的功能与上述定义的查询。

Try   Dim command As SqlCommand = new SqlCommand("sp_getAccountBalance", connection)   command.CommandType = CommandType.StoredProcedure   command.Parameters.Add(new SqlParameter("@CustomerName", CustomerName.Text))   Dim reader As SqlDataReader = command.ExecuteReader()   '... Catch se As SqlException    'error handling End Try

SQL查询的各个部分不是使用绑定变量的合法位置，例如表或列的名称，以及排序顺序指示符（ASC或DESC）。在这种情况下，输入验证或查询重新设计是最合适的防御。对于表或列的名称，理想情况下，这些值来自代码，而不是来自用户参数。

但是，如果用户参数值用于使表名和列名不同，则应将参数值映射到合法/预期的表或列名，以确保未经验证的用户输入不会在查询中结束。请注意，这是设计不佳的症状，如果时间允许，应考虑完全重写。

以下是表名验证的示例。

String tableName;switch(PARAM):  case "Value1": tableName = "fooTable";                 break;  case "Value2": tableName = "barTable";                 break;  ...  default      : throw new InputValidationException("unexpected value provided"                                                   + " for table name");

该tableName然后可以直接附加到SQL查询，因为它是目前已知的是在此查询表名的法律和预期值之一。请记住，通用表验证功能可能会导致数据丢失，因为表名用于不期望它们的查询中。

对于像排序顺序这样简单的东西，最好将用户提供的输入转换为布尔值，然后使用该布尔值选择要附加到查询的安全值。这是动态查询创建中非常标准的需求。

例如：

public String someMethod(boolean sortOrder) { String SQLquery = "some SQL ... order by Salary " + (sortOrder ? "ASC" : "DESC");` ...

任何时候用户输入都可以转换为非String，如日期，数字，布尔值，枚举类型等，然后将其附加到查询中，或用于选择要追加到查询的值，这可以确保它是这样做是安全的。

在所有情况下，也建议将输入验证作为辅助防御，即使使用绑定变量，如本文后面所述。有关如何实施强白名单输入验证的更多技术在输入验证备忘单中进行了描述。

防御选项4：转义所有用户提供的输入#

当上述任何一种方法都不可行时，该技术仅应作为最后的手段使用。输入验证可能是一个更好的选择，因为与其他防御相比，这种方法很脆弱，我们不能保证它会在所有情况下阻止所有SQL注入。

此技术是在将用户输入放入查询之前将其转义。它的实现在数据库方面非常具体。通常只建议在实现输入验证时不会降低遗留代码的成本效益。应该使用参数化查询，存储过程或某种为您构建查询的对象关系映射器（ORM）来构建或重写从头开始构建的应用程序或需要低风险容忍度的应用程序。

这种技术就是这样的。每个DBMS都支持一种或多种特定于某些查询的字符转义方案。如果您使用正在使用的数据库的正确转义方案转义所有用户提供的输入，则DBMS不会将该输入与开发人员编写的SQL代码混淆，从而避免任何可能的SQL注入漏洞。

要专门为数据库编码器查找javadoc，请单击Codec左侧的类。有很多编解码器实现。两个特定于数据库的编解码器是OracleCodec，和MySQLCodec。

只需All Known Implementing Classes:在Interface Codec页面顶部单击其名称即可。

目前，ESAPI目前拥有以下数据库编码器：

MySQL（支持ANSI和本机模式）

数据库编码器即将推出：

SQL ServerPostgreSQL的

如果您的数据库编码器丢失，请告诉我们。

特定于数据库的转义详细信息#

如果您想构建自己的转义例程，以下是我们为ESAPI编码器开发的每个数据库的转义细节：

SQL ServerDB2转义动态查询

使用ESAPI数据库编解码器非常简单。Oracle示例如下所示：

ESAPI.encoder().encodeForSQL( new OracleCodec(), queryparam );

因此，如果您在代码中生成了一个现有的动态查询，该查询将转到Oracle，如下所示：

String query = "SELECT user_id FROM user_data WHERE user_name = '"               + req.getParameter("userID")              + "' and user_password = '" + req.getParameter("pwd") +"'";try {    Statement statement = connection.createStatement( … );    ResultSet results = statement.executeQuery( query );}

你会重写第一行看起来像这样：

Codec ORACLE_CODEC = new OracleCodec();String query = "SELECT user_id FROM user_data WHERE user_name = '" + ESAPI.encoder().encodeForSQL( ORACLE_CODEC, req.getParameter("userID")) + "' and user_password = '"+ ESAPI.encoder().encodeForSQL( ORACLE_CODEC, req.getParameter("pwd")) +"'";

无论输入是什么，它现在都可以安全地进行SQL注入。

为了获得最大的代码可读性，您还可以构建自己的代码OracleEncoder：

Encoder oe = new OracleEncoder();String query = "SELECT user_id FROM user_data WHERE user_name = '" + oe.encode( req.getParameter("userID")) + "' and user_password = '" + oe.encode( req.getParameter("pwd")) +"'";

使用这种类型的解决方案，您只需要将每个用户提供的参数包装成一个ESAPI.encoder().encodeForOracle( )调用或者您命名为调用的任何内容，您就可以完成。

在Like子句中转义通配符

该LIKE关键字允许进行文本扫描搜索。在Oracle中，下划线_字符仅匹配一个字符，而＆符号%用于匹配任何字符的零次或多次出现。必须在LIKE子句条件中转义这些字符。

例如：

SELECT name FROM emp WHERE id LIKE '%/_%' ESCAPE '/';SELECT name FROM emp WHERE id LIKE '%\%%' ESCAPE '\';

MySQL支持两种转义模式：

ANSI_QUOTES SQL模式，以及这个关闭的模式，我们称之为MySQL 模式。

ANSI SQL模式：'使用''（两个单一刻度）简单编码所有（单个刻度）字符

MySQL 模式，执行以下操作：

NUL (0x00) --> \0  [This is a zero, not the letter O]BS  (0x08) --> \bTAB (0x09) --> \tLF  (0x0a) --> \nCR  (0x0d) --> \rSUB (0x1a) --> \Z"   (0x22) --> \"%   (0x25) --> \%'   (0x27) --> \'\   (0x5c) --> \\_   (0x5f) --> \_ all other non-alphanumeric characters with ASCII values less than 256  --> \c where 'c' is the original non-alphanumeric character.

我们还没有实现SQL Server转义例程，但是下面有很好的指针和链接到描述如何防止SQL服务器上的SQL注入攻击的文章，请参见此处。

DB2转义#

此信息基于DB2 WebQuery特殊字符以及Oracle JDBC DB2驱动程序中的一些信息。

有关几个DB2 Universal驱动程序之间差异的信息。

十六进制编码所有输入#

转义的一个特殊情况是对从用户接收的整个字符串进行十六进制编码的过程（这可以看作是转义每个字符）。Web应用程序应在将用户输入包含在SQL语句中之前对其进行十六进制编码。SQL语句应该考虑到这一事实，并相应地比较数据。

例如，如果我们必须查找匹配sessionID的记录，并且用户将字符串abc123作为会话ID发送，则select语句将为：

SELECT ... FROM session WHERE hex_encode(sessionID) = '616263313233'

hex_encode应该由所使用的数据库的特定工具替换。字符串606162313233是从用户接收的字符串的十六进制编码版本（它是用户数据的ASCII / UTF-8代码的十六进制值的序列）。

如果攻击者要传输包含单引号字符的字符串，然后尝试注入SQL代码，则构造的SQL语句将只显示如下：

... WHERE hex_encode ( ... ) = '2720 ... '

27是单引号的ASCII代码（十六进制），它与字符串中的任何其他字符一样只是十六进制编码。产生的SQL只能包含数字数字和字母a来f，从来没有任何特殊字符，它可能会使SQL注入。

在PHP中转义SQLi#

使用预准备语句和参数化查询。这些是由数据库服务器与任何参数分开发送和解析的SQL语句。这样攻击者就无法注入恶意SQL。

你基本上有两个选择来实现这个目标：

使用PDO（适用于任何支持的数据库驱动程序）：

$stmt = $pdo->prepare('SELECT * FROM employees WHERE name = :name');$stmt->execute(array('name' => $name));foreach ($stmt as $row) {    // do something with $row}

$stmt = $dbConnection->prepare('SELECT * FROM employees WHERE name = ?');$stmt->bind_param('s', $name);$stmt->execute();$result = $stmt->get_result();while ($row = $result->fetch_assoc()) {    // do something with $row}

PDO是通用选项。如果您要连接到MySQL以外的数据库，则可以引用特定于驱动程序的第二个选项（例如，对于PostgreSQL，请使用pg_prepare（）和pg_execute（））。

额外的防御

除了采用四种主要防御之一外，我们还建议采用所有这些额外的防御措施，以便提供深度防御。这些额外的防御是：

最低权限白名单输入验证最低权限#

为了最大限度地减少成功SQL注入攻击的潜在损害，您应该最小化分配给环境中每个数据库帐户的权限。不要为您的应用程序帐户分配DBA或管理员类型访问权限。我们知道这很容易，当你这样做时，一切都“有效”，但这是非常危险的。

从头开始确定您的应用程序帐户需要哪些访问权限，而不是试图找出您需要带走的访问权限。确保仅需要读访问权限的帐户才被授予对他们需要访问的表的读访问权限。

如果帐户只需要访问表的某些部分，请考虑创建一个视图，以限制对该部分数据的访问，并为帐户分配帐户访问权限，而不是基础表。很少，如果有的话，授予对数据库帐户的创建或删除访问权限。

如果您采用的策略是在任何地方使用存储过程，并且不允许应用程序帐户直接执行自己的查询，那么将这些帐户限制为只能执行所需的存储过程。不要直接向数据库中的表授予任何权限。

SQL注入不是对数据库数据的唯一威胁。攻击者可以简单地将参数值从它们所呈现的合法值之一更改为未经授权的值，但应用程序本身可能被授权访问。因此，尽量减少授予应用程序的权限将降低此类未经授权的访问尝试的可能性，即使攻击者没有尝试将SQL注入用作其漏洞利用的一部分。

在您使用它时，您应该最小化DBMS运行的操作系统帐户的权限。不要以root用户身份或系统运行DBMS！大多数DBMS都是开箱即用的，具有非常强大的系统帐户。例如，默认情况下，MySQL在Windows上作为系统运行！使用受限制的权限将DBMS的OS帐户更改为更合适的帐户。

多个DB用户#

Web应用程序的设计者不仅应避免在Web应用程序中使用相同的所有者/管理员帐户来连接到数据库。不同的DB用户可以用于不同的Web应用程序。

通常，需要访问数据库的每个单独的Web应用程序都可以具有指定的数据库用户帐户，Web应用程序将使用该帐户连接到数据库。这样，应用程序的设计者可以在访问控制中具有良好的粒度，从而尽可能地减少特权。然后，每个数据库用户都可以选择访问它所需的内容，并根据需要进行写访问。

例如，登录页面需要对表的用户名和密码字段进行读访问，但不能对任何表单进行写访问（无插入，更新或删除）。但是，注册页面当然需要对该表的插入权限; 只有当这些Web应用程序使用不同的DB用户连接到数据库时，才能强制执行此限制。

查看#

通过限制对表的特定字段或表的连接的读访问，可以使用SQL视图进一步增加访问的粒度。它可能具有额外的好处：例如，假设系统需要（可能由于某些特定的法律要求）来存储用户的密码，而不是盐渍的密码。

设计师可以使用视图来弥补这种限制; 撤消对表的所有访问（来自除所有者/管理员之外的所有数据库用户）并创建一个输出密码字段的哈希而不是字段本身的视图。任何成功窃取数据库信息的SQL注入攻击都将被限制为窃取密码的哈希值（甚至可能是键控哈希值），因为任何Web应用程序的数据库用户都无权访问表本身。