网站总被XSS攻击怎么办？PHP输出编码怎么做最安全-php教程-PHP中文网

htmlspecialchars()必须显式传参ent_quotes|ent_html5和'utf-8'：ent_quotes确保单双引号均转义防属性逃逸，ent_html5兼容html5实体如'，'utf-8防止多字节截断绕过。

网站总被xss攻击怎么办？php输出编码怎么做最安全

htmlspecialchars() 是 PHP 输出到 HTML 文本或属性时最直接、最不可绕过的安全手段，但只用它还不够——漏掉上下文、参数写错、或塞进 JS 里就等于没防。

为什么 htmlspecialchars() 必须带 ENT_QUOTES | ENT_HTML5 参数？

默认调用 htmlspecialchars($str) 只转义双引号，而单引号属性（比如 <input value="<script>">）会直接逃逸。浏览器解析时，单引号内的 <code><script></script> 不被当成标签，但 onerror='alert(1)' 这类事件仍能执行。

必须显式传参：htmlspecialchars($str, ENT_QUOTES | ENT_HTML5, 'UTF-8')
ENT_QUOTES 确保单双引号都转义，堵住属性值注入口
ENT_HTML5 支持 HTML5 实体（如 '），避免旧模式下某些字符被跳过
'UTF-8' 强制编码声明，防止多字节截断绕过（如 %C0%AE%C0%AE/ 路径遍历配合 XSS）

输出到 JavaScript 字符串时，htmlspecialchars() 完全无效

写成 <script>var msg = "<?php echo $user; ?>";</script>，哪怕 $user 经过 htmlspecialchars()，只要里面含 " 或 \，JS 解析器就会提前截断字符串并执行后续代码。

正确做法：用 json_encode($user, JSON_HEX_TAG | JSON_HEX_AMP | JSON_HEX_APOS | JSON_HEX_QUOT)
外层 JS 字符串必须用双引号包裹，且不额外加引号：var msg = <?php echo json_encode($user, ...); ?>;
禁用 addslashes() 或手写 str_replace() —— JS 引擎不认这些，\u0022 依然可触发
data-* 属性同理危险，也得走 json_encode()，不能图省事用 htmlspecialchars()

富文本场景不能靠 htmlspecialchars()，白名单才是底线

论坛、商品描述、后台编辑器要保留 <p></p><div class="aritcle_card flexRow artxards"> <div class="artcardd flexRow"> <a class="aritcle_card_img" rel="nofollow" href="/xiazai/gongju/2229" title="PHP 8.5.5"><img src="https://img.php.cn/upload/manual/001/246/273/6a03d2f895963707.jpeg" alt="PHP 8.5.5" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a> <div class="aritcle_card_info flexColumn"> <a rel="nofollow" href="/xiazai/gongju/2229" title="PHP 8.5.5" class="overflowclass">PHP 8.5.5</a> <p class="overflowclass">PHP 8.5.5 是 PHP 8.5 分支的维护更新版本。该版本延续了“小步快跑”的迭代逻辑，通过深度错误修复、底层性能微调以及安全加固，旨在为开发者提供一个更健壮、更高效的运行环境。该版本严格遵守语义化版本规范，不包含破坏性变更。</p> </div> <a rel="nofollow" href="/xiazai/gongju/2229" title="PHP 8.5.5" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span> </a> </div> </div>、<img src>，但又得拦住 <script></script>、onerror、javascript:。这时候 htmlspecialchars() 把所有标签都干掉，strip_tags() 又拦不住注释混淆（）或大小写变形（<script></script>）。

必须用 HTMLPurifier（通过 Composer 安装），它基于 DOM 解析 + 白名单策略，严格按 W3C 规范过滤
配置示例：只允许 <p></p>、<strong></strong>、<a href></a>，且 href 必须以 http:// 或 https:// 开头
别信“正则删 script 标签”或 “DOMDocument + 手动遍历” —— 嵌套、实体编码、Unicode 变体极易漏判
前端编辑器（如 CKEditor）的配置可被绕过，后端必须独立做净化

CSP 和响应头不是补丁，是最后一道兜底

哪怕某处 echo 漏了转义，Content-Security-Policy 也能阻止大部分内联脚本执行。但它不是万能的，配置错误反而会让页面崩掉。

基础 CSP 示例：header("Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline';");
'unsafe-inline' 先留着过渡，长期目标应移除，改用 nonce 或 hash
必须配 X-Content-Type-Options: nosniff，否则攻击者可能上传伪装成 text/plain 的 JS 文件绕过 MIME 检查
X-XSS-Protection 在现代浏览器中已弃用，优先保证 CSP 和正确转义

复杂点在于：每个输出位置都是独立战场。同一变量在 <div> 里、<code>value= 里、<script></script> 里、style= 里，要用完全不同的处理方式。最容易被忽略的是 data-* 属性和内联事件绑定 —— 它们看起来像 HTML，实则运行在 JS 上下文里。