网络安全初探-XSS攻击方式&&防御手段

今天药忘吃喽~ 2023-01-22 09:58 254阅读 0赞

### 文章目录 ###

*  一、什么是 XSS
 *  二、XSS注入的方法
 *  三、XSS 攻击的分类
 *   *  1.反射型XSS
     *  2.存储型XSS
     *  3.DOM型XSS
 *  四、XSS 攻击的预防
 *   *  1.预防 DOM 型 XSS 攻击
     *  2.输入过滤
     *  3.拼接HTML时对其进行转义
     *  4.Content Security Policy
     *  5.其他安全措施

# 一、什么是 XSS #

> Cross-Site Scripting（跨站脚本攻击）简称  
> XSS，是一种代码注入攻击。攻击者通过在目标网站上注入恶意脚本，使之在用户的浏览器上运行。利用这些恶意脚本，攻击者可获取用户的敏感信息如  
> Cookie、SessionID 等，进而危害数据安全。 为了和 CSS 区分，这里把攻击的第一个字母改成了 X，于是叫做 XSS。

XSS 的本质是：恶意代码未经过滤，与网站正常的代码混在一起；浏览器无法分辨哪些脚本是可信的，导致恶意脚本被执行。

# 二、XSS注入的方法 #

*  在 HTML 中内嵌的文本中，恶意内容以 script 标签形成注入。
 *  在内联的 JavaScript 中，拼接的数据突破了原本的限制（字符串，变量，方法名等）。
 *  在标签属性中，恶意内容包含引号，从而突破属性值的限制，注入其他属性或者标签。
 *  在标签的 href、src 等属性中，包含 javascript: 等可执行代码。
 *  在 onload、onerror、onclick 等事件中，注入不受控制代码。
 *  在 style 属性和标签中，包含类似 background-image:url(“javascript:…”); 的代码（新版本浏览器已经可以防范）。
 *  在 style 属性和标签中，包含类似 expression(…) 的 CSS 表达式代码（新版本浏览器已经可以防范）。

如果开发者没有将用户输入的文本进行合适的过滤，就贸然插入到 HTML 中，这很容易造成注入漏洞。攻击者可以利用漏洞，构造出恶意的代码指令，进而利用恶意代码危害数据安全。

# 三、XSS 攻击的分类 #

## 1.反射型XSS ##

反射型XSS只是简单的把用户输入的数据从服务器反射给用户浏览器，要利用这个漏洞，攻击者必须以某种方式诱导用户访问一个精心设计的URL（恶意链接），才能实施攻击。

**攻击步骤**：

1.  攻击者构造出特殊的 URL，其中包含恶意代码。
2.  用户打开带有恶意代码的 URL 时，网站服务端将恶意代码从 URL 中取出，拼接在 HTML 中返回给浏览器。
3.  用户浏览器接收到响应后解析执行，混在其中的恶意代码也被执行。
4.  恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。

反射型 XSS 漏洞常见于通过 URL 传递参数的功能，如网站搜索、跳转等。

**成因:**  
当用户的输入或者一些用户可控参数未经处理地输出到页面上，就容易产生XSS漏洞。

## 2.存储型XSS ##

存储型（或 HTML 注入型/持久型）XSS 攻击最常发生在由社区内容驱动的网站或 Web 邮件网站，不需要特制的链接来执行。黑客仅仅需要提交 XSS 漏洞利用代码（反射型XSS通常只在url中）到一个网站上其他用户可能访问的地方。这些地区可能是博客评论，用户评论，留言板，聊天室，HTML 电子邮件，wikis，和其他的许多地方。一旦用户访问受感染的页，执行是自动的。

**攻击步骤**：

1.  攻击者将恶意代码提交到目标网站的数据库中。
2.  用户打开目标网站时，网站服务端将恶意代码从数据库取出，拼接在 HTML 中返回给浏览器。
3.  用户浏览器接收到响应后解析执行，混在其中的恶意代码也被执行。
4.  恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。

常见于带有用户保存数据的网站功能，如论坛发帖、商品评论、用户私信等。

**成因**：  
存储型XSS漏洞的成因与反射型的根源类似，不同的是恶意代码会被保存在服务器中，导致其它用户（前端）和管理员（前后端）在访问资源时执行了恶意代码，用户访问服务器-跨站链接-返回跨站代码。

## 3.DOM型XSS ##

通过修改页面的DOM节点形成的XSS。

**攻击步骤**

1.  攻击者构造出特殊的 URL，其中包含恶意代码。
2.  用户打开带有恶意代码的 URL。
3.  用户浏览器接收到响应后解析执行，前端 JavaScript 取出 URL 中的恶意代码并执行。
4.  恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。

**示例**

//url: XXXX/DOM-XSS.html#alert(1)
    <html>
    	<head></head>
    	<body>
    		<script type="text/javascript">
    		var text = location.hash.substr(1);
    		eval(text);
    		</script>
    	</body>
    </html>

**成因**  
前端 JavaScript 代码本身不够严谨，把不可信的数据当作代码执行了。

# 四、XSS 攻击的预防 #

在处理输入时，以下内容都不可信：

*  来自用户的 UGC 信息
 *  来自第三方的链接
 *  URL 参数
 *  POST 参数
 *  Referer （可能来自不可信的来源）
 *  Cookie （可能来自其他子域注入）

## 1.预防 DOM 型 XSS 攻击 ##

DOM 型 XSS 攻击，实际上就是网站前端 JavaScript 代码本身不够严谨，把不可信的数据当作代码执行了。

在使用 .innerHTML、.outerHTML、document.write() 时要特别小心，不要把不可信的数据作为 HTML 插到页面上，尽量使用 .textContent、.setAttribute() ，innerHTML会将文本解析为HTML。

DOM 中的内联事件监听器，如 location、onclick、onerror、onload、onmouseover 等， 标签的href属性，JavaScript 的eval()、setTimeout()、setInterval()等，都能把字符串作为代码运行。如果不可信的数据拼接到字符串中传递给这些 API，很容易 产生安全隐患，请务必避免。

## 2.输入过滤 ##

1.  在用户提交时，由前端过滤输入，然后提交到后端。但是一旦攻击者绕过前端过滤，直接构造请求，就可以提交恶意代码了。
2.  后端在写入数据库前，对输入进行过滤，然后把“安全的”内容，返回给前端。

存在的问题：

一个正常的用户输入了 5 < 7 这个内容，在写入数据库前，被转义，变成了 5 $lt; 7。 问题是：在提交阶段，我们并不确定内容要输出到哪里。
    - 用户的输入内容可能同时提供给前端和客户端，而一旦经过了 escapeHTML()，客户端显示的内容就变成了乱码( 5 $lt;7 )。
    - 在前端中，不同的位置所需的编码也不同。 当 5 $lt;7 作为 HTML 拼接页面时，可以正常显示：5 < 7

**对于不受信任的输入，都应该限定一个合理的长度。虽然无法完全防止 XSS 发生，但可以增加 XSS 攻击的难度。**

## 3.拼接HTML时对其进行转义 ##

如果拼接 HTML 是必要的，就需要采用合适的转义库，对 HTML 模板各处插入点进行充分的转义。  
常用的模板引擎，如 doT.js、ejs、FreeMarker 等，对于 HTML 转义通常只有一个规则，就是把 & < > " ’ / 这几个字符转义掉，确 实能起到一定的 XSS 防护作用，但并不完善。

## 4.Content Security Policy ##

严格的安全策略(CSP) 在 XSS 的防范中可以起到以下的作用：

禁止加载外域代码，防止复杂的攻击逻辑。  
禁止外域提交，网站被攻击后，用户的数据不会泄露到外域。  
禁止内联脚本执行（规则较严格，目前发现 GitHub 使用）。  
禁止未授权的脚本执行（新特性，Google Map 移动版在使用）。  
合理使用上报可以及时发现 XSS，利于尽快修复问题。

## 5.其他安全措施 ##

*  HTTP-only Cookie: 禁止 JavaScript 读取某些敏感 Cookie，攻击者完成 XSS 注入后也无法窃取此 Cookie。
 *  验证码：防止脚本冒充用户提交危险操作。

[本文链接https://blog.csdn.net/qq\_39903567/article/details/117024675][https_blog.csdn.net_qq_39903567_article_details_117024675]

参考：  
[https://tech.meituan.com/2018/09/27/fe-security.html][https_tech.meituan.com_2018_09_27_fe-security.html]

[https_blog.csdn.net_qq_39903567_article_details_117024675]: https://blog.csdn.net/qq_39903567/article/details/117024675
[https_tech.meituan.com_2018_09_27_fe-security.html]: https://tech.meituan.com/2018/09/27/fe-security.html