我认为，在PHP应用程序（或任何web应用程序）中防止SQL注入的最佳方法是考虑应用程序的架构。如果防止SQL注入的唯一方法是记住使用一个特殊的方法或函数，它在每次与数据库对话时都会做正确的事情，那么这是错误的。这样，在代码的某个时刻忘记正确格式化查询只是时间问题。

采用MVC模式和CakePHP或CodeIgniter这样的框架可能是正确的方法：创建安全数据库查询等常见任务已在这些框架中得到解决并集中实现。它们可以帮助您以合理的方式组织web应用程序，并让您更多地考虑加载和保存对象，而不是安全地构造单个SQL查询。

安全警告：此答案不符合安全最佳实践。转义不足以防止SQL注入，请改用准备好的语句。使用以下概述的策略，风险自负。（此外，在PHP7中删除了mysql_real_ascape_string（）。）不推荐使用警告：mysql扩展目前不推荐使用。我们建议使用PDO扩展

我使用三种不同的方法来防止我的web应用程序容易受到SQL注入的攻击。

使用mysql_real_aescape_string（），这是PHP中的一个预定义函数，此代码为以下字符添加反斜杠：\x00、\n、\r、\、'、“和\x1a。将输入值作为参数传递，以最大限度地减少SQL注入的机会。最先进的方法是使用PDO。

我希望这对你有帮助。

考虑以下查询：

$iId=mysql_real_ascape_string（“1或1=1”）；$sSql=“SELECT*FROM table WHERE id=$iId”；

mysql_real_aescape_string（）在这里不起保护作用。如果在查询中的变量周围使用单引号（“”），则可以防止这种情况发生。下面是一个解决方案：

$iId=（int）mysql_real_aescape_string（“1或1=1”）；$sSql=“SELECT*FROM table WHERE id=$iId”；

这个问题有一些很好的答案。

我建议，使用PDO是最好的选择。

编辑：

自PHP 5.5.0起，mysql_real_aescape_string（）已被弃用。使用mysqli或PDO。

mysql_real_aescape_string（）的替代方法是

string mysqli_real_escape_string ( mysqli $link , string $escapestr )

例子：

$iId = $mysqli->real_escape_string("1 OR 1=1");
$mysqli->query("SELECT * FROM table WHERE id = $iId");

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

我正面临这个问题，但我认为我以非常复杂的方式解决了它——黑客避免使用引号的方式。我将其与模拟的准备语句结合使用。我使用它来防止各种可能的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');

不推荐的警告：这个答案的示例代码（与问题的示例代码一样）使用了PHP的MySQL扩展，该扩展在PHP 5.5.0中被弃用，在PHP 7.0.0中被完全删除。安全警告：此答案不符合安全最佳实践。转义不足以防止SQL注入，请改用准备好的语句。使用以下概述的策略，风险自负。（此外，在PHP7中删除了mysql_real_ascape_string（）。）

使用PDO和MYSQLi是防止SQL注入的好方法，但如果您真的想使用MySQL函数和查询，最好使用

mysql_real_reape_string

$unsafe_variable = mysql_real_escape_string($_POST['user_input']);

还有更多的功能可以防止这种情况：比如识别-如果输入是字符串、数字、字符或数组，那么有很多内置函数可以检测这种情况。此外，最好使用这些函数来检查输入数据。

is_string（is_string）

$unsafe_variable = (is_string($_POST['user_input']) ? $_POST['user_input'] : '');

是数字（_N）

$unsafe_variable = (is_numeric($_POST['user_input']) ? $_POST['user_input'] : '');

使用这些函数来检查mysql_real_aescape_string中的输入数据要好得多。

关于许多有用的答案，我希望为这一主题增添一些价值。

SQL注入是一种可以通过用户输入（由用户填充然后在查询中使用的输入）进行的攻击。SQL注入模式是正确的查询语法，而我们可以称之为：错误的查询是由于错误的原因，我们假设可能有坏人试图获取影响安全性（机密性、完整性和可用性）三个原则的秘密信息（绕过访问控制）。

现在，我们的重点是防止安全威胁，如SQL注入攻击，问题是（如何使用PHP防止SQL注入攻击），更现实的是，数据过滤或清除输入数据是在这样的查询中使用用户输入数据时的情况，而不是使用PHP或任何其他编程语言，或者更多人建议使用现代技术，如prepared语句或当前支持SQL注入预防的任何其他工具，是否认为这些工具不再可用？如何保护您的应用程序？

我反对SQL注入的方法是：在将用户输入数据发送到数据库之前（在任何查询中使用之前）清除用户输入数据。

的数据筛选（将不安全数据转换为安全数据）

考虑PDO和MySQLi不可用。如何保护应用程序？你强迫我使用它们吗？PHP以外的其他语言呢？我更愿意提供一般性的想法，因为它可以用于更广泛的边界，而不仅仅是用于特定的语言。

SQL用户（限制用户权限）：最常见的SQL操作是（SELECT、UPDATE、INSERT），那么，为什么要将UPDATE权限授予不需要它的用户呢？例如，登录和搜索页面只使用SELECT，那么，为什么在这些页面中使用具有高权限的DB用户？

规则：不要为所有权限创建一个数据库用户。对于所有SQL操作，您可以创建类似（deluser、selectuser、updateuser）的方案作为用户名，以方便使用。

参见最低特权原则。

数据过滤：在构建任何查询用户输入之前，应该对其进行验证和过滤。对于程序员来说，为每个用户输入变量定义一些财产很重要：数据类型、数据模式和数据长度。一个介于（x和y）之间的数字字段必须使用精确的规则进行精确验证，对于一个字符串（文本）的字段：模式就是这种情况，例如，用户名只能包含一些字符，比如[A-zA-Z0-9_-.]。长度在（x和n）之间变化，其中x和n（整数，x<=n）。规则：创建精确的过滤器和验证规则是我的最佳实践。使用其他工具：在这里，我也同意您的观点，即准备好的语句（参数化查询）和存储过程。这里的缺点是这些方法需要高级技能，而大多数用户并不具备这些技能。这里的基本思想是区分SQL查询和内部使用的数据。这两种方法甚至可以用于不安全的数据，因为这里的用户输入数据不会向原始查询添加任何内容，例如（any或x=x）。

有关详细信息，请阅读OWASP SQL注入预防秘籍。

现在，如果您是高级用户，可以开始使用这种防御，但是对于初学者来说，如果他们不能快速实现存储过程并准备好语句，最好尽可能过滤输入数据。

最后，让我们考虑用户在下面发送此文本，而不是输入其用户名：

[1] UNION SELECT IF(SUBSTRING(Password,1,1)='2',BENCHMARK(100000,SHA1(1)),0) User,Password FROM mysql.user WHERE User = 'root'

可以在没有任何准备好的语句和存储过程的情况下尽早检查此输入，但为了安全起见，在用户数据过滤和验证之后开始使用它们。

最后一点是检测需要更多努力和复杂性的意外行为；它不建议用于普通的web应用程序。

上述用户输入中的意外行为是SELECT、UNION、IF、SUBSTRING、BENCHMARK、SHA和root。一旦检测到这些单词，就可以避免输入。

更新1:

一位用户评论说，这篇文章毫无用处，好吧！以下是OWASP.ORG提供的内容：

主要防御措施：选项#1：使用准备好的语句（参数化查询）选项#2：使用存储过程选项#3：转义所有用户提供的输入其他防御措施：同时强制：最低权限同时执行：白名单输入验证

正如你可能知道的，声称一篇文章应该有一个有效的论据支持，至少要有一个引用！否则，这被认为是一次攻击和一次糟糕的索赔！

更新2:

从PHP手册中，PHP：准备好的语句-手册：

转义和SQL注入绑定变量将由服务器自动转义。这个服务器将其转义值插入到语句模板。必须向绑定变量类型的服务器，以创建适当的转变有关详细信息，请参见mysqli_stmt_bind_param（）函数信息服务器中的值的自动转义有时是被认为是防止SQL注入的安全功能。相同的在以下情况下，可以使用未准备的报表实现安全程度输入值被正确转义。

更新3:

我创建了测试用例，以了解PDO和MySQLi在使用准备好的语句时如何将查询发送到MySQL服务器：

PDO:

$user = "''1''"; // Malicious keyword
$sql = 'SELECT * FROM awa_user WHERE userame =:username';
$sth = $dbh->prepare($sql, array(PDO::ATTR_CURSOR => PDO::CURSOR_FWDONLY));
$sth->execute(array(':username' => $user));

查询日志：

189查询SELECT*FROM awa_user WHERE username=“\”\“1”\“”189退出

MySQLi：

$stmt = $mysqli->prepare("SELECT * FROM awa_user WHERE username =?")) {
$stmt->bind_param("s", $user);
$user = "''1''";
$stmt->execute();

查询日志：

188准备SELECT*FROM awa_user WHERE username=？188执行SELECT*FROM awa_user WHERE用户名=“\”\“1”\“”188退出

很明显，准备好的语句也在逃避数据，而不是其他。

同样如上述陈述中所述，

服务器内值的自动转义有时被认为是防止SQL注入的安全功能。如果输入值被正确转义，则可以使用未准备的语句实现相同程度的安全性

因此，这证明了在发送任何查询之前对整数值进行数据验证（如intval（））是一个好主意。此外，在发送查询之前防止恶意用户数据是一种正确有效的方法。

请参阅这个问题以了解更多详细信息：PDO向MySQL发送原始查询，而Mysqli发送准备好的查询，两者都产生相同的结果

参考文献：

SQL注入秘籍SQL注入信息安全安全原则数据验证

警告：本答案中描述的方法仅适用于非常特定的场景，并不安全，因为SQL注入攻击不仅仅依赖于能够注入X=Y。

如果攻击者试图通过PHP的$_GET变量或URL的查询字符串侵入表单，如果他们不安全，您将能够抓住他们。

RewriteCond %{QUERY_STRING} ([0-9]+)=([0-9]+)
RewriteRule ^(.*) ^/track.php

因为1=1、2=2、1=2、2=1、1+1=2等……是攻击者SQL数据库的常见问题。也许它也被许多黑客应用程序使用。

但您必须小心，不能从站点重写安全查询。上面的代码为您提供了一个提示，可以重写或重定向（这取决于您）将特定的动态查询字符串黑客入侵到一个页面中，该页面将存储攻击者的IP地址，甚至是他们的COOKIES、历史记录、浏览器或任何其他敏感信息，因此您可以稍后通过禁用他们的帐户或联系当局来处理他们。