yii 1.1.23 本身无模板引擎，不存在原生“模板注入”漏洞；所谓风险实为两类：一是 render() 直接使用用户可控视图名导致目录遍历或rce；二是项目混用twig等第三方模板引擎引发的ssti。
Yii 1.1.23 本身不是模板引擎，它不自带模板渲染功能，也没有“Yii 模板注入”这一原生漏洞类型。你看到的“Yii 1.1.23 模板注入”大概率是误标或混淆，实际风险来自以下两种典型场景之一：
✅ 真实风险点一：Yii 1.1.23 中的 CController::render() + 外部可控视图名拼接
这是 Yii 1.1.x 最常见的 SSTI 类风险路径（虽非严格模板注入，但可导致任意文件读取、目录遍历甚至配合其他条件触发代码执行）。
典型危险写法：
public function actionView() {
$template = $_GET['tpl']; // 用户完全可控
$this->render($template); // 直接传入 render()，无校验
}
后果：
- 攻击者可传入
../../config/main.php读取数据库密码； - 若开启
allow_url_include，可能配合php://filter或远程协议读取敏感内容； - 在极特殊配置下（如自定义视图类、存在危险 eval 逻辑），可能升级为 RCE。
修复方式：
- ❌ 禁止将任何用户输入直接拼接进视图路径；
- ✅ 使用白名单校验：
$allowed = ['article', 'user_profile', 'help']; $template = $_GET['tpl']; if (!in_array($template, $allowed)) { throw new CHttpException(400, 'Invalid template'); } $this->render($template); - ✅ 或统一用固定前缀 + 后缀，禁用路径分隔符：
$template = preg_replace('/[^a-z0-9_]/i', '', $_GET['tpl']); $this->render('pages/' . $template); // 强制限定目录
✅ 真实风险点二：项目中混用了其他模板引擎（如 Twig、Smarty），而 Yii 是宿主框架
常见于老项目升级过程中：
- Yii 1.1.23 作为 MVC 框架运行；
- 业务模块却用
Twig_Environment::render()动态加载用户提交的模板字符串； - 此时漏洞本质是 Twig 模板注入（SSTI），和 Yii 无关，但扫描工具常归因到“Yii 应用”。
验证方法：
搜索项目代码中是否出现：
new Twig_Environment(-
->render(配合用户输入的$templateStr -
eval(、create_function(、call_user_func(等动态执行函数调用模板内容
修复核心：
- ⚠️ 绝对禁止将用户输入当作模板源码去
render()； - ✅ 模板必须来自预置文件（如
templates/email/welcome.twig），且路径由白名单控制； - ✅ 如需“用户自定义样式”，应仅开放变量赋值（如
twig->render('mail.twig', ['title' => $userInput])），而非让用户写{% if 1*7 %}...{% endif %}这类逻辑。
? 关键提醒：Yii 1.1.23 已停止维护多年
- 官方早在 2015 年就终止支持 Yii 1.x；
- 1.1.23 发布于 2020 年（社区维护版），不包含现代安全机制（如 CSP 默认头、自动转义、沙箱模板）；
- 所有依赖
$_GET/$_POST直接参与路径、类名、文件名、回调函数名的逻辑，都应视为高危。
强烈建议：
- 将系统迁移至 Yii 2.0.48+ 或 Yii 3.x（已内置更严格的视图隔离与参数过滤）；
- 若无法升级，至少在入口层加 Nginx 规则拦截可疑视图参数：
if ($args ~ "(tpl|view|template)=[^&]*\.\.") { return 400; } if ($args ~ "(tpl|view)=[^&]*[[:cntrl:]\$\{\}\[\]]") { return 400; }
不复杂，但容易忽略的是：风险不在 Yii 版本号本身，而在你如何用它拼接、加载、执行外部数据。 抓住“用户输入 → 文件路径 / 类名 / 模板内容”这条链，逐个堵死，比纠结版本号更有效。
