答案是使用参数化查询。核心思路是避免直接拼接用户输入与SQL语句，通过PDO或mysqli的预处理机制将SQL结构与数据分离，使用户输入始终作为纯数据处理，从而彻底防止SQL注入，安全性远高于手动过滤或转义。
PHP过滤SQL关键字，核心思路并非真的去“过滤”那些敏感词，而是要从根本上改变数据与SQL指令的交互方式，也就是采用参数化查询（Prepared Statements）。这才是防止SQL注入攻击最有效、最推荐的手段。如果非要谈及“过滤”，那也是在特定场景下对特殊字符进行转义，但这与参数化查询的安全性层级完全不同。
解决方案
要安全地处理PHP中的用户输入并防止SQL注入，最稳妥的方案是使用数据库扩展提供的参数化查询（Prepared Statements）功能。无论是
PDO
还是
mysqli
扩展，都提供了这种机制。
1. 使用PDO进行参数化查询：
PDO（PHP Data Objects）提供了一个轻量级的、一致的接口来访问数据库。
立即学习“PHP免费学习笔记（深入）”；
setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION); // 设置错误模式为抛出异常 $user_input_id = $_GET['id'] ?? ''; $user_input_name = $_POST['name'] ?? ''; // 示例1：通过占位符绑定参数（推荐） $stmt = $pdo->prepare("SELECT * FROM users WHERE id = :id AND name = :name"); $stmt->bindParam(':id', $user_input_id, PDO::PARAM_INT); // 明确指定参数类型 $stmt->bindParam(':name', $user_input_name, PDO::PARAM_STR); $stmt->execute(); $result = $stmt->fetchAll(PDO::FETCH_ASSOC); // print_r($result); // 示例2：通过问号占位符绑定参数 $stmt = $pdo->prepare("INSERT INTO products (name, price) VALUES (?, ?)"); $product_name = 'New Widget'; $product_price = 19.99; $stmt->execute([$product_name, $product_price]); // 数组形式传递参数 // echo "Affected rows: " . $stmt->rowCount();} catch (PDOException $e) { // 生产环境中不应直接输出错误信息，应记录日志 error_log("Database error: " . $e->getMessage()); // echo "An error occurred. Please try again later.";}?>
2. 使用mysqli进行参数化查询：
mysqli
是MySQL数据库的增强版接口，也支持预处理语句。
connect_error) { die("Connection failed: " . $conn->connect_error);}$user_input_email = $_GET['email'] ?? '';$user_input_status = $_POST['status'] ?? '';// 示例1：查询$stmt = $conn->prepare("SELECT username, registration_date FROM members WHERE email = ? AND status = ?");if ($stmt === false) { // 错误处理，例如日志记录 error_log("Prepare failed: " . $conn->error); // die("Prepare failed: " . $conn->error);}// 绑定参数，'ss'表示两个参数都是字符串类型$stmt->bind_param('ss', $user_input_email, $user_input_status);$stmt->execute();$result = $stmt->get_result(); // 获取结果集if ($result->num_rows > 0) { while ($row = $result->fetch_assoc()) { // print_r($row); }}$stmt->close();// 示例2：插入$stmt = $conn->prepare("INSERT INTO logs (action, timestamp) VALUES (?, NOW())");if ($stmt === false) { error_log("Prepare failed: " . $conn->error);}$action_log = 'User logged in';$stmt->bind_param('s', $action_log); // 's'表示一个字符串类型参数$stmt->execute();// echo "New record created successfully.";$stmt->close();$conn->close();?>
3.
mysqli_real_escape_string
(辅助/遗留方案):
虽然强烈推荐使用参数化查询，但在某些极少数情况下（比如处理非SQL语句的数据，或者在极老的代码库中），
mysqli_real_escape_string
可以作为一种辅助手段来转义字符串中的特殊字符。它并不能替代预处理语句的安全性。
connect_error) { die("Connection failed: " . $conn->connect_error);}$user_search_term = $_GET['term'] ?? '';// 在将字符串拼接到SQL语句之前进行转义$escaped_search_term = $conn->real_escape_string($user_search_term);// 这种方式依然不推荐，因为它容易遗漏，且不如参数化查询安全$sql = "SELECT * FROM articles WHERE title LIKE '%" . $escaped_search_term . "%'";$result = $conn->query($sql);// ... 处理结果 ...$conn->close();?>
核心思想是：永远不要直接将用户输入拼接到SQL语句中。 参数化查询将SQL逻辑与数据分离，数据库在执行前就知道哪些是指令，哪些是数据，从而有效阻止了恶意注入。
参数化查询：为何它是抵御SQL注入的终极武器？
在我看来，参数化查询之所以被称为“终极武器”，是因为它从根本上改变了数据库处理查询的方式，而不是简单地在表面上“过滤”或“清洗”数据。我们都知道，SQL注入的本质是攻击者利用应用程序对用户输入处理不当，将恶意的SQL代码注入到原本的数据中，使得数据库在执行时将这些恶意代码当作合法的SQL指令来执行。
参数化查询的工作原理是这样的：你先向数据库发送一个带有占位符的SQL模板（比如
SELECT * FROM users WHERE id = ?
），这个模板定义了查询的结构。数据库收到这个模板后，会对其进行解析和预编译，它知道哪里是查询的条件，哪里是将来要接收数据的地方。然后，你再将实际的用户数据作为独立的参数发送给数据库。数据库接收到这些参数后，会严格地将它们视为数据，并填充到之前预编译的SQL模板中。
这意味着什么呢？这意味着即使你的用户输入中包含像
' OR 1=1 --
这样的SQL关键字或攻击代码，数据库也只会把它当成一个普通的字符串值，而不是可以执行的SQL指令。它不会去解析这些字符作为SQL语法的一部分，因为查询的结构在数据到来之前就已经固定了。这种“先定结构，后填数据”的模式，彻底切断了攻击者通过数据来改变SQL指令的可能性。
所以，这不是一个“黑名单”或“白名单”的问题，而是一个架构上的防御。它不依赖于你对所有可能攻击模式的了解，因为它从设计上就规避了这种风险。在我看来，任何现代PHP应用，如果涉及数据库交互，都应该无条件地采用参数化查询。
mysqli_real_escape_string
：在现代PHP开发中还有一席之地吗？
说实话，在现代PHP开发中，
mysqli_real_escape_string
的地位已经非常尴尬了。它曾经是防止SQL注入的重要工具，尤其是在
mysqli
或
mysql
（已废弃）扩展时代，当预处理语句还不那么普及或者开发者对其理解不深时。它的作用是转义字符串中的特殊字符，比如单引号（
'
）、双引号（
"
）、反斜杠（
）、NULL字符等等，这些字符在SQL语句中具有特殊含义。通过在将用户输入拼接到SQL语句之前进行转义，可以防止这些特殊字符被解释为SQL语法的一部分。
怪兽AI数字人
数字人短视频创作，数字人直播，实时驱动数字人
44 查看详情 
但是，它存在几个明显的局限性：
易于遗漏： 你必须手动地、有意识地对每一个可能来自用户输入的字符串进行转义。一旦忘记，就可能留下漏洞。而参数化查询是统一处理的，很难遗漏。仅适用于字符串：
mysqli_real_escape_string
只能处理字符串类型的数据。如果你的查询条件是数字（例如
WHERE id = 1
），攻击者依然可以通过注入
1 OR 1=1
这样的数字类型注入，因为它不会被转义。当然，你可以先强制类型转换，但那又增加了额外的步骤和出错的可能。与数据库连接相关： 它需要一个活动的数据库连接才能工作，因为转义规则可能因数据库的字符集设置而异。无法防御所有注入： 比如
ORDER BY
子句的注入，或者某些高级的盲注技术，
mysqli_real_escape_string
可能就显得力不从心了。
那么，它在现代PHP中还有没有一席之地呢？我觉得，在绝大多数情况下，答案是没有。如果你正在编写新的代码，或者维护一个可以升级的现有项目，那么参数化查询应该是你的首选，甚至可以说是唯一选择。
但凡事没有绝对，我能想到的少数场景可能是：
遗留系统维护： 如果你接手了一个庞大且老旧的系统，改造成本巨大，而其中某些非核心、低风险的功能确实难以快速切换到预处理语句，那么作为一种临时或局部的补救措施，它或许还有点用。但这仅仅是权宜之计，并且风险自担。非SQL上下文的字符串处理： 有时候你可能需要对一个字符串进行“安全处理”，但这个字符串最终不是直接拼接到SQL语句中，而是用于其他需要转义特殊字符的场景。这种情况下，它的转义功能可能还有用，但这已经脱离了SQL注入防御的范畴。
总而言之，
mysqli_real_escape_string
就像一把老旧的工具，它有它的历史贡献，但面对现代的挑战和更强大的新工具（参数化查询），它的作用已经微乎其微，甚至可以说，它的存在反而可能让一些开发者产生错觉，以为自己已经足够安全了。
避免手动过滤陷阱：黑名单策略为何不可靠？
当我看到一些开发者尝试通过手动过滤SQL关键字来防御注入时，心里总会咯噔一下。这通常意味着他们正在使用一种“黑名单”策略：列出所有已知的恶意SQL关键字（比如
UNION
,
SELECT
,
OR
,
DROP
,
DELETE
等），然后检查用户输入中是否包含这些词，如果包含就阻止或替换掉。
但为什么这种方法是极其不可靠的呢？
原因很简单：你永远无法穷尽所有可能的攻击变体。这就像一场猫鼠游戏，而攻击者永远是那个更狡猾、更有创造力的“猫”。
关键字变体与混淆： SQL语法非常灵活，攻击者可以通过各种方式来混淆关键字，使其不被简单的字符串匹配过滤掉。
大小写混淆：
SELECT
vs
SELECT
vs
SELECT
注释：
SEL/**/ECT
,
UNI--ON
编码： 十六进制编码、URL编码等，例如
%55%4E%49%4F%4E
代表
UNION
特殊字符：
UNI(ON
(某些数据库会忽略括号内的字符)双重转义： 如果你的过滤逻辑在某个环节先转义了，攻击者可能会利用这一点进行双重转义来绕过。空白字符变体： 各种空格、制表符、换行符的组合。
语义分析的复杂性： 数据库引擎在解析SQL时，会进行复杂的词法和语法分析。你的简单字符串匹配过滤，根本无法达到数据库引擎的理解深度。它可能认为
OR 1=1
是恶意注入，但攻击者可能写成
' OR '1'='1
，或者利用其他函数如
LENGTH()
、
SUBSTRING()
进行盲注，这些并不直接包含明显的“恶意关键字”。
过滤不当可能导致合法数据被阻止： 如果你过滤得过于严格，可能会误伤正常的业务数据。比如，某个商品名称中恰好包含了
UNION
这个词，你的过滤就会阻止这个合法的数据。
维护成本高昂： 随着新的攻击手法和数据库特性的出现，你需要不断更新你的黑名单，这几乎是不可能完成的任务。你永远都在追赶攻击者的脚步。
在我看来，尝试手动过滤SQL关键字，无异于在堵一个千疮百孔的堤坝，你堵住了一个漏洞，攻击者很快就会在旁边找到另一个。这种策略不仅效率低下，而且给人一种虚假的安全感，最终只会让系统面临更大的风险。
构建安全的数据库交互层，应该遵循“白名单”原则，但这里的“白名单”不是指过滤关键字，而是指只允许明确定义和预期的数据类型和结构进入SQL查询。而参数化查询正是这种“白名单”思维在SQL注入防御上的最佳实践，因为它确保了数据永远作为数据处理，而不是作为可执行代码。
以上就是PHP如何过滤SQL关键字_PHPSQL关键字过滤函数使用教程的详细内容，更多请关注php中文网其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/69622.html
微信扫一扫 
支付宝扫一扫 
