Yii框架如何防止SQL注入

Yii框架虽通过ActiveRecord的数组式where语法（如['username' => $input]）天然具备SQL注入防护能力，得益于PDO预处理机制，但开发者极易在字符串拼接、动态orderBy/groupBy、原生SQL编写及IN子句处理等场景中因误用或疏忽而引入高危漏洞；必须严格遵循参数化绑定、白名单校验（尤其对排序/分组字段）、使用Yii内置工具生成安全占位符等最佳实践，切忌依赖转义函数或正则模糊过滤——真正的安全不来自“差不多”，而源于对每个用户输入点的审慎控制与明确约束。

ActiveRecord 查询天然防注入，但别乱用 where 的数组语法

Yii 2 的 User::find()->where(['username' => $input]) 这类写法，默认走 PDO 预处理，$input 不管是 'admin\' OR 1=1--' 还是空字符串，都会被当纯值处理，不会触发 SQL 注入。这是最省心、最推荐的路径。

但注意：如果写成 where('username = "' . $input . '"') 或 where("username = '$input'")，就立刻掉进坑里——字符串拼接绕过了所有防护机制。

常见错误场景：

• 在动态构建条件时，误把用户输入直接拼进 SQL 字符串
• 从旧 PHP 项目迁移代码，保留了 mysql_real_escape_string 思维，以为加了转义就安全
• 在 orderBy、groupBy 等子句中传入未校验的用户参数（这些不支持参数绑定）

原生 SQL 必须用 bindValue 或命名占位符，别碰 bindParam 的引用陷阱

当你必须写原生 SQL（比如复杂视图、存储过程调用），createCommand() 是唯一入口，但绑定方式决定生死。

正确做法是用命名占位符 + bindValue()：

$sql = 'SELECT * FROM post WHERE status = :status AND created_at > :since';
$posts = Yii::$app->db->createCommand($sql)
    ->bindValue(':status', $status, \PDO::PARAM_INT)
    ->bindValue(':since', $dateStr, \PDO::PARAM_STR)
    ->queryAll();

容易踩的坑：

• bindParam() 是引用传递，如果变量后续被修改，执行时会取最新值，导致结果不可控
• 漏写第三个参数（如 \PDO::PARAM_INT）可能导致类型隐式转换，影响索引或比较逻辑
• 用问号占位符（?）时，顺序必须严格对应 bindValue() 调用顺序，易错且难维护

IN 子句里的数组参数不能直接塞，得用 createNamedParameters

用户提交了一组 ID：[101, 205, 333]，想查 WHERE id IN (101, 205, 333)。别手写字符串拼接，也别用 where(['id' => $ids])（它只适用于 ActiveRecord 查询，且底层仍需生成占位符）。

正确解法是让 Yii 帮你生成带序号的占位符：

$ids = [101, 205, 333];
$params = Yii::$app->db->getQueryBuilder()->createNamedParameters($ids);
// 返回 [':qp0' => 101, ':qp1' => 205, ':qp2' => 333]
<p>$sql = 'SELECT * FROM user WHERE id IN (' . implode(', ', array_keys($params)) . ')';
$users = Yii::$app->db->createCommand($sql, $params)->queryAll();
</p>

关键点：

• 手动拼 IN 列表（如 "'".implode("','", $ids)."'"）等于放弃所有防护
• Query 构建器的 andWhere(['id' => $ids]) 在原生 SQL 场景下不生效，它只作用于 Query 对象
• 数组过大时（如上千 ID），要考虑分批查询或改用临时表，避免 SQL 长度超限或性能骤降

ORDER BY 和 GROUP BY 字段必须白名单校验

这类子句无法参数化——数据库不允许把列名/表名当参数绑定。所以任何来自用户的排序字段（如 $_GET['sort']）都必须显式限制范围。

推荐写法：

$allowedSorts = ['name', 'created_at', 'status', 'price'];
$sort = Yii::$app->request->get('sort', 'created_at');
if (!in_array($sort, $allowedSorts)) {
    throw new BadRequestHttpException('Invalid sort field');
}
$posts = Post::find()->orderBy($sort . ' DESC')->all();

为什么不能妥协：

• 用 preg_match('/^[a-zA-Z_][a-zA-Z0-9_]*$/', $sort) 校验看似宽松，但可能放行 name ASC, id DESC 这类组合，破坏预期逻辑
• 前端传 sort=name;DROP TABLE user;，即使正则没拦住，后端拼进去也会执行恶意语句
• 模型规则（rules()）对 orderBy 无效，它只校验属性赋值，不干预查询构造

真正危险的不是技术多难，而是开发者误以为“用了 Yii 就万事大吉”，在 orderBy 这种地方随手接用户输入。白名单不是可选项，是强制项。

到这里，我们也就讲完了《Yii框架如何防止SQL注入》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于Yii框架的知识点！