PHP防SQL注入方法详解

防止SQL注入最有效的方式是使用预处理配合参数化查询，而非拼接SQL；需禁用动态表名/字段名拼接，改用白名单校验；数据库账号应遵循最小权限原则并屏蔽错误信息。

防止SQL注入最有效的方式是不拼接SQL语句，而是使用预处理（Prepared Statements）配合参数化查询。这是PHP操作数据库时保障安全的基石，不是“可选技巧”，而是必须遵循的标准做法。

用PDO或MySQLi启用预处理

原生字符串拼接（如 "SELECT * FROM user WHERE id = " . $_GET['id']）直接暴露在注入风险下。正确做法是把SQL结构和数据完全分离：

• PDO示例：`$stmt = $pdo->prepare("SELECT * FROM users WHERE email = ? AND status = ?");`
  `$stmt->execute([$_POST['email'], 1]);`
• MySQLi面向对象示例：`$stmt = $mysqli->prepare("INSERT INTO logs (action, ip) VALUES (?, ?)");`
  `$stmt->bind_param("ss", $action, $ip);`
  `$stmt->execute();`

问号占位符（或命名参数如 :email）由驱动自动转义并绑定类型，攻击者无法突破SQL语法边界。

过滤输入不能替代预处理

用 htmlspecialchars()、filter_var() 或正则过滤用户输入，只适用于输出显示或简单校验，不能用于构造SQL。例如：

• intval($_GET['id']) 看似安全，但仅适用于整数字段，且掩盖了设计缺陷——本就不该让ID参与字符串拼接
• addslashes() 或 mysql_real_escape_string()（已废弃）已被证明在多字节编码等场景下可能失效

过滤是辅助手段，不是SQL安全的主力。重心必须放在“不拼接”上。

避免动态表名/字段名，必要时白名单校验

预处理无法绑定表名、列名或ORDER BY字段。若业务真需动态指定（如多租户切换表），绝不可直接插入变量：

• 错误：$sql = "SELECT * FROM " . $_GET['table'] . " WHERE id = ?";`
• 正确：限定可选范围，用白名单判断
  `$allowed_tables = ['users', 'posts', 'comments'];`
  `$table = in_array($_GET['table'], $allowed_tables) ? $_GET['table'] : 'users';`
  `$sql = "SELECT * FROM {$table} WHERE id = ?";`

没有绝对安全的“动态拼接”，只有受控的、穷举的、显式声明的选项。

最小权限原则 + 错误信息屏蔽

数据库账号权限要严格限制。应用账号只需 SELECT/INSERT/UPDATE 必需表，禁用 DROP、UNION、LOAD_FILE 等高危操作权限。同时关闭详细错误输出：

• 开发环境可开 display_errors=On，生产环境务必设为 Off，改用日志记录
• 避免泄露表结构、字段名、数据库版本等敏感信息，防止攻击者辅助构造注入语句

基本上就这些。不复杂，但容易忽略。坚持用预处理，守住SQL结构和数据的边界，99%的注入风险自然消失。