ThinkPHP防止XSS攻击_htmlspecialchars过滤与转义【说明】

在ThinkPHP里写个htmlspecialchars()，看起来简单吧？但实际项目里，这函数失效的案例真不少。我先说个核心判断：ThinkPHP 不会自动帮你转义输出，htmlspecialchars() 必须显式调用，而且参数必须写全，否则 XSS 依然有机可乘。

为什么 htmlspecialchars() 在 ThinkPHP 中经常失效

不是函数没用，而是调用姿势错了——说白了就是没按规矩来。ThinkPHP 模板里写个 {$content}，默认是压根不转义的；控制器里直接 echo $input，更是裸奔式的输出。常见失效原因包括：

• 漏传第三个参数 'UTF-8'。别小看这一点，缺少它会导致多字节编码绕过（比如 %C0%AE%C0%AE/ 这种路径遍历+XSS 组合攻击）。
• 只用 ENT_COMPAT 或不传标志。单引号没转义，攻击者可以用 onerror="alert(1)" 这种招数轻松触发。
• 在模板中写 {$content|htmlspecialchars}。这种简写默认不带 ENT_QUOTES，本质上等价于 htmlspecialchars($content, ENT_COMPAT)，保护力度远远不够。
• 对富文本字段也套 htmlspecialchars()。结果呢？

  Hello

  直接显示成源码，而不是渲染后的段落，排版全毁了。

ThinkPHP 6 中正确调用 htmlspecialchars() 的位置和写法

TP6 已经彻底移除了 default_filter 配置，所有过滤必须显式、按需进行。几点关键建议：

• 模板层优先：用 {:htmlspecialchars($content, ENT_QUOTES | ENT_HTML5, 'UTF-8')}，这比 {$content|htmlspecialchars} 可靠得多。参数齐全，心里有底。
• 控制器层慎用：不要在 assign() 前统一转义，否则同一变量没法复用于 JS 变量或属性值。比如你要在模板里同时用于展示和赋值，统一转义反而束手束脚。
• API 输出 HTML 片段时（比如后台返回编辑器预览 HTML），不能只靠 htmlspecialchars()，必须走 HTMLPurifier 白名单清洗。不然直接输出带脚本的内容，风险太大。
• 如果用了 input('name') 获取参数，可以加第三参数： input('name', '', 'htmlspecialchars')。不过注意，这只适用于纯文本展示场景，不能替代输出点的最终校验。

htmlspecialchars() 不适用的 3 种典型输出上下文

它只管 HTML 文本节点和属性值，其他场景强行套用反而会引入漏洞。具体来说：

• 内联 Ja vaScript 字符串：比如 。这种场景必须用 json_encode($title, JSON_UNESCAPED_UNICODE | JSON_HEX_TAG | JSON_HEX_AMP)，而不是 htmlspecialchars()。
• HTML 属性未用引号包裹：比如
  。即便 $id 已经转义，缺了引号还是可以被空格截断，然后注入 onclick=alert(1) 这类攻击。
• 富文本内容输出：比如文章正文里包含 。htmlspecialchars() 会把整个标签变成文字，排版直接破坏。正确的做法是用 HTMLPurifier 清洗，只保留白名单内的标签。

真正容易被忽略的，是那些“看起来不像输出点”的地方：meta 标签的 content 属性、CSS 的 background-image: url()、甚至 SVG 的 xlink:href。这些上下文各有对应的编码和校验方式，不能图省事全扔给 htmlspecialchars()。不然呢？漏洞就是从这里钻进来的。