前端安全问题及解决方案

一、跨站脚本攻击（XSS）

XSS，即Cross Site Script（跨站脚本攻击）；为了和层叠样式表(Cascading Style Sheet)做出区分，在安全领域叫做 XSS。通过URL带入的，浏览器错误的将攻击者提供的用户输入数据当做JavaScript脚本给执行了。

解决： 使用正则匹配去除某些字符串、过滤域名。

function filterXss(str, regExp){// let regex = /<(\S*?)[^>]*>.*?|<.*? \/>/gi;// 去除包含<>内容的，防止xss漏洞let filterValue = str.replace(/<.*?>/g,'');// 去除<开头类型的xss漏洞filterValue = str.replace(/<+.*$/g,'');if(regExp && !regExp.test(filterValue)){filterValue = '';}return filterValue;
}

1、XSS 有哪些

1.1反射型攻击

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

当用户的输入或者一些用户可控参数未经处理地输出到页面上，就容易产生XSS漏洞。主要场景有以下几种：

将不可信数据插入到HTML标签之间时；// 例如div, p, td；

将不可信数据插入到HTML属性里时；// 例如：

将不可信数据插入到SCRIPT里时；// 例如：

还有插入到Style属性里的情况，同样具有一定的危害性；// 例如<span style=” property : $INPUT”>
将不可信数据插入到HTML URL里时，// 例如：<a href=”http://www.abcd.com?param= $INPUT ”>

1.2存储型XSS

简述： 存储型（或 HTML 注入型/持久型）XSS 攻击最常发生在由社区内容驱动的网站或 Web邮件网站，不需要特制的链接来执行。黑客仅仅需要提交 XSS漏洞利用代码（反射型XSS通常只在url中）到一个网站上其他用户可能访问的地方。这些地区可能是博客评论，用户评论，留言板，聊天室，HTML电子邮件，wikis，和其他的许多地方。一旦用户访问受感染的页，执行是自动的
漏洞成因：
存储型XSS漏洞的成因与反射型的根源类似，不同的是恶意代码会被保存在服务器中，导致其它用户（前端）和管理员（前后端）在访问资源时执行了恶意代码，用户访问服务器-跨站链接-返回跨站代码。

1.3 DOM型XSS

简述： 通过修改页面的DOM节点形成的XSS，称之为DOM Based XSS。
漏洞成因:

DOM型XSS是基于DOM文档对象模型的。对于浏览器来说，DOM文档就是一份XML文档，当有了这个标准的技术之后，通过JavaScript就可以轻松的访问DOM。当确认客户端代码中有DOM型XSS漏洞时，诱使(钓鱼)一名用户访问自己构造的URL，利用步骤和反射型很类似，但是唯一的区别就是，构造的URL参数不用发送到服务器端，可以达到绕过WAF、躲避服务端的检测效果。

2、XSS 攻击的预防

XSS 攻击有两大要素： 1. 攻击者提交恶意代码。 2. 浏览器执行恶意代码。

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

2.1.1 在使用 .innerHTML、.outerHTML、document.write()时要特别小心，不要把不可信的数据作为 HTML插到页面上，而应尽量使用.textContent、.setAttribute() 等。

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

2.2.输入过滤、转义

简述： 使用正则匹配去除某些字符串、过滤域名。如下：

function filterXss(str, regExp){// let regex = /<(\S*?)[^>]*>.*?|<.*? \/>/gi;// 去除包含<>内容的，防止xss漏洞let filterValue = str.replace(/<.*?>/g,'');// 去除<开头类型的xss漏洞filterValue = str.replace(/<+.*$/g,'');if(regExp && !regExp.test(filterValue)){filterValue = '';}return filterValue;
}

2.3 前端渲染把代码和数据分隔开

简述： 在前端渲染中，我们会明确的告诉浏览器：下面要设置的内容是文本（.innerText），还是属性（.setAttribute），还是样式（.style）等等。浏览器不会被轻易的被欺骗，执行预期外的代码了。
Javascript：可以使用textContent或者innerText的地方，尽量不使用innerHTML；
query：可以使用text()得地方，尽量不使用html()；

二、CSRF攻击

https://www.cnblogs.com/meituantech/p/9777222.html

三、iframe带来的风险

有些时候我们的前端页面需要用到第三方提供的页面组件，通常会以iframe的方式引入。典型的例子是使用iframe在页面上添加第三方提供的广告、天气预报、社交分享插件等等。

因为iframe中的内容是由第三方来提供的，默认情况下他们不受我们的控制，他们可以在iframe中运行JavaScirpt脚本、Flash插件、弹出对话框等等，这可能会破坏前端用户体验。

解决： sandbox的安全属性，通过它可以对iframe的行为进行各种限制，充分实现“最小权限“原则。使用sandbox的最简单的方式就是只在iframe元素中添加上这个关键词就好，就像下面这样：

<iframe sandbox src="..."> ... </iframe>

sandbox还忠实的实现了“Secure ByDefault”原则，也就是说，如果你只是添加上这个属性而保持属性值为空，那么浏览器将会对iframe实施史上最严厉的调控限制，基本上来讲就是除了允许显示静态资源以外，其他什么都做不了。比如不准提交表单、不准弹窗、不准执行脚本等等，连Origin都会被强制重新分配一个唯一的值，换句话讲就是iframe中的页面访问它自己的服务器都会被算作跨域请求。

另外，sandbox也提供了丰富的配置参数，我们可以进行较为细粒度的控制。一些典型的参数如下：


allow-forms： 允许iframe中提交form表单
allow-popups： 允许iframe中弹出新的窗口或者标签页
（例如，window.open()，showModalDialog()，target=”_blank”等等）
allow-scripts： 允许iframe中执行JavaScript
allow-same-origin： 允许iframe中的网页开启同源策略

四、HTTPS降级HTTP

为了保护信息在传输过程中不被泄露，保证传输安全，使用TLS或者通俗的讲，使用HTTPS已经是当今的标准配置了。然而事情并没有这么简单，即使是服务器端开启了HTTPS，也还是存在安全隐患，黑客可以利用SSL Stripping这种攻击手段，强制让HTTPS降级回HTTP，从而继续进行中间人攻击。

问题的本质在于浏览器发出去第一次请求就被攻击者拦截了下来并做了修改，根本不给浏览器和服务器进行HTTPS通信的机会。大致过程如下，用户在浏览器里输入URL的时候往往不是从https://开始的，而是直接从域名开始输入，随后浏览器向服务器发起HTTP通信，然而由于攻击者的存在，它把服务器端返回的跳转到HTTPS页面的响应拦截了，并且代替客户端和服务器端进行后续的通信。由于这一切都是暗中进行的，所以使用前端应用的用户对此毫无察觉。

解决这个安全问题的办法是使用HSTS（HTTP Strict Transport Security），它通过下面这个HTTP Header以及一个预加载的清单，来告知浏览器在和网站进行通信的时候强制性的使用HTTPS，而不是通过明文的HTTP进行通信：

Strict-Transport-Security: max-age=<seconds>; includeSubDomains; preload

这里的“强制性”表现为浏览器无论在何种情况下都直接向服务器端发起HTTPS请求，而不再像以往那样从HTTP跳转到HTTPS。另外，当遇到证书或者链接不安全的时候，则首先警告用户，并且不再让用户选择是否继续进行不安全的通信。