tp5.1 xss防护需显式过滤，default_filter仅对未指定参数的i()/input()生效，模板{$var}不自动转义，必须用{$var|html}或htmlspecialchars手动处理，htmlpurifier须严格配置白名单并禁用js能力。
TP5.1 的 XSS 防御不能靠“默认安全”，input() 或 I() 不加过滤参数就返回原始输入，模板里 {$var} 也不转义——这意味着只要用户提交 <script>alert(1)</script>，它就会执行。
TP5.1 的 default_filter 配置是否有效？
有效，但仅限于通过 I() 或 input() 获取数据且未显式传入过滤函数的场景。它不是“全局拦截”，而是“默认 fallback”。
-
default_filter在application/config.php中配置，例如'default_filter' => 'htmlspecialchars' - 该配置只影响
I('post.title')或input('title')这类**未指定第三参数**的调用 - 若写了
I('post.content', '', 'htmlpurifier')，则default_filter被完全忽略 - 务必显式指定
htmlspecialchars参数：'default_filter' => "htmlspecialchars, ENT_QUOTES, 'UTF-8'"，否则单引号不转义，onerror='alert(1)'仍可触发
HTMLPurifier 怎么集成才真正起作用？
别只装包、不配规则；HTMLPurifier 不是开箱即用的“安全开关”，白名单漏一条就可能被绕过。
- 执行
composer require ezyang/htmlpurifier安装后，在app/common.php中定义remove_xss()函数 - 禁止用
HTMLPurifier_Config::createDefault()—— 它默认放行太多危险标签和属性 - 必须显式设置白名单：
$cfg->set('HTML.Allowed', 'p,b,i,strong,a[href|title],img[src|alt|width|height]'); - 强制关闭 JS 相关能力：
$cfg->set('Core.RemoveScriptContents', true);和$cfg->set('HTML.SafeIframe', false); - 禁用危险协议：
$cfg->set('URI.AllowedSchemes', ['http', 'https', 'mailto']);，排除javascript:和data:
模板输出怎么防反射型 XSS？
模板层是最后一道防线，但 TP5.1 默认不开启自动转义，{$var} 等价于 <?php echo $var; ?> —— 危险直接裸奔。
- 所有用户输入变量输出，优先用
{$var|html}，它内部调用htmlspecialchars($var, ENT_QUOTES, 'UTF-8') - 避免
{$var|raw}或{$var|default='-'|html}这类写法：过滤器顺序错误会导致默认值未被转义 - 富文本内容（如 TinyMCE 提交）不能走
|html，必须先用remove_xss()处理，再在模板中用{:htmlspecialchars_decode($safe_html)} - 检查
template.default_filter配置项是否为'htmlspecialchars'，防止被覆盖成空字符串或html_entity_decode
哪些地方最容易漏掉 XSS 防护？
不是所有输出点都显眼，有些位置连开发者自己都忘了它是 HTML 渲染上下文。
-
<input value="{$title}">或<div title="{$desc}">：属性值需额外转义，<code>|html不够，要用{:htmlspecialchars($title, ENT_QUOTES | ENT_HTML5, 'UTF-8')} - JSON 接口返回的字段，前端若用
el.innerHTML = data.content渲染，后端必须预处理：$data['content'] = remove_xss($data['content']); - 直接读取数据库字段并输出（如日志列表、后台编辑回显），没走
input()就绕过了default_filter，必须手动过滤 - 使用
html_entity_decode()后又直接输出 —— 解码完等于把闭合标签和脚本全放出来了，解完必须立刻再过一遍htmlspecialchars()
