这里的每个答案都只涵盖了问题的一部分。事实上，有四个不同的查询部分可以动态添加到SQL中：-

字符串一个数字标识符语法关键字

准备好的声明只涵盖其中两个。

但有时我们必须使查询更加动态，同时还要添加运算符或标识符。因此，我们需要不同的保护技术。

通常，这种保护方法基于白名单。

在这种情况下，每个动态参数都应该在脚本中硬编码，并从该集合中选择。例如，要执行动态排序：

$orders  = array("name", "price", "qty"); // Field names
$key = array_search($_GET['sort'], $orders)); // if we have such a name
$orderby = $orders[$key]; // If not, first one will be set automatically. 
$query = "SELECT * FROM `table` ORDER BY $orderby"; // Value is safe

为了简化这个过程，我编写了一个白名单助手函数，它在一行中完成所有工作：

$orderby = white_list($_GET['orderby'], "name", ["name","price","qty"], "Invalid field name");
$query  = "SELECT * FROM `table` ORDER BY `$orderby`"; // sound and safe

还有另一种保护标识符的方法——逃避，但我更倾向于将白名单作为一种更稳健、更明确的方法。然而，只要引用了标识符，就可以转义引号字符以使其安全。例如，默认情况下，mysql的引号字符必须加倍才能转义。其他DBMS的转义规则则不同。

尽管如此，SQL语法关键字（如AND、DESC等）仍然存在问题，但在这种情况下，白名单似乎是唯一的方法。

因此，一般性建议可表述为

任何表示SQL数据文本的变量（或者，简单地说，SQL字符串或数字）都必须通过准备好的语句添加。无例外。任何其他查询部分，如SQL关键字、表或字段名或运算符，都必须通过白名单进行筛选。

使现代化

尽管人们对SQL注入保护的最佳做法达成了一致，但仍有许多不好的做法。其中一些过于深入人心。例如，就在这个页面上，有80多个被删除的答案（尽管大多数访问者看不见），这些答案都是由于质量不好或推广不良和过时的做法而被社区删除的。更糟糕的是，一些糟糕的答案并没有被删除，反而变得繁荣起来。

例如，有（1）仍然有（3）许多（4）答案（5），包括排名第二的、建议手动字符串转义的答案，这是一种过时的方法，被证明是不安全的。

或者有一个稍微好一点的答案，它只是建议了另一种字符串格式化方法，甚至将其作为终极灵丹妙药。当然，事实并非如此。这种方法并不比常规字符串格式好，但它保留了所有缺点：它只适用于字符串，与任何其他手动格式一样，它本质上是可选的、非强制性的措施，容易出现任何类型的人为错误。

我认为这一切都是因为一个非常古老的迷信，得到了OWASP或PHP手册等权威机构的支持，它宣称任何“逃逸”和SQL注入保护之间的平等。

不管PHP手册说了多少年，*_escape_string决不会使数据安全，也从来没有想过这样做。除了对字符串以外的任何SQL部分都没有用处之外，手动转义是错误的，因为它是手动的，而不是自动的。

OWASP使情况更糟，强调逃避用户输入，这完全是无稽之谈：在注射保护的上下文中不应该有这样的词。每一个变量都有潜在的危险——无论来源如何！或者，换句话说，每一个变量都必须经过正确的格式化才能放入查询中，无论其来源是什么。重要的是目的地。当开发人员开始将绵羊和山羊分开时（考虑某个特定变量是否“安全”），他/她就迈出了灾难的第一步。更不用说，就连措辞都建议在入口点进行大容量转义，这类似于非常神奇的引号功能——已经被轻视、弃用和删除。

因此，与任何“转义”不同的是，准备好的语句确实是防止SQL注入的措施（如果适用）。

从安全角度来看，我倾向于存储过程（MySQL从5.0开始就支持存储过程），其优点是-

大多数数据库（包括MySQL）允许将用户访问限制为执行存储过程。细粒度安全访问控制有助于防止特权攻击升级。这防止了受损的应用程序能够直接针对数据库运行SQL。它们从应用程序中提取原始SQL查询，因此应用程序可以获得的数据库结构信息较少。这使得人们更难理解数据库的底层结构并设计合适的攻击。它们只接受参数，因此参数化查询的优势就在这里。当然，IMO仍然需要清理输入，尤其是在存储过程中使用动态SQL时。

缺点是-

它们（存储过程）很难维护，而且往往会很快繁殖。这使得管理它们成为一个问题。它们不太适合动态查询——若构建它们是为了接受动态代码作为参数，那个么许多优点就被否定了。

安全警告：此答案不符合安全最佳实践。转义不足以防止SQL注入，请改用准备好的语句。

SQL语句中转义特殊字符的一些准则。

不要使用MySQL。此扩展已弃用。请改用MySQLi或PDO。

MySQLi

对于手动转义字符串中的特殊字符，可以使用mysqli_real_escape_string函数。除非使用mysqli_set_charset设置了正确的字符集，否则该函数将无法正常工作。

例子：

$mysqli = new mysqli('host', 'user', 'password', 'database');
$mysqli->set_charset('charset');

$string = $mysqli->real_escape_string($string);
$mysqli->query("INSERT INTO table (column) VALUES ('$string')");

要使用准备好的语句自动转义值，请使用mysqli_prepare和mysqli_stmt_bind_param，其中必须提供相应绑定变量的类型以进行适当的转换：

例子：

$stmt = $mysqli->prepare("INSERT INTO table (column1, column2) VALUES (?,?)");

$stmt->bind_param("is", $integer, $string);

$stmt->execute();

无论您使用prepared语句还是mysqli_real_escape_string，您都必须知道正在使用的输入数据的类型。

因此，如果使用准备好的语句，则必须指定mysqli_stmt_bind_param函数的变量类型。

正如名字所说，mysqli_real_escape_string的使用是为了转义字符串中的特殊字符，因此它不会使整数安全。此函数的目的是防止破坏SQL语句中的字符串，以及它可能对数据库造成的损坏。如果使用得当，mysqli_realescape_string是一个有用的函数，尤其是与sprintf结合使用时。

例子：

$string = "x' OR name LIKE '%John%";
$integer = '5 OR id != 0';

$query = sprintf( "SELECT id, email, pass, name FROM members WHERE email ='%s' AND id = %d", $mysqli->real_escape_string($string), $integer);

echo $query;
// SELECT id, email, pass, name FROM members WHERE email ='x\' OR name LIKE \'%John%' AND id = 5

$integer = '99999999999999999999';
$query = sprintf("SELECT id, email, pass, name FROM members WHERE email ='%s' AND id = %d", $mysqli->real_escape_string($string), $integer);

echo $query;
// SELECT id, email, pass, name FROM members WHERE email ='x\' OR name LIKE \'%John%' AND id = 2147483647

无论你最终使用的是什么，确保你的输入没有被magic_quotes或其他善意的垃圾破坏，如果有必要的话，通过条带斜杠或其他方式来清理它。

PHP和MySQL有很多答案，但以下是针对PHP和Oracle的代码，用于防止SQL注入以及定期使用oci8驱动程序：

$conn = oci_connect($username, $password, $connection_string);
$stmt = oci_parse($conn, 'UPDATE table SET field = :xx WHERE ID = 123');
oci_bind_by_name($stmt, ':xx', $fieldval);
oci_execute($stmt);

一个简单的方法是使用像CodeIgniter或Laravel这样的PHP框架，它具有内置的过滤和活动记录等功能，因此您不必担心这些细微差别。