Premise
-
This article focuses on development environment security, not production environment security.
-
This article is especially geared towards web3 developers, as their development environments may have more sensitive data, especially private keys.
-
Some simple solutions will be given at the end of this article, but the most important thing is to be aware that your development environment is very insecure.
Modern Nodejs development, both front-end and server-side, is used to use .env environment variables to manage the application’s configuration information, which is then fetched in the Nodejs code via require(‘dotenv’).config().
The popular solidity development tool hardhat also uses Nodejs to run deployment and testing scripts, and people are also used to using dotenv to configure private keys and other information in the project, and then use it in hardhat deployment and testing scripts.
But I wonder if you have ever considered whether such a development environment is secure?
How is it not secure?
-
The npm packages that depend on the currently running project may surreptitiously read the environment variables of the current process and upload them to the specified server, the whole process is unaware and does not require any permission confirmation.
-
An npm package that depends on a currently running project may scan your hard drive, read the files on your hard drive, look for configuration files such as .env or .local.env, fetch their contents, and upload them to a specified server, but the whole process is unaware and does not require any permission confirmation, as long as the scanning is done properly.
-
Other programs or processes in the system, read environment variables, scan all files in the development folder, look for configuration files, read the contents, and upload them to the specified server.
Why the fine print?
In the web2 era, the configuration that appears in the development environment is usually some database configuration of the development environment, or some secret key configuration of the test environment system, and so on, and this information usually does not have much use value on the public web, so it does not pose much security problem.
However, in the web3 era or other cryptography-related development fields, information such as wallet private key is a very core asset of users, and mastering the private key of a wallet basically controls all the privileges of the account.
In addition, the wallet address and the private key are bound one-to-one, there is no mechanism to recover the password similar to that of a normal account, once the secret key is leaked, you can only discard the wallet address, but cannot assign a new private key to it.
And the secret key of a wallet address, regardless of testing and production, the secret key is the same. Although we can circumvent security issues through many good habits, it still leads to private key leakage due to unfamiliarity or negligence.
I wonder if you have paid attention to this problem? And if it is circumvented?
Translated with DeepL Translate: The world's most accurate translator (free version)
Chinese Version
前提
-
本文主要探讨开发环境安全，而不是生产环境安全。
-
本文特别面向 web3 开发者，因为他们的开发环境可能存在更多敏感数据，特别是私钥。
-
本文最后会给出一些简单的解决方案，但是最重要的是希望大家意识到你的开发环境非常不安全。
现代 Nodejs 开发，不管是前端还是服务端，都习惯使用 .env 环境变量来管理应用的配置信息，然后在 Nodejs 代码中，通过 require(‘dotenv’).config() 来获取配置信息。
现在流行的 solidity 开发工具 hardhat 也是使用 Nodejs 来运行部署和测试脚本的，同样大家也习惯使用 dotenv 来在项目中配置私钥等信息，然后在 hardhat 部署和测试脚本中使用。
不过不知道大家是否考虑过这样的开发环境是否安全？
怎么不安全？
-
当前正在运行的项目中依赖的 npm 包，可能会偷偷读取当前进程的环境变量，并将其上传至指定的服务器，整个过程是无感知的，不需要任何权限确认。
-
当前正在运行的项目中依赖的 npm 包，可能会扫描你的硬盘，读取你硬盘上的文件，寻找譬如 .env 或者 .local.env 等类型的配置文件，并获取其中内容，上传至指定的服务器，只要扫描得当，整个过程是无感知的，不需要任何权限确认。
-
系统中的其他程序或者进程，读取环境变量，扫描开发文件夹内的所有文件，寻找配置文件，读取内容，上传至指定的服务器。
为什么细思极恐？
在 web2 时代，出现在开发环境中的配置通常是开发环境的一些数据库配置，或者一些测试环境系统的秘钥配置之类的，这些信息通常在公网上不具备太大的使用价值，所以不会带来太大的安全问题。
但是在 web3 时代，或者其他和加密相关的开发领域，类似钱包私钥等信息，是用户非常核心的资产，掌握了一个钱包的私钥，基本上就掌控了这个账户的所有权限，其危害性还不止账户内的资产本身，还包括这个账户拥有 owner 权限的合约的安全。
另外，钱包地址和私钥是一对一绑定的，没有类似于普通账户中的恢复密码的机制，一旦秘钥泄露，你只能弃用这个钱包地址，而无法为其分配新的私钥。
而且一个钱包地址的秘钥，不分测试和生产，秘钥都是同一个，虽然我们可以通过很多良好的习惯规避安全问题，但是还是会因为不熟悉或者疏忽，导致私钥泄露。
不知道大家是否关注过这个问题呢？又是如果规避的？
