如何降低在 npm 模块中发布敏感信息的可能性

《如何降低在 npm 模块中发布敏感信息的可能性》

简评:国内也有不少在开源代码里泄露敏感数据的例子,这种事一定要小心啊。

目前 npm 上有着数十万的包,而隐藏在这惊人数量之下的是更令人惊讶的敏感信息泄漏。包括 authentication tokens、密码、生产测试数据(比如信用卡号码)等等。

作为一个开发者,一定要避免泄漏类似的敏感数据。

npm publish

首先,我们要理解npm publish的行为,了解其如何选择要上传的文件对我们控制发布内容至关重要。当然,如果你想要了解最为详细的内容,可以直接查看 npm documentation

当执行npm publish命令时,npm 会打包当前目录下的文件,同时会根据 .gitignore,.npmignore 和 package.json 中的 “files” 属性来决定忽略掉哪些文件和要包括哪些文件。

npm 总是会包含的文件:

  • package.json;
  • README ;
  • CHANGLOG;
  • LICENSE 或者另一种拼写 LICENCE。

npm 总是会忽略掉的文件:

  • .*.swp
  • ._*
  • .DS_Store
  • .git, hg , .svn, CVS 版本控制目录
  • .npmrc
  • .lock-wscript
  • .wafpickle-*
  • config.gypi
  • npm-debug.log

.gitignore vs .npmignore

忽略某些文件最常用的做法之一就是在 .gitignore 文件中声明。因为,这些你不想提交到仓库的文件通常你也不会想把它们发布出去。

npm 自己也有一个 .npmignore 文件,其行为与 .gitignore 完全一样。而这两者并不是叠加的关系,而是替代关系。如果你在项目中增加了 .npmignore,那么其会完全替代掉 .gitignore 的作用。因此,如果你尝试两个都使用的话,可能就会无意中发布某些你认为已经排除掉的文件。

因此,如果可以的话最好坚持使用 .gitignore,但如果是用其他的版本控制工具,那就使用 .npmignore 吧。

文件白名单

除了去控制哪些文件被排除,还可以通过 package.json 中的 “files” 属性来控制包含哪些文件 –whitelisting with the files array。目前只有 57,000 个包使用了这种方式来控制发布的内容,虽然可能比较麻烦,但确实是最安全的做法。

如果这样做,最终打包的文件将是“files” 中声明的文件加上上面提到的肯定会包含的文件再减去被排除掉的文件

使用只读 tokens

如果你有私有包使用了持续集成(CI)服务,通常会需要提供一个 token 认证,来让 CI 能够完成所需的工作。现在,你可以生成一个只读的 token 给 CI,如果其被泄漏了,造成的损害也会很有限。

目前 npm 命令行还不支持这个功能,但我们可以手动生成:

curl -u [USERNAME]:[PASSWORD] https://registry.npmjs.org/-/npm/v1/tokens \
-X POST -H 'content-type: application/json' \
-d '{"password":"[USERNAME]", "readonly": "true"}'

可以点击 npm 网站中的个人头像 -> Tokens 中检查和删除创建的 token。

《如何降低在 npm 模块中发布敏感信息的可能性》

如果真的不幸泄露了敏感信息,怎么办?

首先你要明白模块一旦发布,基本马上就会被复制到其他的镜像。要确保泄漏的信息不会造成损害最好的办法就是马上让被泄漏的 API 秘钥失效,或者马上修改被泄露的密码。

而如果泄露的信息不是你能修改的,那你的第一步应该是 unpublish the package 来减小损害,然后才去任何适用于数据泄漏的其他操作。但如果你想要 unpublish 的模块已经发布超过了 24 小时,那就只能寻求 npm 支持团队(support@npmjs.com)的帮助了。

总结

如果开发中真的有很敏感的信息,还是建议用白名单来控制,不要嫌麻烦。因为 npm 的特性,一旦泄露基本很快就会被发现。

英文原文:Publishing what you mean to publish
旧文推荐:
Android 国际货币格式化的一个小知识点
图片加载时使用 SVG 作为图片 placehold

点赞