如何修复用户鉴权接口中的SQL注入-SQL-PHP中文网

唯一能根治SQL注入的方案是参数化查询，其他过滤、转义等均为补丁；登录接口因鉴权依赖用户输入（如username、password）且旧代码常拼接字符串，极易被admin'--或'OR 1=1绕过；PHP中必须用mysqli_prepare()或PDO::prepare()，严禁mysql_query()或mysqli_query()拼接，且密码须哈希存储、字段名/表名等动态结构需白名单校验。

如何修复用户鉴权接口中的sql注入

直接改用参数化查询，别拼字符串。这是唯一能根治的方案，其他过滤、转义、黑名单都是补丁，迟早被绕过。

为什么登录接口最容易中招

鉴权逻辑天然依赖用户可控输入（username、password、email），而旧代码常写成：
SELECT * FROM users WHERE username = '$_POST[username]' AND password = '$_POST[password]'
只要输入 admin' -- 或 ' OR 1=1 #，整个验证逻辑就失效。这不是“可能被攻击”，而是“必然可被绕过”。

PHP 中必须用 `mysqli_prepare()` 或 `PDO::prepare()`

不要用 mysql_query()（已废弃）或 mysqli_query() 拼接字符串。
正确做法是分离 SQL 结构与数据：

/* PDO 示例 */
$stmt = $pdo->prepare("SELECT id, role FROM users WHERE username = ? AND password_hash = ?");
$stmt->execute([$username, $password_hash]);
$user = $stmt->fetch();

注意：

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

? 占位符不接受字段名、表名、排序方向等动态结构 —— 这些必须硬编码或白名单校验
密码必须提前哈希（如 password_hash()），绝不能明文比对
如果用 MySQLi，对应方法是 mysqli_prepare() + bind_param()，类型字符（s 字符串、i 整数）不能错

Java Spring Boot 里别碰 `String.format()` 或 `+` 拼 SQL

常见错误写法：
String sql = "SELECT * FROM user WHERE username = '" + username + "'";
正确路径只有两条：

用 JdbcTemplate 的 query() / update() 带参数重载方法：jdbcTemplate.query("SELECT * FROM user WHERE username = ?", new Object[]{username}, ...)
用 MyBatis 时，所有参数必须用 #{}，禁用 ${} —— 后者直接字符串替换，等同于拼接
Spring Data JPA 的方法命名（如 findByUsername()）底层自动参数化，安全；但自定义 @Query 时，也必须用 ?1 或 :name 绑定参数

修复后仍要检查三类漏网之鱼

参数化不是银弹，以下场景极易被忽略：

ORDER BY / LIMIT 动态字段：比如 ORDER BY ${sortField} —— 必须用白名单校验：in_array($sortField, ['created_at', 'name'], true)
LIKE 模糊搜索：用户输入 %admin% 本身合法，但若拼进 SQL：WHERE name LIKE '%'.$keyword.'%' 就危险 —— 改用参数化：WHERE name LIKE CONCAT('%', ?, '%')
多租户场景的 schema 或 table 名：如 SELECT * FROM tenant_{$tenantId}.users —— 表名无法参数化，必须严格校验 $tenantId 是否匹配正则 ^[a-z0-9_]{3,20}$，且查库确认该租户存在