正如你所看到的，人们建议你最多使用准备好的陈述。这并没有错，但如果每个进程只执行一次查询，则会有轻微的性能损失。

我正面临这个问题，但我认为我以非常复杂的方式解决了它——黑客避免使用引号的方式。我将其与模拟的准备语句结合使用。我使用它来防止各种可能的SQL注入攻击。

我的方法：

如果您希望输入是整数，请确保它真的是整数。在像PHP这样的变量类型语言中，这一点非常重要。例如，您可以使用这个非常简单但功能强大的解决方案：sprintf（“SELECT 1,2,3 FROM table WHERE 4=%u”，$input）；如果你对整数十六进制有任何期望，如果你对它十六进制，你将完全逃避所有输入。在C/C++中有一个名为mysql_hex_string（）的函数，在PHP中可以使用bin2hex（）。不用担心转义字符串的大小是其原始长度的2倍，因为即使使用mysql_real_ascape_string，PHP也必须分配相同的容量（（2*input_length）+1），这是相同的。这种十六进制方法通常在传输二进制数据时使用，但我认为没有理由不对所有数据使用它来防止SQL注入攻击。请注意，您必须在数据前面加上0x，或者改用MySQL函数UNHEX。

例如，查询：

SELECT password FROM users WHERE name = 'root';

将变成：

SELECT password FROM users WHERE name = 0x726f6f74;

or

SELECT password FROM users WHERE name = UNHEX('726f6f74');

Hex是完美的逃脱。无法注射。

UNHEX函数与0x前缀之间的差异

评论中有一些讨论，所以我最后想说清楚。这两种方法非常相似，但在某些方面略有不同：

0x前缀只能用于char、varchar、text、block、binary等数据列。此外，如果要插入空字符串，则其使用有点复杂。您必须将其完全替换为“”，否则会出现错误。

UNHEX（）适用于任何列；你不必担心空字符串。

---

十六进制方法通常用作攻击

注意，这种十六进制方法通常被用作SQL注入攻击，其中整数就像字符串一样，并且只使用mysql_real_aescape_string进行转义。然后可以避免使用引号。

例如，如果你只是这样做：

"SELECT title FROM article WHERE id = " . mysql_real_escape_string($_GET["id"])

攻击很容易给你注射。考虑从脚本返回的以下注入代码：

SELECT ... WHERE id = -1 UNION ALL SELECT table_name FROM information_schema.tables;

现在只提取表结构：

SELECT ... WHERE id = -1 UNION ALL SELECT column_name FROM information_schema.column WHERE table_name = __0x61727469636c65__;

然后只需选择所需的数据。是不是很酷？

但如果可注入站点的编码器将其十六进制，则不可能进行注入，因为查询将如下所示：

SELECT ... WHERE id = UNHEX('2d312075...3635');

无论使用哪个数据库，避免SQL注入攻击的正确方法都是将数据与SQL分离，这样数据就不会被SQL解析器解释为命令。可以使用正确格式化的数据部分创建SQL语句，但如果您不完全了解详细信息，则应始终使用准备好的语句和参数化查询。这些是SQL语句，与任何参数分开发送到数据库服务器并由其解析。这样，攻击者就不可能注入恶意SQL。

你基本上有两种选择来实现这一点：

使用PDO（适用于任何受支持的数据库驱动程序）：$stmt=$pdo->prepare（'SELECT*FROM employees WHERE name=：name'）；$stmt->execute（['name'=>$name]）；foreach（$stm作为$row）{//用$row做点什么}使用MySQLi（用于MySQL）：

由于PHP 8.2+，我们可以使用execute_query（），它在一个方法中准备、绑定参数和执行SQL语句：

$result = $dbConnection->execute_query('SELECT * FROM employees WHERE name = ?', [$name]);

while ($row = $result->fetch_assoc()) {
    // Do something with $row
}

PHP8.1之前：

$stmt = $dbConnection->prepare('SELECT * FROM employees WHERE name = ?');
$stmt->bind_param('s', $name); // 's' specifies the variable type => 'string'
$stmt->execute();

$result = $stmt->get_result();
while ($row = $result->fetch_assoc()) {
    // Do something with $row
}

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

---

正确设置连接

PDO

注意，当使用PDO访问MySQL数据库时，默认情况下不会使用真正准备好的语句。要解决此问题，必须禁用对已准备语句的模拟。使用PDO创建连接的示例如下：

$dbConnection = new PDO('mysql:dbname=dbtest;host=127.0.0.1;charset=utf8mb4', 'user', 'password');

$dbConnection->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);
$dbConnection->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

在上面的示例中，错误模式并不是绝对必要的，但建议添加它。这样PDO将通过抛出PDOException通知您所有MySQL错误。

然而，第一行setAttribute（）是必需的，它告诉PDO禁用模拟的准备语句并使用真正的准备语句。这可以确保在将语句和值发送到MySQL服务器之前，PHP不会对其进行解析（使攻击者没有机会注入恶意SQL）。

尽管您可以在构造函数的选项中设置字符集，但需要注意的是，PHP的“旧”版本（5.3.6之前）会默默忽略DSN中的字符集参数。

Mysqli公司

对于mysqli，我们必须遵循相同的程序：

mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT); // error reporting
$dbConnection = new mysqli('127.0.0.1', 'username', 'password', 'test');
$dbConnection->set_charset('utf8mb4'); // charset

---

解释

传递给准备的SQL语句由数据库服务器解析和编译。通过指定参数（在上面的示例中为？或命名参数，如：name），您可以告诉数据库引擎要过滤的位置。然后，当您调用execute时，准备好的语句将与您指定的参数值组合在一起。

这里重要的一点是，参数值与编译语句组合，而不是SQL字符串。SQL注入的工作原理是，当脚本创建要发送到数据库的SQL时，诱使脚本包含恶意字符串。因此，通过将实际的SQL与参数分开发送，可以限制出现意外情况的风险。

在使用准备好的语句时发送的任何参数都将被视为字符串（当然，数据库引擎可能会进行一些优化，因此参数也可能以数字结尾）。在上面的示例中，如果$name变量包含“Sarah”；DELETE FROM employees（从员工中删除）结果只需搜索字符串“‘Arah’；DELETE FROM employees”，您不会得到空表。

使用准备好的语句的另一个好处是，如果您在同一会话中多次执行同一语句，那么它只会被解析和编译一次，从而提高了速度。

哦，既然您询问了如何为插入操作，这里有一个示例（使用PDO）：

$preparedStatement = $db->prepare('INSERT INTO table (column) VALUES (:column)');

$preparedStatement->execute([ 'column' => $unsafeValue ]);

---

准备好的语句可以用于动态查询吗？

虽然您仍然可以为查询参数使用准备好的语句，但动态查询本身的结构不能参数化，某些查询功能也不能参数化。

对于这些特定的场景，最好使用白名单过滤器来限制可能的值。

// Value whitelist
// $dir can only be 'DESC', otherwise it will be 'ASC'
if (empty($dir) || $dir !== 'DESC') {
   $dir = 'ASC';
}

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

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

缺点是-

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

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

这里的每个答案都只涵盖了问题的一部分。事实上，有四个不同的查询部分可以动态添加到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注入的措施（如果适用）。

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