前端安全 — XSS攻击

原创已于 2022-08-16 10:37:14 修改 · 695 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#javascript

于 2022-04-13 19:39:47 首次发布

js 专栏收录该内容

14 篇文章

订阅专栏

XSS攻击的介绍

XSS漏洞的发生和修复

一个案例

注意特殊的HTML属性、JavaScript API

根据上下文采用不同的转义规则

随着互联网的高速发展，信息安全问题已经成为企业最为关注的焦点之一，而前端又是引发企业安全问题的高危据点。在移动互联网时代，前端人员除了传统的XSS、CSRF等安全问题之外，又时常遭遇网络劫持、非法调用Hybrid API等新型安全问题。当然，浏览器自身也在不断在进化和发展，不断引入CSP、Same- Site Cookies等新技术来增强安全性，但是仍存在很多潜在的威胁，这需要前端技术人员不断进行“查漏补缺”。
XSS，主要包括:
1. XSS攻击的介绍
2. XSS攻击的分类
3. XSS 攻击的预防和检测
4. XSS攻击的总结
5. XSS攻击案例

XSS攻击的介绍

在开始本文之前，我们先提出一个问题，请判断以下两个说法是否正确:
1. XSS防范是后端RD (研发人员)的责任，后端RD应该在所有用户提交数据的接口，对敏感字符进行转义，才能进行下一步操作。
2.所有要插入到页面上的数据，都要通过一个敏感字符过滤函数的转义，过滤掉通用的敏感字符后，就可以插入到页面中。
如果你还不能确定答案，那么可以带着这些问题向下看，我们将逐步拆解问题。

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="><script>alert( 'XSS' );</script>时，服务端会解析出请求参数keyword,得到"><script>alert( ' xss');</script>，拼接到HTML中返回给浏览器。形成了如下的HTML:

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

浏览器无法分辨出<script>alert( 'XSS' );</script>是恶意代码，因而将其执行。
这里不仅仅 div 的内容被注入了，而且 input 的 value 属性也被注入，alert 会弹出两次。
面对这种情况，我们应该如何进行防范呢?

其实，这只是浏览器将用户的输入当成了脚本进行了执行。那么只要告诉浏览器这段内容是文本就可以了。

聪明的小明很快找到了解决办法，将这个漏洞修复

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

escapeHTML()按照如下规则进行转义：

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

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

恶意代码都被转义，不再被浏览器执行，而且搜索词能够完美的在页面显示出来。
通过这个事件，小明学习到了如下知识:

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

注意特殊的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="<8= escapeHTML ( getParameter (" redirect_ _to"))8>">
跳转...
</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"))8>">
跳转...
</a>
else
<a href=" /404">
跳转...
</a>
}

通过这个事件，小明学习到了如下知识:

做了HTML转义，并不等于高枕无忧。
对于链接跳转，如<a href= "xxx.” 或location. href= "xxx"，要检验其内容，禁止以javascript: 开头的链接，和其他非法的scheme。

根据上下文采用不同的转义规则

某天，小明为了加快网页的加载速度，把一个数据通过JSON的方式内联到HTML中：

<script>
var initData = <% = data.toJSON() %>
</script>

插入JSON的地方不能使用 escapeHTML(),因为转义”后，JSON格式会被破坏