经过了转义函数的处理后,最终浏览器接收到的响应为:
<input type="text" value=""><script>alert('XSS');</script>"><button>搜索</button>
<div>
您搜索的关键词是:"><script>alert('XSS');</script>
</div>
恶意代码都被转义,不再被浏览器执行,而且搜索词能够完美的在页面显示出来。
通过这个事件,小明学习到了如下知识:
通常页面中包含的用户输入内容都在固定的容器或者属性内,以文本的形式展示。
攻击者利用这些页面的用户输入片段,拼接特殊格式的字符串,突破原有位置的限制,形成了代码片段。
攻击者通过在目标网站上注入脚本,使之在用户的浏览器上运行,从而引发潜在风险。
通过 HTML 转义,可以防止 XSS 攻击。[事情当然没有这么简单啦!请继续往下看]。
注意特殊的 HTML 属性、JavaScript API
自从上次事件之后,小明会小心的把插入到页面中的数据进行转义。而且他还发现了大部分模板都带有的转义配置,让所有插入到页面中的数据都默认进行转义。这样就不怕不小心漏掉未转义的变量啦,于是小明的工作又渐渐变得轻松起来。
但是,作为导演的我,不可能让小明这么简单、开心地改 Bug 。
不久,小明又收到安全组的神秘链接:?redirect_to=javascript:alert(\'XSS\')。小明不敢大意,赶忙点开页面。然而,页面并没有自动弹出万恶的“XSS”。
小明打开对应页面的源码,发现有以下内容:
<a href="<%= escapeHTML(getParameter("redirect_to")) %>">跳转...</a>这段代码,当攻击 URL 为 ?redirect_to=javascript:alert(\'XSS\'),服务端响应就成了:
<a href="javascript:alert('XSS')">跳转...</a>虽然代码不会立即执行,但一旦用户点击 a 标签时,浏览器会就会弹出“XSS”。
可恶,又失策了...
在这里,用户的数据并没有在位置上突破我们的限制,仍然是正确的 href 属性。但其内容并不是我们所预期的类型。
原来不仅仅是特殊字符,连 javascript: 这样的字符串如果出现在特定的位置也会引发 XSS 攻击。
小明眉头一皱,想到了解决办法:
// 禁止 URL 以 "javascript:" 开头xss = getParameter("redirect_to").startsWith(\'javascript:\');
if (!xss) {
<a href="<%= escapeHTML(getParameter("redirect_to"))%>">
跳转...
</a>
} else {
<a href="http://www.likecs.com/404">
跳转...
</a>
}
只要 URL 的开头不是 javascript:,就安全了吧?
安全组随手又扔了一个连接:?redirect_to=jAvascRipt:alert(\'XSS\')
这也能执行?.....好吧,浏览器就是这么强大。
小明欲哭无泪,在判断 URL 开头是否为 javascript: 时,先把用户输入转成了小写,然后再进行比对。
不过,所谓“道高一尺,魔高一丈”。面对小明的防护策略,安全组就构造了这样一个连接:
?redirect_to=%20javascript:alert(\'XSS\')%20javascript:alert(\'XSS\') 经过 URL 解析后变成javascript:alert(\'XSS\'),这个字符串以空格开头。这样攻击者可以绕过后端的关键词规则,又成功的完成了注入。
最终,小明选择了白名单的方法,彻底解决了这个漏洞:
// 根据项目情况进行过滤,禁止掉 "javascript:" 链接、非法 scheme 等allowSchemes = ["http", "https"];
valid = isValid(getParameter("redirect_to"), allowSchemes);
if (valid) {
<a href="<%= escapeHTML(getParameter("redirect_to"))%>">
跳转...
</a>
} else {
<a href="http://www.likecs.com/404">
跳转...
</a>
}
通过这个事件,小明学习到了如下知识:
做了 HTML 转义,并不等于高枕无忧。