安全(要和不要)

定期检查您的应用程序的安全性,因为任何失误都可能使您自己,您的团队,您的用户甚至您的服务器面临严重漏洞的风险。 不要忽略这个页面,因为你认为你知道一切。

我们为安全影院的新手收集了一些最佳实践,并为Vue生态系统新手提供了一些安全专业的见解。 当我们通过自己的研究和很棒的安全社区的发布意识到风险时,我们将修改并添加到本文档中。

Vue安全风险

用户输入和v-html的危险

v-html指令是一种以编程方式呈现标记的好方法,但即使是Vue文档也带有此警告:

“在您的网站上动态呈现任意HTML可能非常危险,因为它很容易导致XSS漏洞。仅对可信内容使用HTML插值,而不使用用户提供的内容。”

如果您不知道这意味着什么,请快速了解一下OWASP对[XSS(又称跨站点脚本)]的评价(https://www.owasp.org/index.php/Cross-site_Scripting_(XSS))。

公平地说,这一个很好的建议,但不要总不切实际。 想象一个会创新的攻击者,他会使用社会工程攻击、撒谎、网络钓鱼等方式费尽心思进入你的系统。如果出现webpack加载器漏洞并以邪恶方式更改页面,该怎么办?如果有人制造卑鄙和恶意的公关怎么办?如果突然第三方API更改和替换纯文本并开始发送相同结构但不同内容的数据,该怎么办?如果您认为安全的系统实际上已经被放入后门了怎么办?如果初级开发人员对代码进行意外且根本性威胁的更改且对未经正确审核会怎么样? (是的,白痴有时和坏意图一样危险!)重点是,通过准备绝对最坏的情况并强化所有系统来预测意外情况。

使用v-pre指令, 如果您需要采取额外的预防措施。

vue-i18n

Vue的准官方国际化包允许您将html存储在密钥的值中并可能呈现它们。 如果用户无法修改这些值,您应该没问题 - 但请确保您信任(也就是审查)翻译! 我们的建议(虽然带来更多的工作,并将减慢HMR)是使用模板插值

eval()

虽然你可能会想要使用eval(),即使你知道自己在做什么,但请不要

Quasar组件

两个Quasar组件和两个插件能防止呈现“不安全内容”。 这是一个可选功能,通过向组件添加sanitize类型的布尔属性来实现。 这些组件将在下面讨论。

QSelect

如果您没有自定义与菜单相关的作用域槽(即option作用域槽),阻止组件在带有一个或多个sanitize属性的标签和子标签中呈现HTML。 一般来说,这不是用户提供的数据。 如果您要自定义此插槽,您自己有责任去消除风险。

QChat & Emoji

同样可以通过使用sanitize属性阻止QChatMessage组件将html传递给浏览器。

TIP

最近有一些漏洞(特别是对于较旧的Android和iOS设备),其中某些表情符号和非标准UTF-8实际上触发了移动设备重启和启动屏幕循环。 考虑对在纯文本类型的输入字段中的markdown解析进行devland集成,并在将其传递给聊天接收者之前在服务器端将其呈现为HTML。

加载

许多开发人员要求加载插件能够显示HTML,因此默认情况下启用了这个功能,但是如果你有所担心,则添加sanitize:true并删除向量。

通知

能使用HTML设计通知插件默认是不启用的(因为它不符合Material Design的规范),但是如果你设置了布尔属性html:true那么你负责消除风险。

对话框

能使用HTML设计对话框插件默认是不启用的(因为它不符合Material Design的规范),但是如果你设置了布尔属性html:true那么你负责消除风险。

QInput

任何允许用户输入按键、从缓冲区粘贴或删除文件的字段都存在安全风险。 我们不会详细介绍这个细节,但请记住,保持安全是您的责任。 只有你可以防止服务台火灾!

QEditor

该组件允许用户实际创建HTML(甚至粘贴它)。 如果您要将其保存并将其显示给其他用户,则需要在服务器端关注以验证它。 在那种情况下去掉<script></ script><iframe></ iframe>。 您可以访问v-html vs. double-mustache 文档中的示例来使用QEditor组件,并查看两种呈现方法将提供的内容。 QEditor没有sanitize标签。 此外,如果您创建自定义按钮,则您有责任确保它们的安全。 警告过你了。 .

处理文件

那么如何验证和确保文件安全呢? 好吧,虽然这有点超出了“前端框架”的范围,但我们知道很多读这篇文章的人也会在服务器上存储用户创建的文件。 如果你只是存储它们(而不是以任何方式处理它们),通过检测幻数来验证文件的类型是否合适。 考虑使用ClamAV检查已知病毒签名的文件。

图片

如果您允许用户将图像上传到您的服务器,您应该知道许多常用模块只检查文件后缀。 制作一个只表面上看似图像的图像是轻而易举的。 通过检查幻数来验证文件是否是它所声称的文件,为此考虑使用is-image。 虽然您可以使用此方法检查浏览器中的幻数, 另一种方法是让用户将图像加载到画布中,然后直接从画布上传。 Vue-croppa 是很好的前端工具。

归档

用于目录遍历的归档解压缩攻击是一个真正的安全问题,并且在不解压缩文件的情况下几乎不可能检测到。 如果你可以不接受这种类型的媒体来避免这个问题,那就去做吧。 否则,在Linux上使用简陋的 less / lesspipe.lessfilter通过您自定义的工作流程来预处理这些文件。

密码

不要以明文保存密码,事实上 - 不要保存密码。 保存安全哈希并按照使用安全盐和适当算法的方案在内存中计算它们。 限制密码的长度(最小和最大字符数),但是将上限设置得足够高,以至于没有合法用户可以使用。 考虑使用高度安全的密码重置应用程序流程,并允许用户根据自己的喜好进行配置。这是每个项目都独有的流程,因此我们无法告诉您如何解决问题。不过这里有一些很好的链接:

密码学

  • 不要创建自己的加密解决方案
  • 不要以明文形式存储个人信息
  • 不要创建自己的加密解决方案
  • 不要忽略实施细节的任何方面
  • 不要创建自己的加密解决方案
  • 不要使用MD5或SHA1
  • 不要创建自己的加密解决方案

关于这个主题和正确选择工业强度解决方案的好地方是libsodium

分发

TIP

如果有人想要更改数据库中的某些内容或将某些文件添加到服务器并且他们没有使用SSH密钥,则验证输入确保输入安全。

Web

  • 不要使用http
  • 不要在JWT中存储敏感数据
  • 使用https / wss
  • 手动审核您的证书
  • 验证用户
  • 记住JWT没有按照sé加密
  • 使用JWE代替JWT并使用AES256 CBC + HMAC SHA512
  • 双击并执行完整的OWASP网络审核

Cordova

  • 不要使用iframe
  • 不要使用适用于Android Gingerbread的包
  • 签名所有版本
  • 加密的所有静态数据

Cordova文档页面详细介绍了有关保护Cordova的详细信息,虽然看起来已经过时,但这些信息大多仍然适用。

Electron

Electron是一个非常特殊的情况,因为XSS和远程代码注入实际上可能导致最终用户(甚至开发人员)设备的完全瘫痪。

  • 不要禁用websecurity
  • 不要启用远程代码执行
  • 阅读我们的增强Electron安全指南。

SSR

使用SSR模式生成项目时,将为您提供最小的Express服务器。 您有责任强化您的环境以保护您的服务器和用户。 为此,我们提供了一系列重要的HEADERS,您可以考虑这些HEADERS,并在项目进入生产阶段之前选择性地激活(请参阅src-ssr/index.js)。 重要的是要记住,HEADERS不是防弹的,因为这取决于浏览器供应商是否尊重它们 - 例如如果您的内容安全策略使用sandbox值, Chrome将打破PDF查看

  • 不要忘记设置限制性headers
  • 不要认为单独使用headers可以保护您免受所有攻击
  • 阅读headers

环境安全

更安全意味着要考虑很多事情,并且您遵守的以下准则越多,攻击足迹就越小。

运营安全

审核您的开发系统如何工作:

  • 不要保留不需要的软件
  • 使用占用空间更小,启用安全功能的操作系统和发行版(例如SELinux)
  • 确保您机器上的所有软件都是最新的(尤其是NODE)
  • 使用密码管理器
  • 尽可能使用双因子验证(2FA)

审核您的生产环境如何工作:

  • 不要认为默默无闻的安全措施会在你受到攻击时帮助你
  • 不要打开不需要的端口
  • 不要以为容器或VM根据其性质保护您的安全
  • 不要停止偏执,永远
  • 关闭服务器的密码和root访问权限
  • 使用安全传输协议(SSH,HTTPS,SFTP,WSS)
  • 安装fail2ban和rkhunter
  • 定期分析您的日志
  • 加密静态数据
  • 使用先进的媒体类型分析
  • 使用ClamAV检测受感染的文件
  • 定期进行系统维护
  • 从允许/可用类型中删除旧密码
  • 使用CSP标头保护用户

组织和存储库安全

这是每个团队应该在他们的雷达上进行思考的事情。 考虑谁有权访问您的存储库,如何合并提交以及如何发布资产。 以下是一些值得记住的好事:

  • 不要将敏感数据放入源代码中
  • 不要忽略yarn auditnpm audit报告
  • 不要盲目依赖第三方服务
  • 在合并到master之前进行审核
  • 对审阅者/代码提交者进行双因子验证(2FA)
  • 签名提交
  • 认真对待GitHub安全警告
  • 进行深入的代码审查
  • 审查关键的第三方库,尤其是使用真实文件的任何库
  • 为关键库订版本
  • 提交锁包文件
  • .env文件添加到.gitignore

得到帮助!

关于我们的专家团队如何帮助您,请了解更多

最后的注意事项

安全不是安心,它是需要警惕和意识到的知识的实际应用。 不要停止担心安全问题,不要认为你做得足够了。 你可以承担更多的事情,不断有新的漏洞需要注意。 但是他们最大的安全威胁都是懒惰,所以穿你的外面的鞋子,向上滚动页面,然后阅读关于XSS的OWASP链接。 我们不会告诉任何人。