存储型xss防御核心在于输出编码而非入库过滤：必须根据html、属性、js、url等上下文，分别使用chtml::encode、cjson::encode、urlencode等精准编码，严禁直接echo用户数据，富文本需htmlpurifier白名单清洗。
Yii 1.1.28 是一个较老但仍在部分遗留系统中使用的 PHP 框架版本。它本身不自带自动 XSS 防护机制，尤其在模板渲染、数据输出环节完全依赖开发者手动处理。存储型 XSS 在 Yii 1.1 中高发，根本原因不是框架“有漏洞”，而是开发者未对用户输入的持久化内容做上下文敏感的输出编码——即把从数据库读出的、未经处理的用户留言、评论、昵称等内容，直接 echo 到 HTML 页面里。
下面给出清晰、可落地的修复思路：
明确输出点，区分上下文再编码
存储型 XSS 的载荷（如 <script>alert(1)</script>）存于数据库，但真正触发是在页面渲染时。因此修复重点不在“入库时过滤”，而在于“输出时编码”。Yii 1.1 没有类似 Laravel 的 {{ }} 自动转义或 React 的 JSX 天然沙箱，所有 echo、CHtml::encode() 调用都需人工判断上下文：
-
HTML 文本内容（如
<div>xxx</div>）：必须用CHtml::encode($content)或htmlspecialchars($content, ENT_QUOTES, 'UTF-8') -
HTML 属性值（如
<input value="xxx">）：同样用CHtml::encode，但需确保属性用英文双引号包裹，避免被闭合绕过 -
JavaScript 字符串内（如
var msg = "xxx";）：不能只用htmlspecialchars，需用CJSON::encode($content)或自定义 JS 字符串转义函数（如将"→\"、→ <code>\u003c） -
URL 参数值（如
<a href="?q=xxx"></a>）：必须用urlencode($content)，而非 HTML 编码
⚠️ 注意：
CHtml::encode()仅适用于 HTML 内容上下文，误用于 JS 或 URL 场景会失效甚至引入新问题。
替换危险的原始输出方式
检查所有视图文件（.php 模板），定位以下高风险写法并替换：
- ❌
<?php echo $model->comment; ?>→ ✅<?php echo CHtml::encode($model->comment); ?> - ❌
<?php echo $this->widget('zii.widgets.CListView', array('dataProvider'=>$dp)); ?>→ 检查该 widget 内部是否自动转义，否则需重写或封装安全 wrapper - ❌ 直接拼接 JS 变量：
<script>var name = "<?php echo $user->name; ?>";</script>→ ✅ 改为var name = <?php echo CJSON::encode($user->name); ?>;
对富文本内容启用白名单清洗（非简单转义）
如果业务允许用户提交带格式的内容（如 <b>加粗</b>），CHtml::encode 会把所有标签干掉，不可取。此时应：
- 使用服务端 HTML 清洗库，如
HTMLPurifier（Yii 1.1 兼容） - 配置严格白名单：只允许
<p><br><b><i><ul><li></ul></i></b></p>等无脚本能力标签 - 禁用
onerror、onclick、javascript:等事件和伪协议 - 清洗后再用
CHtml::encode输出到页面（双重保险）
数据库字段不建议“入库过滤”
不要在保存前用 strip_tags() 或正则删 <script></script> —— 这属于输入验证误用。存储型 XSS 的修复主战场是输出，不是存储。入库过滤会丢失业务语义（比如用户昵称含 符号）、破坏数据完整性，且极易被绕过（大小写混淆、注释绕过等）。
补充纵深防御（降低被利用概率）
即使输出编码到位，也建议叠加以下措施：
- 设置
HttpOnly和SecureCookie，防止 XSS 窃取会话 - 添加响应头
X-Content-Type-Options: nosniff和X-XSS-Protection: 1; mode=block（虽现代浏览器已弃用后者，但旧 IE 仍有效） - 如条件允许，在 Nginx/Apache 层配置基础规则拦截明显恶意 payload（如
<script.></script.>），作为应急兜底
修复本质不是“堵住某个函数”，而是建立“所有用户控制的数据，必须经上下文适配的编码后再输出”的开发习惯。Yii 1.1 没有魔法防护，但只要守住输出这一关，存储型 XSS 就无法落地。
