如何设置Yii框架以防御XSS攻击及输入输出过滤？

本文共计1076个文字，预计阅读时间需要5分钟。

《Yii框架的XSS防护并非开关即完事，核心在于输入校验++输出转义++富文本单行过滤三层动作缺失一层，漏掉任意一层，例如仅做Html::encode()但未处理富文本、或仅过滤输入但不处理输出，都可能导致被绕过。》

Html::encode() 什么时候够用，什么时候不够用

纯文本场景下（如用户名、标题、地址），Html::encode($userInput) 是最轻量也最安全的选择：它把 变成 <code><，script 标签直接失效，连解析机会都不给。

但它在以下情况会出问题：

• 你允许用户提交带格式的内容（比如商品详情页的编辑器输出），Html::encode() 会把所有 <p></p>、<strong></strong> 全部转义成乱码，页面无法渲染
• 你把用户输入拼进 JavaScript 字符串里，例如 var desc = "= Html::encode($desc) ?>"; —— 这种写法仍可能因引号闭合失败导致 XSS
• 你在 JS 中用 innerHTML 或 document.write() 插入内容，Html::encode() 对 DOM 层面的注入无效

HtmlPurifier 必须配白名单，不能只调用 process()

HtmlPurifier::process($html) 默认行为是保守过滤，但 Yii 不自带默认配置，直接调用等于裸奔——它不会自动禁掉 onerror、javascript:、data:text/html 等高危属性和协议。

必须显式配置白名单，例如在组件配置中：

['HTML.Allowed' => 'p,strong,em,u,ol,ul,li,a[href|title],img[src|alt]']

关键点：

• a[href] 要限制协议，推荐写成 a[href|title|rel] 并在后端校验 href 是否以 http:// 或 https:// 开头
• 禁止启用 HTML.SafeIframe，除非你真需要嵌第三方视频且已严格校验 src 域名白名单
• 别在列表页、搜索页等高频接口里每次调用 HtmlPurifier::process()，开销大；建议缓存净化结果，或用 Redis 存 $key = 'purified_' . md5($rawHtml)

输出到 JS 变量或属性时的特殊处理

用户数据进 JS 环境比进 HTML 更危险，因为没标签边界，一个未闭合的引号就能逃逸。

正确做法不是靠 Html::encode()，而是：

• 用 json_encode($value, JSON_UNESCAPED_UNICODE | JSON_HEX_TAG | JSON_HEX_AMP) 包裹后再插入 JS 字符串，确保双引号、反斜杠、<、& 全被转义
• 绝对避免 document.getElementById('x').innerHTML = '= $userHtml ?>'; 这类写法；改用 textContent 或先用 HtmlPurifier 净化再插入
• 如果必须动态生成 script 标签（如埋点），用 CSP 的 nonce 或 hash 控制执行权限，而不是拼字符串

容易被忽略的三个盲区

很多项目在测试环境看不出问题，上线后被扫出 XSS，往往栽在这三处：

• URL 参数里的 redirect_url、next 类跳转字段，后端取值后直接 header("Location: $url") 或前端 window.location.href = url —— 必须校验是否为站内路径，禁止开放协议（如 javascript:、data:）
• Cookie 中的 user_name 或 avatar_url，被 JS 读取后直接插入 DOM —— 即使后端已转义，JS 层仍需二次处理
• 后台导出 Excel 或 CSV 时，把用户输入字段原样写入文件，再被 Excel 解析执行宏或公式 —— 这属于“XSS 衍生攻击”，得在导出前对字段做 str_replace(['=', '+', '-', '@'], '', $value) 过滤

真正难防的不是 <script>，而是那些看起来“合法”的字符组合。只要数据流经用户可控输入 → 输出到浏览器上下文，就必须按上下文类型选对应防护手段，不能复用同一套逻辑。