使用owasp forHTMLAttribute编码后仍存在XSS漏洞问题咨询

问题成因 #

你使用的OWASP forHtmlAttribute 函数的防护范围仅针对HTML属性注入场景，作用是转义<>"'&等HTML特殊字符，避免攻击者通过闭合引号插入额外HTML属性。但它无法校验属性值本身的合法性：
javascript: 属于浏览器支持的伪协议，只要出现在href属性值的开头，不需要闭合任何引号，用户点击标签时浏览器就会直接执行后续的JavaScript代码，完全绕开了HTML属性转义的防护逻辑。

你遇到的攻击Payload逻辑非常简单：攻击者直接将backUrl参数设置为javascript:开头的恶意代码，转义函数不会处理javascript相关字符，所以恶意代码会原样填入href属性触发执行。

硬编码主机名方案的原理 #

在URL前硬编码主机名的核心作用是强制链接只能是本站路径，从根源上消除伪协议生效的可能性：
假设你的站点域名是https://example.com，修改代码后生成的href属性结构为https://example.com${转义后的backUrl}，就算攻击者传入javascript:eval(xxx)的Payload，最终生成的完整链接为https://example.comjavascript:eval(xxx)，这是一个普通的本站相对路径，点击后只会跳转404，完全不会触发JS执行。

同时这个方案也能避免攻击者传入第三方站点链接造成钓鱼跳转的风险。

更稳妥的排查/优化方向 #

• 不要仅依赖HTML属性转义防护链接类的注入风险，所有用户可控参数填入href、src、form action等属性时，都要先做格式校验：优先只允许/开头的本站相对路径，不符合规则的参数直接替换为站点首页路径。
• 如果业务确实需要支持跳转到外部站点，必须额外加域名白名单校验，禁止无限制的任意跳转。
• 排查全站所有类似的返回跳转逻辑，统一做规则校验，避免遗漏其他同类风险点。

内容的提问来源于stack exchange，提问作者Sébastien Sutterlin