如何验证 JavaScript 库是否安全?

信息安全 javascript 漏洞扫描器
2021-08-12 16:24:08

我是开源 JavaScript 库的主要开发人员。该库在我工作的公司中用于几个客户。时不时地有一个客户对实现一个他从未听说过的库感到偏执,并问我为什么他应该信任这个代码。

我理解这种担忧,通常我会将它们指向托管该库的 github 存储库,并显示使用同一库的其他项目和客户端。有时他们会在 github 上查看代码,之后一切运行顺利。

但这一次,客户有点偏执。他问我图书馆已经通过了什么样的安全检查,并告诉我他们的系统“通过了 OWASP 前 10 项检查/扫描验证”。

经过一番研究,我发现最接近的是这份列出2010 年 Web 应用程序中的前 10 个漏洞的文档,作者是 OWASP

我认为并非所有这些都适用,因为我没有提供 Web 应用程序,而只是提供了一个 javascript 库。而我的理解是,这些漏洞大部分时间都需要由安全专家手动检查,而不是自动扫描。

现在我的问题:

  • 有什么方法可以在 JavaScript 库中声明安全标准?
  • 是否有任何工具可以扫描 JavaScript 以查找安全威胁?

更新 1

尽管我不是安全专家,但我是一名 Web 开发人员,并且我了解可能导致 Web 应用程序漏洞的常见缺陷。我需要的是某种方法来专门为非技术人员证明这个库至少已经检查过最小的威胁和漏洞,并且实际上可以安全地在他们的网站上使用。

我想到的可能是一家中立的公司或专门从事网络安全的顾问,可以审查代码并证明其质量。这是一种常见的做法吗?

更新 2

想象一下,有人递给您一个大型 javascript 文件,作为集成的一部分包含在您的网站中。该脚本将在您的站点内运行,并且。您可能想确定该文件的来源以及创建它的开发者是谁。想象一下,facebook 的某个流氓开发人员决定在点赞按钮脚本中注入一些恶意代码,以从运行它的站点窃取数据或 cookie。

当您包含来自知名公司的库或由多人审查的开源项目(如 jQuery)时,这种情况不太可能发生。但是,当您包含来自小公司或独立开发人员的脚本时,我会认为这是一个问题。

我不想在我的库中寻找漏洞,因为我知道我没有包含任何漏洞。我只是想以某种方式证明代码是安全的,因此用户在使用时不会有这种顾虑。

4个回答

为了避免客户端安全问题,您需要了解客户端代码的安全要求和常见错误。OWASP 有很好的资源。确保您阅读了基于 DOM 的 XSS,因为这是最常见的安全错误之一。

至于安全最佳实践,我有几个建议:

  • 为避免 XSS,请遵守Adam Barth 在构建无 XSS Web 应用程序的三个简单规则中找到的规则。

  • 避免setInnerHtml().innerHtml =相反,使用setInnerText()或基于 DOM 的操作(以确保不引入脚本标签,即避免基于 DOM 的 XSS)。避免document.write()

  • 避免eval()它的使用往往与安全漏洞相关。同样,避免使用其他将字符串转换为代码并执行它的 API,例如setTimeout()使用字符串参数、setInterval()使用字符串参数或new Function().

  • 打开Javascript “严格模式”它有助于避免之前导致安全问题的 Javascript 的一些微妙领域。

  • 确保您的代码与严格的内容安全策略兼容(这里有一个教程),例如script-src 'self'; object-src 'self'.

另请参阅有关客户端(Javascript)的安全问题,这是一个相关主题。

我不知道有任何静态分析工具可以扫描 Javascript 并查找安全问题。

如果您遵循 Doug Crockford 关于如何使用 Javascript 的建议(例如,按照他的书 Javascript: The Good Parts),您可以使用JSLint这是一个非常激进的 lint 工具。如果您的代码是 JSLint-clean,那么这是一个积极的标记。但是 JSLint 并不主要关注安全性。而且,如果您使用遗留代码并在其上运行 JSLint,您可能会被一堆警告淹没。

标准做法是让您的客户进行安全测试,但我看到越来越多的开发人员聘请安全测试人员为客户提供一些保证。

但是没有办法说“这段代码保证安全”——只有“这段代码看起来相当安全”或“适合目的”

我认为你想要的基本上是不可能的——说一个程序做或不做一些恶意的(未指定的)事情相当于停止问题。尤其要考虑到 javascript 是复杂的交互软件生态系统的一部分。漏洞利用并不一定像编写一个名为steal_cookies_and_send_to_bad_guys 的函数那么简单。

因此,既然这是不可能的,那么您能做的最好的事情就是让应该能够发现一些“已知种类”的恶意软件的人检查代码,并可能形成一种观点,认为它在其他方面是光明正大的并且写得很好。

一种选择是沙盒或重写 javascript。这是这个方向的一些事情。

http://www.slideshare.net/phungphu/a-twotier-sandbox-architecture-for-untrusted-javascript

Google JS 和 javascript 的客户端沙箱

maffeis 对不受信任的 javascript 进行基于 Google 语言的隔离