前端安全性应该做什么从安全漏洞开始
原标题:前端安全性应该做什么？让我们从安全漏洞开始.
author |李诗琪
editor |郭蕊
从一个安全漏洞说起
Lodash是一个非常受欢迎的npm库，每月有超过8000万次下载，在GitHub上有超过400万个项目使用它。不久前，洛达什的一个安全漏洞炸毁了朋友圈。让我们先回忆一下这个安全漏洞:
攻击者可以通过Lodash的某些功能覆盖或污染应用程序。例如，Object.prototype的属性可以通过Lodash库中的函数defaultsDeep进行修改。
我们都知道，当Java读取对象中的属性时，如果找不到，它会在原型链中查找它。想象一下，如果修改后的属性是toString方法:
const load=' { ' constructor ' : { ' prototype ' : { ' ToString ' : true } } } '
_。默认深度({})。
每个对象都有一个toString方法，当对象被表示为文本值时，或者当对象被引用为预期字符串时，会自动调用该方法。默认情况下，toString方法由每个对象对象继承。如果在自定义对象中没有重写此方法，toString将返回[对象类型]，其中类型是对象的类型。如果toString方法被覆盖，对应用程序的影响将非常大。
事实上，上述问题属于非常常见的原型污染安全漏洞——。
原型污染:攻击者通过某种方式修改了一个Java对象的原型。
然而，这并不是洛达什第一次暴露出安全漏洞。事实上，像这样的安全漏洞可能仍然存在于我们在千千使用的1000万种不同的开源依赖中。如果我们平时不注意，我们的项目在遇到问题时造成的损失是无法估计的。这相当于在你的项目中埋下许多不知道什么时候会爆炸的炸弹。
Security Survey
事实上，开发人员对源代码的安全性比对他们编写的代码的安全性更有信心，但是在确保代码安全性和质量的工具方面仍然存在许多不足。在npm没有完善的安全检测机制之前，npm和NodeJs团队曾经对成千上万的Java开发人员发起了一项调查。第一个问题是安全性，特别是开发人员如何看待他们编写的代码和他们使用的开源项目的安全性。
调查结果显示，全球97%的Java开发人员在自己的项目中依赖开源代码，77%的开发人员担心他们使用的开源代码的安全性。更有趣的是，87%的人对他们代码的安全性表示担忧。
此外，一半以上的Java开发人员认为他们用来评估开放源代码的安全性和质量的工具不够好。
NPM Audit
NPM官员维护一个漏洞列表。当开发人员或专业安全团队发现依赖包存在安全问题时，他们会向NPM官员报告，然后该官员会通知项目开发人员进行修复。修复完成后，npm将发布漏洞和解决方案的详细描述信息:
npm aduit主要将需要检查的依赖信息发送到官方检查界面。该结构将判断当前依赖信息是否包含历史上报告的漏洞数据库中的漏洞，然后生成漏洞报告，包括包名称、漏洞严重性、配置文件、路径等。反馈给开发者。
我们现在正在直接安装一个带有安全漏洞的lodash
4.17.4版本，所以在安装完成后，您会被提醒刚刚添加的依赖项包含3个漏洞。
执行npm审核我们可以看到漏洞的详细信息。这个版本的lodash有三个安全漏洞。让我们仔细看看其中一个:
该项目不直接依赖于lodash，而是依赖于
commit lit/load中
commit lit/CLI所依赖的lodash。因此，对于一些迭代周期长的大型项目来说，包含数万个安全漏洞是正常的。
单击链接了解漏洞的详细信息:http://www.npmjs.com/advisories/1065
我们可以看到漏洞和解决方案的具体描述。右侧是漏洞的具体报告时间和披露时间。
GitHub安全委员会
我们可能经常收到类似以下GitHub安全漏洞警报的电子邮件。
打开链接，我们可以看到该漏洞的具体详细信息页面:
GitHub为此打开了一个单独的页面。安全部分显示了GitHub检测到的依赖安全漏洞。可以看出，这些漏洞足以引起大家的注意，需要快速修复:
此外，GitHub还为每个可修复的漏洞提供了一键式修复功能。单击自动安全更新按钮，GitHub将自动修复这些相关漏洞。并向您的仓库提交拉取请求:
安全漏洞修复策略
npm还提供npm奥迪菲克斯命令来帮助我们自动修复漏洞，并继续使用上述示例。Lodash在版本4.17.12之前有原型污染漏洞。让我们来看看具体的修复策略:
直接依赖漏洞
目前，我们直接依赖于具有安全漏洞的lodash
4.17.4版本:
“依赖项”: {
“Lodash”: ' 4.17.4 '
安全漏洞修复策略
因为4 . 17 . 4的依赖项范围是=3 . 0 . 3 . 4 . 0 . 0，并且修复后的版本4.17.12在这个范围内，npm审核修复实际上执行逻辑npm更新
Lodash
4 . 17 . 4-Lodash
4.17.12
安全漏洞修复策略
假设我们当前的依赖路径很深:
commitlin/CLI 7 . 1 . 2
commitlin/Load 1 . 0 . 1 Lodash 3 . 0 . 0
因为
安全漏洞修复策略
假设
commitlin/load此时有更新版本
commitlint/load^1.0.2依赖于lodash 4.0.0 (=4.0.05.0.0)，lodash
4.17.12在此依赖范围内，则修复策略为npmpupdate
实现npm审计- json将打印出一份详细的json格式安全报告，您可以在其中看到这些漏洞的详细信息和特定的漏洞修复策略。
由于这个JSON相对较大，我不会直接在这里发布。您可以选择一个项目在本地执行npm审计。
间接依赖漏洞
in metadata属性:我们可以看到漏洞检查的数据概览:
漏洞显示每个级别的漏洞数量，信息的相应安全漏洞级别从左到右依次为低、中、高和关键。
以下是每个依赖项的测试次数，即熟悉的依赖项、开发依赖项等。
强制修复漏洞
在“操作”属性中，将列出所有易受攻击的修复策略。例如，下面，更新
commitlin/load，深度为2。若要修复路径
commitlin/CLI
commitlin/loadlodash上的漏洞:
commitlin/load '，'目标' :' 1.0.2 '，
'操作' : '更新'，'模块' : '
commitlin/load，深度为2。若要修复路径
'解析' :[
' id ' : 1184，
'路径' : '
commitlin/CLI
commitlin/loadlodash '，
'开发' : 让我们来看看一些要点:
不可修复漏洞
commitlin/loadlodash '，
1，Hacker One
漏洞数据总览
Hacker One(http://hackerone.com)成立于2012年，是一个聚合和披露安全漏洞的平台。黑客可以在网站上披露他们发现的安全漏洞，并向相关网站或公司报告，这些网站或公司可以在确认后向黑客提供各种感谢，如奖金。黑客龙(HackerOne)已经注册了30多万名黑客，提交了10多万个有效漏洞，支付了超过4200万美元的漏洞奖励。
修复策略
2，Snyk
Snyk是一个面向多个开发堆栈的依赖分析平台，涵盖了Java、Java、Net、Ruby、Python、PHP、Golang和Scala。Snyk维护一个全面的开源漏洞数据库，包括Snyk自己的专门研究团队发现的漏洞和从公共数据源跟踪的漏洞。
Snyk的漏洞数据库通过其威胁情报系统提供了关于漏洞的全面数据，提供了更好的覆盖范围，并能够显示和报告尚未收到CVE的漏洞。例如，npm建议的72%的漏洞首先被添加到Snyk数据库中。
Snyk还提供了扫描安全漏洞的机制。与npm审计相比，它的优点是可以很容易地与GitHub或GitLab的配置项过程集成。有关扫描机制的更多比较，请参见本文:http://www.nearform.com/blog/comparing-npm-audit-with-snyk/.
我们可以从上面的安全报告中看到，将会有一个Snyk漏洞报告作为某些漏洞的参考，Lodash也是Snyk安全团队发现并报告的一个安全漏洞。
3，CVE
用CVE标识识别特定漏洞或暴露。组织可以快速准确地从各种CVE兼容信息源获取信息。通过比较不同的安全工具和服务，CVE可以帮助组织选择最适合其需求的内容。
正如我们所见，无论是上面的npm审计报告，还是Snyk、HackerOne等其他安全平台的报告。将附上漏洞的CVE号。
摘要
我希望阅读这篇文章能对你有如下帮助:
了解依赖安全漏洞的背景；了解npm自动修复安全漏洞的机制；学习一些常见的安全知识，以提高对前端安全问题的关注。作者:李诗琪，字节跳动工业工程学院的前端工程师。
