Yii中$request->get()和$request->post()不自动过滤输入，返回的是原始字符串，无类型转换或校验；正确做法是通过模型验证层（如rules()声明约束并调用validate()）确保数据安全。
Yii中$request->get()和$request->post()不自动过滤输入
直接调用 $request->get('id') 或 $request->post('email') 拿到的是原始字符串，没有任何类型转换、空格截断、编码归一化或合法性校验。这不是“漏了过滤”，而是设计如此：Yii 的 Request 类只是对 $_GET 和 $_POST 的封装，不是 filter_input() 的替代品。
常见错误现象：
-
$id = (int)$request->get('id')—— 输入"1abc"会转成1，仍是脏数据 -
"SELECT * FROM user WHERE name = '" . $request->get('name') . "'"—— 直接拼 SQL，100% SQL 注入风险 - 前端传
{"status":"active"}，后端却用$request->post('status')取不到值（因为是 JSON，不是 form-data）
正确做法优先走模型验证层，而不是对每个参数单独 cast 或 filter_var：
- 定义一个继承
Model的表单类，rules()中声明字段类型、范围、格式等约束 - 用
$form->load($request->get(), '')或$form->load($request->post(), '')绑定数据 - 必须调用
$form->validate()，只有通过才使用$form->id等属性
Active Record save() 不等于自动过滤，safe 属性才是关键
Model::save() 本身不做字段过滤，它只执行验证通过后的赋值与持久化。是否允许用户提交某字段，取决于该字段是否在 rules() 中被标记为 safe，或显式列入 scenarios() 的 safe 列表。
常见错误现象：
- 模型里有
public $avatar_url;，但没在rules()中声明为safe，结果$model->load($post)后该字段始终为空，误以为是框架 bug - 把敏感字段（如
is_admin、status）也设为safe，导致用户可通过 POST 直接篡改
安全实践要点：
- 默认不设
safe，只对明确允许用户修改的字段加['attribute', 'safe'] - 用
['attribute', 'filter', 'filter' => 'trim']做前置清理，比手动trim()更可靠 - 用
['attribute', 'default', 'value' => 0]防止空值穿透，尤其对整型/布尔字段 - 更新操作慎用
load()全量绑定；推荐用$model->setAttributes(['name' => $name], false)显式控制字段
原生 SQL 和 Query 构建器里的动态字段必须白名单校验
Active Record 的 where(['status' => $status]) 是安全的，但一旦涉及字段名、排序、分组、连表别名等动态结构，AR 就不再兜底。这些地方若拼接用户输入，就是裸奔状态。
常见错误写法：
-
->orderBy($_GET['sort'] . ' DESC')—— 攻击者传sort=id; DROP TABLE user--即可触发注入 -
->join('LEFT JOIN', 'orders o', 'u.id = o.user_id AND o.status = ' . $_GET['status'])—— 字符串拼接绕过所有预处理 -
->select($_GET['fields'])—— 可能注入函数调用或子查询
正确做法：
- 排序字段严格白名单：
if (!in_array($sort, ['created_at', 'price', 'name'])) { throw new BadRequestHttpException(); } - 再用
->orderBy([$sort => SORT_DESC])，而非字符串拼接 - 字段名、表名、别名一律来自配置数组或常量，不接受用户输入
- IN 查询不要手拼：
createCommand()->bindValues(array_fill(0, count($ids), ':id'))->execute()或用str_repeat()动态生成占位符
文件上传、JSON body、XML 解析等非标准输入需额外识别和清理
$request->post() 只读取 application/x-www-form-urlencoded 和 multipart/form-data 请求体。其他类型的数据（如 JSON、XML、纯文本）必须主动识别 content-type 并换用对应方法解析，否则拿不到数据还误判为“参数缺失”。
典型陷阱：
- 前端用
fetch('/api/user', { method: 'POST', body: JSON.stringify({name:'a'}) })，后端写$request->post('name')→ 返回 null - XML 上传未调用
libxml_disable_entity_loader(true)，可能触发 XXE 攻击 - 文件名直接拼进路径：
$file->saveAs('/uploads/' . $_FILES['file']['name'])→ 路径遍历（../../etc/passwd）
应对方式：
- 先判断
$request->getContentType()，JSON 就用Json::decode($request->getRawBody()) - XML 解析前必须禁用外部实体：
libxml_disable_entity_loader(true)（Yii 2.0+ 仍需手动加） - 文件名强制重命名：
basename(pathinfo($file->name, PATHINFO_FILENAME)) . '_' . time() . '.' . $file->extension - 扩展名二次校验：不能只信
$file->extension，要读取文件头（magic number）确认真实类型
最易被忽略的一点：所有从请求中提取的值，无论经过多少层封装，只要最终用于 SQL 字段、文件路径、HTML 输出、系统命令，就必须在那个使用点上重新确认其安全性——没有“一次过滤，处处安全”这回事。
