背景原因：

16461179597757.jpg

针对此情况，Vue作者尤雨溪发表了《关于近日涉及 SonarQube 和 Vue 的漏洞通知》作为回应。
结论：Vue近期并没有收到漏洞报告，SonarQube近期公开漏洞是纯粹的后端 API 鉴权漏洞，跟前端和 Vue 没有任何关系，同时只要遵循普适的前端安全常识，Vue 本身并不存在任何安全性问题。

那我们应该遵循怎样的前端安全常识呢？

什么是前端安全问题

所有发生在浏览器、单页面应用、Web页面当中的安全问题。

浏览器最核心和基础的安全功能
同源策略（same origin policy）
重要因素：协议+域名+端口
限制来自不同源的“document“或脚本，对当前“document”读取或设置某些属性。

当前浏览器面临的主流攻击手段及主流防御手段
善守者藏于九地之下，善攻者动于九天之上

1、跨站脚本攻击（XSS）

XSS是跨站脚本攻击（Cross-Site Scripting）的简称， OWASP排行榜中长期霸榜，从未掉出过前三名的存在。
xss本质原因：浏览器错误的将攻击者提供的用户输入数据当做JavaScript脚本给执行了
分类：
1、恶意输入的脚本是否在应用中存储，XSS被划分为“存储型XSS”和“反射型XSS”；
（1、）反射型攻击手段
将用户输入或者地址输入的数据反射给浏览器，让浏览器默认去执行。
例如：
一个带有参数的地址（www.ceshi.com?a=我在测试）
这个a的参数需要写入到界面上去，
通常手段是将这个a中的参数修改成一个script脚本，页面加载的时候就执行了该脚本实现xss攻击

16481931847254.jpg

一般手段
在 HTML 中内嵌的文本中，恶意内容以 script 标签形成注入。
在内联的 JavaScript 中，拼接的数据突破了原本的限制（字符串，变量，方法名等）。
在标签属性中，恶意内容包含引号，从而突破属性值的限制，注入其他属性或者标签。

16484749790176.jpg

在标签的 href、src 等属性中，包含 javascript: 等可执行代码。
在 onload、onerror、onclick 等事件中，注入不受控制代码。

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

一个优秀的开发者应该明白它的原理。站在黑客的角度来讲，面对环境的逐步变化，条件的逐步限制，攻击思路灵活变化是对整个职业生涯有益的。
防御手段 ：
1、上下文编码输出

2、安全属性使用

16481940683667.jpg

（2、）储存型攻击手段

存储型XSS会把用户输入的数据“存储”在服务器端。这种XSS具有很强的稳定性。

比较常见的一个场景就是，黑客写下一篇包含有恶意JavaScript代码的博客文章，文章发表后，所有访问该博客文章的用户，都会在他们的浏览器中执行这段恶意的JavaScript代码。黑客把恶意的脚本保存到服务器端，所以这种XSS攻击就叫做“存储型XSS”。
存储型XSS通常也叫做“持久型XSS”(Persistent XSS)，因为从效果上来说，它存在的时间是比较长的。

16486087093812.jpg

案例
不少开发者（https://v2ex.com/t/840562#reply11）在使用到 vue -cli 中的 node-ipc 模块时，这个依赖项会在桌面以及其他位置创建一个叫做“WITH-LOVE-FROM-AMERICA.txt”的文件，不过打开这个文件是空的。据悉，该 package 每周下载量达到了百万。另外，使用 Yarn 的开发者也受到了影响。
开始有人以为只是个恶作剧，但事情并非如此简单。有开发者在对代码进行测试处理后发现，node-ipc 包的作者 RIAEvangelist 在投毒。他起初提交的是一段恶意攻击代码：如果主机的 IP 地址来自俄罗斯或白俄罗斯，该代码将对其文件进行攻击，将文件全部替换成 ❤。

当开源开始“站队”时，开发者该如何自处？

“DOM based XSS”类型其实也是反射型，按照“数据是否保存在服务器端”来划分，DOM Based XSS从效果上来说也是反射型XSS。

2、跨站点请求伪造（CSRF）

典型的钓鱼网站
诱使用户点击第三方网站，以该用户的身份向被攻击网站发送请求，获取凭证从而绕过后台用户认证。
通过iframe、img、script等带src属性的标签和form表单提交，发起跨域请求

CSRF通常是跨域的，因为外域通常更容易被攻击者掌控。但是如果本域下有容易被利用的功能，比如可以发图和链接的论坛和评论区，攻击可以直接在本域下进行，而且这种攻击更加危险。

16481910163638.jpg

有这种地址加参数直连的，就要注意了，我们需要先进行一次RSA加密在通过encodeURIComponent对数据进行编码。

16485651790597.jpg

3、iframe的风险
攻击场景：
前端页面需要用到第三方提供的页面组件，通常会以iframe的方式引入。
iframe在给我们的页面带来更多丰富的内容和能力的同时，也带来了不少的安全隐患。因为iframe中的内容是由第三方来提供的，默认情况下他们不受我们的控制，他们可以在iframe中运行JavaScirpt脚本、Flash插件、弹出对话框等等，这可能会破坏前端整体的安全性。

他们是如何去破坏前端安全的呢？接下来我们介绍最常见的两种方式

1、iframe中的域名因为过期而被恶意攻击者抢注（这个很简单不多介绍）
2、第三方被黑客攻破，iframe中的内容被替换掉（关于怎么去攻破，我们可以把后面介绍的攻击方法在第三方网页上都去试一次。所以我们在使用第三方的时候都要做到小心谨慎，毕竟第三方的代码不受我们自己控制）
下载安装木马、恶意勒索软件

防御手段：
浏览器沙箱（sandbox）
对iframe的行为进行各种限制，充分实现“最小权限“原则。
将不受信任的网页或JavaScript代码运行在一个受限制的环境中。从而保护本地系统安全。
除了允许显示静态资源以外，其他什么都做不了。比如不准提交表单、不准弹窗、不准执行脚本等等，连Origin都会被强制重新分配一个唯一的值，换句话讲就是iframe中的页面访问它自己的服务器都会被算作跨域请求。

疫情防控的临时隔离点

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

4、点击劫持（ClickJacking）

引入控制。企业应规范开源软件的引入流程，建立开源软件安全引入和退出机制。同时，对开源软件的引入需要加入安全评估因素，不仅需要评估项目团队引入的开源软件是否存在公开的漏洞，是否存在开源法律风险，而且企业应进行完整性验证，开源软件是否来自官方，避免使用被篡改的开源软件。

资产梳理。无论是软件开发者，还是企业，它们在软件开发过程中会引入大量开源软件。然而，企业的安全管理者和开发管理者常常不清楚自身的信息系统到底引入多少开源软件，引入了哪些开源软件。开源软件有着层层嵌套的依赖关系，软件开发者或企业很难通过人工方式进行梳理。因此，建议使用专业的自动化工具识别软件系统中含有哪些开源软件以及开源软件之间的关联关系，形成企业开源软件可视化资产清单。

风险识别。软件中使用的开源软件可能存在已知漏洞，且这些开源软件背后调用或依赖的其他开源软件也可能存在已知安全漏洞。在软件开发过程中，企业应及时发现存在漏洞的开源软件版本并进行升级。

漏洞告警。在软件运行阶段，企业应监控开源软件漏洞情报信息，及时发现开源软件的最新漏洞信息，并进行应急响应。

合理修复。绝大多数的开源软件是通过版本更新实现漏洞修复的。对于不能通过升级新版本或打补丁来修复漏洞，企业应引入专业的漏洞研究队伍，定制漏洞修复方案。

现代软件大多数是被“组装”出来的，不是被“开发”出来的