HTML代码安全审查中如何识别利用属性隐藏注入

聊到XSS注入，很多人第一反应还是盯着标签不放。说句实在话，单纯过滤标签基本是在做无用功。真正危险的地方，是那些浏览器会自动解析执行的HTML属性——它们才是隐藏注入的重灾区。

判断一个注入是否存在，最直接有效的办法就是：盯着属性值，看它能不能被浏览器当成可执行上下文来解析。只要能，那就是一个潜在的突破口。

哪些 HTML 属性会触发 Ja vaScript 执行

浏览器在解析以下属性时，只要值里包含着合法的JS逻辑，就会毫不犹豫地执行——不管它是不是在标签里面。

• 所有以 on 开头的事件处理器：onerror、onclick、onload、onfocus 是常见的，但千万别忽略那些冷门的，例如 oncut、oncontextmenu，攻击者特别喜欢挑程序员不熟悉的去下手。
• href 属性中的伪协议：如果 href 的值以 ja vascript: 或 vbscript: 开头，那就是一个天然的执行入口。href="ja vascript:fetch('/api/steal')" 这种写法，虽然老套，但依然有效。
• src、srcdoc、data 中的脚本协议：这几个属性同样能接受 ja vascript: 协议。srcdoc 尤其危险，因为它等价于内嵌一个完整的HTML页面，执行环境几乎不受限制。
• style 属性中的 CSS 表达式：虽然现代浏览器已经废弃了，但老版本IE下的 expression() 或者部分旧CSS解析器中的 url(ja vascript:...)，依然是一段挥之不去的阴影。

为什么 innerHTML 比 textContent 危险得多

代码审查时，只要看到 element.innerHTML = userInput 这样的写法，基本可以直接判定高危了。原因很简单：innerHTML 会把字符串当成HTML来解析，并执行其中所有能执行的脚本；而 textContent 只是把内容当成纯文本渲染出来，不会触发任何解析逻辑。

• 同等级的高风险操作还包括：document.write()、insertAdjacentHTML()，以及前端框架中那些主动绕过默认渲染路径的API，比如Vue的 v-html 和React的 dangerouslySetInnerHTML。
• 框架自带的自动转义机制，只覆盖默认的渲染路径。一旦你手动调用上述API，就等于主动放弃了这层防护。
• 警惕那种“看起来只是填个value”的直觉陷阱。比如 ，攻击者完全可以闭合引号，完成注入。

如何快速验证属性注入是否生效

验证环节完全不需要等后端响应，用浏览器的开发者工具直接改DOM，或者构造URL参数测试，效率最高。

• 针对URL参数反射场景，用payload：" onfocus="alert(1)。观察页面是否生成类似 这样的结构。
• 对于src类属性，尝试 src="ja vascript:alert(1)"。注意，现代浏览器可能会拦截，但在某些旧版浏览器或特定的CSP配置下，依然能触发。
• 重点检查 srcdoc 是否拼接了用户输入。如果代码中存在 ，几乎可以百分百确认存在注入点。
• 千万别忽视HTML实体的绕过能力。比如用 " 替代英文双引号、& 等，这些看似无害的编码，往往能轻松绕过简单的正则过滤。

最容易被忽略的 DOM 型 XSS 位置

这类漏洞是真正的“隐形杀手”——不经过服务器返回，全靠前端Ja vaScript动态拼接，审查时极易漏掉，因为它没有明显的网络请求痕迹。

• location.hash 或 location.search 直接被赋值给 innerHTML、document.title、iframe.src。这类操作在SPA应用里极其常见，风险也极高。
• document.referrer 被用于构造链接或显示来源页，未经编码就直接插入DOM。攻击者可以控制上一页的URL，从而注入恶意内容。
• 从 localStorage 或 sessionStorage 读取的数据，未经清洗就直接用于渲染。比如某些网站会保存用户上次的搜索关键词，然后显示在页面上，一旦关键词被注入恶意脚本，后果不堪设想。

真正难防的，从来都不是那些显眼的 标签，而是那些看起来人畜无害、却在属性里悄悄执行脚本的组合。审查代码的时候，得盯着每一个动态拼接的点，心里反复问自己：这个值最终会被安放到哪个属性里？那个属性，到底会不会被执行？