如何避免XSS攻击

前言

XSS 攻击：即跨站脚本攻击，它是 Web 程序中常见的漏洞。原理是攻击者往 Web 页面里插入恶意的脚本代码（css 代码、Javascript 代码等），当用户浏览该页面时，嵌入其中的脚本代码会被执行，从而达到恶意攻击用户的目的，如盗取用户 cookie、破坏页面结构、重定向到其他网站等。

预防：

1、获取用户的输入，不用innerHtml,用innerText.
2、预防 XSS 的核心是必须对输入的数据做过滤处理。对用户的输入进行过滤，如对& < > " ’ /等进行转义。

XSS案例

 说明：这里用一个XSS案例更好的说明XSS攻击，重点感谢美团技术团队的案例支持。   

某天，公司需要一个搜索页面，根据 URL 参数决定关键词的内容。小明很快把页面写好并且上线。代码如下：

<input type="text" value="<%= getParameter("keyword") %>">
<button>搜索</button>
<div>
  您搜索的关键词是：<%= getParameter("keyword") %>
</div>

然而，在上线后不久，小明就接到了安全组发来的一个神秘链接：

http://xxx/search?keyword="><script>alert('XSS');</script>

小明带着一种不祥的预感点开了这个链接[请勿模仿，确认安全的链接才能点开]。果然，页面中弹出了写着"XSS"的对话框。
可恶，中招了！小明眉头一皱，发现了其中的奥秘：

当浏览器请求 http://xxx/search?keyword=">，拼接到 HTML 中返回给浏览器。形成了如下的 HTML：

<input type="text" value=""><script>alert('XSS');</script>">
<button>搜索</button>
<div>
  您搜索的关键词是："><script>alert('XSS');</script>
</div>

浏览器无法分辨出 是恶意代码，因而将其执行。
这里不仅仅 div 的内容被注入了，而且 input 的 value 属性也被注入， alert 会弹出两次。
面对这种情况，我们应该如何进行防范呢？
其实，这只是浏览器把用户的输入当成了脚本进行了执行。那么只要告诉浏览器这段内容是文本就可以了。

聪明的小明很快找到解决方法，把这个漏洞修复

<input type="text" value="<%= escapeHTML(getParameter("keyword")) %>">
<button>搜索</button>
<div>
  您搜索的关键词是：<%= escapeHTML(getParameter("keyword")) %>
</div>

经过了转义函数的处理后，最终浏览器接收到的响应为：

<input type="text" value="&quot;&gt;&lt;script&gt;alert(&#x27;XSS&#x27;);&lt;&#x2F;script&gt;">
<button>搜索</button>
<div>
  您搜索的关键词是：&quot;&gt;&lt;script&gt;alert(&#x27;XSS&#x27;);&lt;&#x2F;script&gt;
</div>

通过这个事件，学习到了如下知识：

 1.通常页面中包含的用户输入内容都在固定的容器或者属性内，以文本的形式展示。
 2.攻击者利用这些页面的用户输入片段，拼接特殊格式的字符串，突破原有位置的限制，形成了代码片段。 
 3.攻击者通过在目标网站上注入脚本，使之在用户的浏览器上运行，从而引发潜在风险。
 4. 通过 HTML 转义，可以防止 XSS 攻击。<span style="color:red">[事情当然没有这么简单啦！请继续往下看]</span>。

注意特殊的 HTML 属性、JavaScript API

自从上次事件之后，小明会小心的把插入到页面中的数据进行转义。而且他还发现了大部分模板都带有的转义配置，让所有插入到页面中的数据都默认进行转义。这样就不怕不小心漏掉未转义的变量啦，于是小明的工作又渐渐变得轻松起来。
但是，作为导演的我，不可能让小明这么简单、开心地改 Bug

不久，小明又收到安全组的神秘链接：

http://xxx/?redirect_to=javascript:alert(‘XSS’)。小明不敢大意，赶忙点开页面。然而，页面并没有自动弹出万恶的“XSS”。

小明打开对应页面的源码，发现有以下内容：

<a href="<%= escapeHTML(getParameter("redirect_to")) %>">跳转...</a>

这段代码，当攻击 URL 为 http://xxx/?redirect_to=javascript:alert(‘XSS’)，服务端响应就成了：

<a href="javascript:alert(&#x27;XSS&#x27;)">跳转...</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="/404">
    跳转...
  </a>
}

只要 URL 的开头不是 javascript:，就安全了吧？

安全组随手又扔了一个连接：http://xxx/?redirect_to=jAvascRipt:alert(‘XSS’)
，在判断 URL 开头是否为 javascript: 时，先把用户输入转成了小写，然后再进行比对。

不过，所谓“道高一尺，魔高一丈”。面对小明的防护策略，安全组就构造了这样一个连接：

http://xxx/?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="/404">
    跳转...
  </a>
}

通过这个事件，小明学习到了如下知识：
1、做了 HTML 转义，并不等于高枕无忧。
2、对于链接跳转，如 <a href=“xxx” 或 location.href=“xxx”，要检验其内容，禁止以 javascript: 开头的链接，和其他非法的 scheme。

	作者：狂欢