谈到跨站脚本攻击(XSS),许多开发者的第一反应仍是紧盯标签。坦白说,仅靠过滤基本属于徒劳。真正的高危地带,其实是那些浏览器会自动解析执行的HTML属性——它们才是隐藏注入的重灾区。
判断是否存在XSS注入漏洞,最直接高效的方式就是:聚焦属性值,观察它能否被浏览器当作可执行上下文来解析。只要能,那里就是潜在的突破口。
哪些 HTML 属性会触发 JavaScript 执行
浏览器在解析以下属性时,只要值中包含了合法的JS逻辑,就会毫不犹豫地执行——不论它是否位于标签内部。
- 所有以
on开头的事件处理器:onerror、onclick、onload、onfocus等广为人知,但切勿忽视冷门事件,如oncut、oncontextmenu,攻击者尤其偏爱开发者不熟悉的属性进行突破。 href属性中的伪协议:若href的值以javascript:或vbscript:开头,便构成了天然的执行入口。href="javascript:fetch('/api/steal')"这种写法虽然经典,但至今仍然有效。src、srcdoc、data中的脚本协议:这几个属性同样支持javascript:协议。srcdoc尤为危险,因为它相当于内嵌一个完整的HTML页面,执行环境几乎不受限制。style属性中的 CSS 表达式:虽然现代浏览器已废弃,但老版本IE下的expression()或部分旧CSS解析器中的url(javascript:...),依然是挥之不去的遗留风险。
为什么 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="javascript:alert(1)"。注意现代浏览器可能拦截,但在某些旧版浏览器或特定CSP配置下,依然可能触发。 - 重点检查
srcdoc是否拼接了用户输入。如果代码中存在,几乎可以百分百确认存在注入点。 - 千万别忽视HTML实体的绕过能力。例如用
"替代英文双引号、&等,这些看似无害的编码往往能轻松绕过简单的正则过滤。
最容易被忽略的 DOM 型 XSS 位置
这类漏洞是真正的“隐形杀手”——不经服务器返回,完全由前端JavaScript动态拼接,审查时极易遗漏,因为它没有明显的网络请求痕迹。
location.hash或location.search直接被赋值给innerHTML、document.title、iframe.src。这种操作在SPA应用中极其常见,风险也极高。document.referrer被用于构造链接或显示来源页,未经编码就直接插入DOM。攻击者可以控制上一页的URL,从而注入恶意内容。- 从
localStorage或sessionStorage读取的数据,未经清洗就直接用于渲染。例如某些网站会保存用户上次的搜索关键词,然后显示在页面上,一旦关键词被注入恶意脚本,后果不堪设想。
真正难以防范的,从来都不是那些显眼的 标签,而是那些看似人畜无害、却在属性中悄悄执行脚本的组合。进行前端安全审查时,必须紧盯每一个动态拼接的点,反复自问:这个值最终会被安放到哪个属性里?那个属性,到底会不会被执行?
