HTML注入本质是未转义的用户输入被浏览器解析为HTML结构，关键在innerHTML、document.write等API或服务端模板拼接时缺失转义，导致标签/事件执行；它与XSS现象重合但根源不同，防御须坚持输出编码与上下文隔离。
HTML注入漏洞的本质是用户输入被当成了HTML结构
HTML注入不是XSS的别名，也不是后端SQL注入的前端表现。它指用户提交的内容（比如表单值、URL参数、富文本）未经转义，直接拼进HTML字符串里，导致浏览器解析出新标签或属性。例如：document.getElementById('content').innerHTML = userInput，只要userInput是<img src=x onerror=alert(1)>，就会触发执行——这和XSS现象重合，但根源在DOM操作方式，而非脚本本身。
关键判断点：看输出是否用了innerHTML、document.write()、insertAdjacentHTML()这类会解析HTML的API；或者服务端模板里写了<div>${userInput}</div>且没启用默认转义。
检测时优先盯住这三类反射点
不是所有输入都会进HTML上下文，要聚焦最可能“原样回显”的位置：
- 搜索关键词回显：URL中
?q=test→ 页面<h2>搜索结果：test</h2>，若test未转义，就可插</h2><script>alert(1)</script> - 错误提示页：如
/login?error=Invalid+username→<p class="error">Invalid username</p>，把error改成<svg/onload=alert(1)>试试 - 富文本编辑器内容展示：后端返回的HTML片段（如评论区）若直接
v-html或dangerouslySetInnerHTML渲染，且过滤只删<script>却放行<img onerror>，就是高危点
绕过常见过滤的实操思路
很多系统加了简单黑名单（比如删掉script、onerror），但浏览器解析有容错性和歧义性，得用更底层的方式试探：
立即学习“前端免费学习笔记（深入）”；
— 用大小写混淆：<Img Src=x OnError=alert(1)> 绕过纯小写匹配
— 插入注释分割：<img <!-- -->src=x <!-- -->onerror=alert(1)> 干扰正则匹配边界
— 利用SVG上下文：<svg><script>alert(1)</script></svg> 或 <svg/onload=alert(1)>，部分过滤器不处理SVG命名空间
— 测试javascript:伪协议：<a href="javascript:alert(1)">click</a>，尤其在href或src属性中
注意：不要只依赖<script>测试，现代WAF对这个拦截很严，真正容易漏的是事件属性和自闭合标签里的执行上下文。
服务端模板注入和前端DOM注入要分开验证
同样是${userInput}，风险等级天差地别：
— 如果是FreeMarker/Thymeleaf等服务端模板，且userInput被拼进模板字符串（如template = "<div>" + userInput + "</div>"），那可能触发模板引擎语法执行，比如${7*7}直接算出49，甚至${T(java.lang.Runtime).getRuntime().exec('calc')}（取决于引擎配置）
— 如果是前端框架（React/Vue），{userInput}默认走textContent，安全；但显式写v-html="userInput"或dangerouslySetInnerHTML，就退化成DOM注入，必须人工确认是否做过滤
所以看到模板语法，第一反应不是测XSS，而是查userInput有没有被当成代码执行——比如在FreeMarker里搜?eval、?interpret，在art-template里查{{@data}}或{{= data}}。
最容易被忽略的是：HTML注入常和CSP策略形成“虚假安全感”。即使页面启用了Content-Security-Policy: script-src 'self'，只要攻击者能注入<img src=x onerror=...>，依然能执行任意JS——因为onerror属于内联事件处理器，不受script-src限制。真正起作用的是default-src 'none'配合unsafe-inline禁用，但这又会影响正常功能。所以防御核心永远是：输入不信任，输出必转义，上下文必隔离。
