答案是使用参数化查询。核心思路是避免直接拼接用户输入与SQL语句,通过PDO或mysqli的预处理机制将SQL结构与数据分离,使用户输入始终作为纯数据处理,从而彻底防止SQL注入,安全性远高于手动过滤或转义。

PHP过滤SQL关键字,核心思路并非真的去“过滤”那些敏感词,而是要从根本上改变数据与SQL指令的交互方式,也就是采用参数化查询(Prepared Statements)。这才是防止SQL注入攻击最有效、最推荐的手段。如果非要谈及“过滤”,那也是在特定场景下对特殊字符进行转义,但这与参数化查询的安全性层级完全不同。
要安全地处理PHP中的用户输入并防止SQL注入,最稳妥的方案是使用数据库扩展提供的参数化查询(Prepared Statements)功能。无论是
PDO
mysqli
1. 使用PDO进行参数化查询:
PDO(PHP Data Objects)提供了一个轻量级的、一致的接口来访问数据库。
立即学习“PHP免费学习笔记(深入)”;
<?php
try {
$dsn = 'mysql:host=localhost;dbname=testdb;charset=utf8mb4';
$username = 'your_username';
$password = 'your_password';
$pdo = new PDO($dsn, $username, $password);
$pdo->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
<?php
$conn = new mysqli('localhost', 'your_username', 'your_password', 'testdb');
if ($conn->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
<?php
$conn = new mysqli('localhost', 'your_username', 'your_password', 'testdb');
if ($conn->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模板(比如
SELECT * FROM users WHERE id = ?
这意味着什么呢?这意味着即使你的用户输入中包含像
' OR 1=1 --
所以,这不是一个“黑名单”或“白名单”的问题,而是一个架构上的防御。它不依赖于你对所有可能攻击模式的了解,因为它从设计上就规避了这种风险。在我看来,任何现代PHP应用,如果涉及数据库交互,都应该无条件地采用参数化查询。
mysqli_real_escape_string
说实话,在现代PHP开发中,
mysqli_real_escape_string
mysqli
mysql
'
"
\
但是,它存在几个明显的局限性:
mysqli_real_escape_string
WHERE id = 1
1 OR 1=1
ORDER BY
mysqli_real_escape_string
那么,它在现代PHP中还有没有一席之地呢?我觉得,在绝大多数情况下,答案是没有。如果你正在编写新的代码,或者维护一个可以升级的现有项目,那么参数化查询应该是你的首选,甚至可以说是唯一选择。
但凡事没有绝对,我能想到的少数场景可能是:
总而言之,
mysqli_real_escape_string
当我看到一些开发者尝试通过手动过滤SQL关键字来防御注入时,心里总会咯噔一下。这通常意味着他们正在使用一种“黑名单”策略:列出所有已知的恶意SQL关键字(比如
UNION
SELECT
OR
DROP
DELETE
但为什么这种方法是极其不可靠的呢?
原因很简单:你永远无法穷尽所有可能的攻击变体。这就像一场猫鼠游戏,而攻击者永远是那个更狡猾、更有创造力的“猫”。
关键字变体与混淆: SQL语法非常灵活,攻击者可以通过各种方式来混淆关键字,使其不被简单的字符串匹配过滤掉。
SELECT
SELECT
SELECT
SEL/**/ECT
UNI--ON
%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中文网其它相关文章!
PHP怎么学习?PHP怎么入门?PHP在哪学?PHP怎么学才快?不用担心,这里为大家提供了PHP速学教程(入门到精通),有需要的小伙伴保存下载就能学习啦!
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号