预处理语句可有效防御SQL注入，因其将SQL结构与数据分离，参数值永不被解析为代码；需配合最小权限原则、关闭危险配置及白名单校验动态结构场景。
用预处理语句代替字符串拼接
SQL注入本质是用户输入被当作SQL代码执行，最直接有效的防御就是切断「输入 → 代码」的通路。MySQLi 和 PDO 都支持预处理（prepared statement），它把 SQL 结构和数据分开传输，服务端先编译语句模板，再绑定参数，此时参数值永远不会被解析为语法的一部分。
常见错误是仍用 mysqli_query() 拼接 $_GET['id'] 或 $_POST['username']：
mysqli_query($conn, "SELECT * FROM users WHERE id = " . $_GET['id']); // 危险！
正确做法是使用 mysqli_prepare() + mysqli_stmt_bind_param()，或 PDO 的 prepare() + execute()：
$stmt = $pdo->prepare("SELECT * FROM users WHERE username = ? AND status = ?");
$stmt->execute([$_POST['username'], 1]);- 问号占位符（?）或命名参数（:name）由驱动层做类型转换和转义，不依赖 PHP 层手动过滤
- 即使传入
' OR 1=1 --，也会被当作文本值匹配，不会改变 SQL 逻辑 - 注意：
mysql_real_escape_string()已废弃且不解决所有场景（如数字上下文无引号时无效），别用
最小权限原则：给应用账户只配必要权限
一个 Web 应用通常只需要查、增、改少量表，却常被赋予 GRANT ALL ON *.*，这是高危配置。攻击者一旦突破应用层（比如上传 Webshell 或利用框架漏洞），就能直接执行 DROP DATABASE 或读取 mysql.user 表。
应为每个应用创建独立账号，并限制作用域：
- 用
CREATE USER 'app_rw'@'192.168.1.%' IDENTIFIED BY 'strong_pwd';明确指定 IP 段 - 只授权具体库表：
GRANT SELECT, INSERT, UPDATE ON myapp.users TO 'app_rw'@'%'; - 禁止授予
FILE、PROCESS、SUPER等高危权限（它们可能用于读写文件或提权） - 生产环境禁用 root 远程登录；本地管理用
localhost限定，避免暴露在公网
关闭危险配置与默认账户
MySQL 默认安装带一些便利但不安全的选项，上线前必须检查：
-
skip-grant-tables必须关闭——它会跳过所有权限验证，仅调试时临时启用 -
local_infile默认为 ON（尤其 MySQL 5.6+），攻击者可通过LOAD DATA LOCAL INFILE读取服务器任意文件，应在 my.cnf 中设为local_infile = OFF并重启 - 删除匿名用户：
DELETE FROM mysql.user WHERE User = ''; - 删除 test 库：
DROP DATABASE IF EXISTS test;（它默认允许任何用户访问） - 确保
secure_file_priv设为非空路径（如/var/lib/mysql-files/），限制LOAD_FILE()和INTO OUTFILE的读写范围
应用层还需防绕过预处理的边界场景
预处理能挡住绝大多数注入，但有些地方它根本不起作用——因为 SQL 语法不允许参数化。比如表名、列名、排序字段、LIMIT 的 offset 值，这些都必须拼接进 SQL 字符串。
这时不能靠“过滤关键词”，而要走白名单校验：
- 排序字段只能从预定义数组中选：
$valid_sorts = ['created_at', 'status', 'score'];，再用in_array($_GET['sort'], $valid_sorts)判断 - LIMIT 的 offset 和 count 必须强制转整型：
(int)$_GET['offset']，并加范围限制（如max(0, min(1000, $offset))） - 动态表名绝不能来自用户输入；如需多租户分表，应通过配置映射而非直接拼接
- 存储过程内若用
CONCAT()拼 SQL 再EXECUTE，同样属于二次注入点，要同样白名单处理
真正难防的从来不是标准 CRUD，而是那些需要动态结构的场景——那里没有银弹，只有严格约束和人工审查。
