HTML动态拼接过程中的转义规范与防注入措施-html教程-PHP中文网

innerhtml赋值会立即触发html解析，未转义的、&、"、'将被当作语法符号处理，导致xss或dom错乱；必须对这5个字符实体编码，或优先使用textcontent显示纯文本。

html动态拼接过程中的转义规范与防注入措施

模板字符串拼接时，`innerHTML` 赋值为什么立刻执行脚本

浏览器对 innerHTML 的处理是“解析优先”：只要字符串里含未转义的 、<code>>、&、"、'，就会进入 HTML 解析流程，不管它来自模板字符串还是静态字面量。比如：
const user = '<img src="https://img.php.cn/?x-oss-process=image/resize,p_40" alt="HTML动态拼接过程中的转义规范与防注入措施">'; document.body.innerHTML = `<div>${user}</div>`; —— 这段代码等价于直接写入 HTML 文本，onerror 属性在插入瞬间就被绑定并可能触发。

常见错误现象：
• 用 fetch 拿到用户评论 JSON，直接 innerHTML = `<p>${data.bio}</p>`
• 表单提交后把返回的 message 字段不经处理塞进 innerHTML
• 在 Vue/React 中误用 v-html 或 dangerouslySetInnerHTML 渲染未净化字段

永远优先用 textContent：95% 的文本展示场景（用户名、提示、错误信息）完全不需要 HTML 解析
若必须用 innerHTML，转义函数必须覆盖全部 5 个字符： → <code>，<code>> → >，& → &，" → "，' → '
别手写正则替换，例如 .replace(/, ' 只处理了 <code>，漏掉 <code>& 就可能被绕过（<script></script> 可被浏览器二次解析）

`href` 和 `src` 属性中拼接用户数据的致命误区

只做 HTML 转义对 href、src 类属性无效。攻击者输入 javascript:alert(1) 或 data:text/html,<script>alert(1)</script>，即使 和 <code>> 已转义，协议部分仍会被执行。

实操建议：
• 前端动态设置：先校验协议白名单，再 URL 编码
function safeUrl(input) { const url = new URL(input, location.origin); if (!['http:', 'https:', '/'].includes(url.protocol)) throw new Error('Invalid protocol'); return encodeURIComponent(input); }
• 服务端渲染：确保变量类型为 template.URL（Go html/template）或显式调用 URL 编码函数（如 Node.js 的 encodeURIComponent）

绝对不要写 el.setAttribute('href', userInput) —— 这绕过所有模板转义逻辑
避免在模板中写 href="{{ url }}"，除非 url 是已校验且编码过的绝对路径
IE 对 ' 支持不一致，统一用双引号包裹属性，并转义 "

服务端模板引擎的转义陷阱：默认行为≠安全

Jinja2、EJS、Django 等模板默认开启转义，但开发者常因疏忽或性能考虑关闭它，导致高危输出。例如 EJS 中不转义，而才转义；Django 的 {{ value }} 转义，但 {{ value|safe }} 完全放行。

使用HTML,CSS,JavaScript开发Android应用程序英文文字pdf版附源文件

如果你了解HTML，CSS和JavaScript，您已经拥有所需的工具开发Android应用程序。本动手本书展示了如何使用这些开源web标准设计和建造，可适应任何Android设备的应用程序 - 无需使用Java。您将学习如何创建一个在您选择的平台的Android友好的网络应用程序，然后转换与自由PhoneGap框架到一个原生的Android应用程序。了解为什么设备无关的移动应用是未来的潮流，并开始构建应用程序，提供更

下载

关键检查点：
• 查看模板变量插值语法是否走转义路径（不是所有 {{ }} 都安全）
• 确认转义函数作用域：是仅 HTML 内容上下文，还是覆盖属性、URL、JS 等不同上下文
• PHP 的 htmlspecialchars($input, ENT_QUOTES, 'UTF-8') 必须带第三参数，否则非 UTF-8 编码下可被绕过

Node.js 推荐用 he.escape(input)，避免 entities 库（默认不转义单引号）
Python 必须用 html.escape(input, quote=True)，quote=True 确保双引号也被处理
Java 用 StringEscapeUtils.escapeHtml4(input)，别混用已废弃的 escapeHtml3

富文本场景下，为什么白名单过滤比转义更可靠

纯转义只能让内容“不可执行”，但无法还原合理格式（如加粗、换行）。一旦业务要求保留部分 HTML，就必须切换策略：从“阻止所有危险”转向“只允许明确可信”。此时 DOMPurify.sanitize() 是事实标准。

典型使用方式：
const clean = DOMPurify.sanitize(dirty, { ALLOWED_TAGS: ['p', 'br', 'strong', 'em'], ALLOWED_ATTR: ['href'] });
它自动剥离 <script></script>、onerror、javascript: 协议，并对 href 属性做协议校验。

别用黑名单（如删掉 <script></script>）—— 绕过方式太多（<img src="https://img.php.cn/?x-oss-process=image/resize,p_40" alt="HTML动态拼接过程中的转义规范与防注入措施">、Unicode 变体、注释干扰）
服务端净化更可靠：前端可被绕过，JSoup（Java）、bleach（Python）、sanitize-html（Node.js）应在入库前完成
即使用了 DOMPurify，也别把结果直接传给 eval 或 setTimeout(string) —— 它只管 HTML，不管 JS 执行上下文

真正容易被忽略的是上下文差异：同一个用户输入，在 textContent、双引号属性、href、onclick 里需要的处理方式完全不同。没分清上下文就套用一个转义函数，等于没防。