YII框架的SQL注入是什么？YII框架如何防止注入攻击？-YII-PHP中文网

YII框架的SQL注入是什么？YII框架如何防止注入攻击？

月夜之吻

发布： 2025-08-12 15:29:01

原创

170人浏览过

yii框架中sql注入的防范核心在于参数化查询和输入验证，使用activerecord或yii\db\command的参数绑定功能可有效阻止注入，避免直接拼接sql字符串，尤其在where、order by、group by等子句中需对用户输入进行白名单校验或参数化处理，同时结合模型验证规则实现深度防御，从而全面保障数据库安全。

YII框架的SQL注入是什么？YII框架如何防止注入攻击？

Yii框架中的SQL注入，简单来说，就是恶意用户通过在输入框里塞入一些精心构造的SQL代码，让数据库误以为这些代码是合法指令，从而执行非预期的操作，比如窃取数据、修改数据甚至删除整个表。Yii在设计之初就考虑到了这一点，它主要通过两种方式来筑起防线：一是默认推荐并广泛使用的参数化查询（体现在其ActiveRecord和

yii\db\Command

登录后复制

中），二是强调对所有用户输入进行严格的验证和过滤。

在Yii框架里，防止SQL注入的核心策略，其实是深植于其数据库抽象层设计之中的。首先，也是最推荐的方式，就是使用ActiveRecord。当你通过ActiveRecord进行数据查询、插入、更新或删除时，Yii会在底层自动帮你处理参数绑定。这意味着，无论用户输入了什么奇奇怪怪的字符，它们都会被当作纯粹的数据值来处理，而不是SQL代码的一部分。比如：

$user = User::find()->where(['username' => $inputUsername])->one();

登录后复制

这里的

$inputUsername

登录后复制

，即使包含

' OR '1'='1

登录后复制

这样的恶意字符串，Yii也会把它当作一个完整的字符串值去匹配

username

登录后复制

字段，而不是将其解析为SQL逻辑。这种机制从根本上杜绝了注入的可能。

对于那些需要编写更复杂、更定制化的SQL语句的场景，Yii提供了

yii\db\Command

登录后复制

对象。这时候，关键在于利用其提供的参数绑定方法，比如

bindValue()

登录后复制

或

bindParam()

登录后复制

。

$sql = "SELECT * FROM post WHERE status=:status AND author_id=:authorId";
$posts = Yii::$app->db->createCommand($sql)
    ->bindValue(':status', 1)
    ->bindValue(':authorId', $userId)
    ->queryAll();

登录后复制

看到没，我们不是直接把变量拼接到SQL字符串里，而是用占位符（如

:status

登录后复制

）来代替，然后单独绑定参数。数据库在执行时会区分开SQL结构和数据内容，这就像你给快递员一个包裹，包裹里装的是什么（数据）和包裹本身是什么（SQL结构）是两码事，快递员只会按包裹上的地址（SQL结构）送货，而不会打开包裹看里面是什么（数据）来决定怎么送。

尽管参数化查询是抵御SQL注入的利器，但输入验证和过滤依然是不可或缺的防线。这不仅仅是为了SQL注入，更是为了整个应用的安全和数据的完整性。Yii的模型（Model）层提供了强大的验证规则（rules），你可以强制规定输入的数据类型、长度、格式等等。比如：

public function rules()
{
    return [
        ['username', 'string', 'max' => 255],
        ['email', 'email'],
        ['age', 'integer', 'min' => 0],
    ];
}

登录后复制

通过这些规则，可以在数据进入数据库之前就将其规范化，甚至直接拒绝掉不合法的输入。这是一种“深度防御”的策略，即使某个环节的参数绑定失效（虽然Yii的ActiveRecord和Command很难失效），数据在进入数据库前也已经被“清洗”过了。

最后，虽然不常用，但Yii也提供了

quoteValue()

登录后复制

方法来手动对字符串进行转义。然而，强烈建议优先使用参数化查询，因为手动转义很容易出错，而且不如参数化查询那样彻底和安全。这就像你有一个自动驾驶汽车，却非要自己手动去开，风险自然就高了。

Yii应用中，哪些地方最容易出现SQL注入的隐患？

即便Yii框架提供了强大的防注入机制，但在实际开发中，一些不规范的操作或者对框架理解不够深入，仍然可能无意间留下漏洞。我个人觉得，最容易“踩雷”的地方主要有这么几个：

直接拼接SQL字符串，尤其是在

createCommand()->query()

登录后复制

或
queryAll()
登录后复制
中：这是最经典、也最致命的错误。当你放弃使用参数绑定，而是直接把用户输入或者未经充分验证的变量拼接到SQL语句里时，你就等于在自己的数据库门口打开了一扇大门。

// 错误示范：直接拼接用户输入
$sql = "SELECT * FROM product WHERE name LIKE '%" . $_GET['keyword'] . "%'";
$products = Yii::$app->db->createCommand($sql)->queryAll();

登录后复制

这里的

$_GET['keyword']

登录后复制

如果被注入

%' OR 1=1 --

登录后复制

，那后果不堪设想。正确的做法是使用参数绑定：

// 正确做法：使用参数绑定
$sql = "SELECT * FROM product WHERE name LIKE :keyword";
$products = Yii::$app->db->createCommand($sql)
    ->bindValue(':keyword', '%' . $_GET['keyword'] . '%')
    ->queryAll();

登录后复制

或者更Yii的方式，用ActiveRecord：

$products = Product::find()->where(['like', 'name', $_GET['keyword']])->all();

登录后复制

动态构建
```
ORDER BY
```
登录后复制
登录后复制
或
GROUP BY
登录后复制
登录后复制
子句： ActiveRecord在处理
```
WHERE
```
登录后复制
条件时会自动进行参数化，但对于
```
ORDER BY
```
登录后复制
登录后复制
和
```
GROUP BY
```
登录后复制
登录后复制
这种涉及列名或函数的情况，它通常不会自动转义。如果直接将用户可控的输入用于排序或分组字段，就可能被注入。
```
// 潜在风险：直接使用用户输入作为排序字段
$sortField = $_GET['sort'] ?? 'id';
$users = User::find()->orderBy($sortField)->all();
```
登录后复制
如果
```
$_GET['sort']
```
登录后复制
是
```
id DESC, (SELECT SLEEP(5))
```
登录后复制
，那就会导致延迟攻击。正确的做法是，对这类动态字段进行白名单校验：
```
$validSortFields = ['id', 'username', 'email'];
$sortField = in_array($_GET['sort'], $validSortFields) ? $_GET['sort'] : 'id';
$users = User::find()->orderBy($sortField)->all();
```
登录后复制
使用
```
addExpression()
```
登录后复制
或
addSelect()
登录后复制
时，不注意参数化：有时为了实现一些复杂的查询逻辑，我们会用到这些方法来添加自定义的SQL表达式。如果表达式中包含了用户输入，而没有进行适当的参数绑定或验证，也可能留下漏洞。
```
// 潜在风险：在addSelect中直接拼接
```
登录后复制

以上就是YII框架的SQL注入是什么？YII框架如何防止注入攻击？的详细内容，更多请关注php中文网其它相关文章！