如何保证以太坊DApp本地存储localStorage的安全

本文介绍如何保证以太坊DApp的本地存储localStorage的安全。 内容很详细。 有兴趣的朋友可以参考一下。 希望对大家有所帮助。

部署去中心化应用程序 dapp 会引入一些有趣的安全注意事项，这些注意事项在更传统的开发中可能不存在。 如何保证dApp本地存储的安全？

之所以提出这个问题，是因为我们在使用 Colony dApps 时遇到的一个重要障碍是如何应对使用 IPFS 或 Swarm 等分布式存储系统将 dApp 数据保存在本地的挑战。

我将从 dApp 开发人员的角度来看这个问题，然后研究一些可能的解决方案。

共享本地存储localStorage的问题

IPFS 运行本地 node 节点，它与 Web 服务器捆绑在一起。 捆绑的 Web 服务器允许节点轻松地相互连接并共享网络中其他地方可能需要的数据。

作为一个去中心化的应用程序构建者，您将依赖此 Web 服务器将您的内容从一个节点推送到另一个节点，使其立即可供最终用户按需使用。

假设你完全去中心化并且避免使用 DNS 或网络代理之类的东西来跟踪你的内容在网络上的位置，访问 dApp 的方式通常是通过浏览器使用其查询本地节点哈希，例如：

:8080/QmcefGgoVLMEPyVKZU48XB91T3zmtpLowbMK6TBM1q4Dw/

现在，假设在正常使用期间，您的应用程序将数据保存在浏览器的本地存储中：可能需要传递一些数据，或者保留一个本地用户交互队列以最小化链上交易并节省 gas 成本。

浏览器中的本地存储仅限于特定的地址上下文（域和端口）。 IPFS 节点获取此上下文，这意味着通过 IPFS Web 服务器运行的任何去中心化应用程序都将使用具有读写访问权限的相同 localStorage。

这可能是个大问题。

默认情况下，某些 dApp 的辅助依赖项使用 localStorage 以明文形式临时保存密钥。 这个数据应该不是一天能看到的。

另一个潜在的泄漏问题是保存它们在内存中的状态以便以后可以恢复的包。 类似 Flux 的库通常（相对）安全，因为它们只在内存中运行，但启用持久状态会将内存中的状态放入 localStorage，从而向潜在的攻击者开放。

缓解问题的策略

不幸的是以太坊内存，安全没有灵丹妙药：作为 dApp 开发人员，您为安全所做的任何调整都可能需要在开发的其他方面做出一些妥协。

以下是您可以做出的一些妥协：

没有数据被存储

这当然是最安全的方法，但这有点像烧毁你的房子来消灭蟑螂。 本地存储数据的dApp有很多功能和基本行为，删掉太多之后应用可能就没有存在的意义了。

此外，有许多库默认使用 localStorage，您必须手动检查每个依赖项并删除任何需要它的依赖项，或者自己修改库。

加密一切这在理论上更有希望，特别是因为大多数 dApp 开发人员已经默认在看板上保持加密。

加密本地存储值

加密所有本地存储实际上有点麻烦。 要加密数据，必须有一个密钥：但用户不能将该密钥存储在 dApp 中，因为它将被放置在 localStorage 中，这样做你就回到了原点。

一种解决方案是使用钱包：您的 dApp 可能以某种方式与区块链交互，要求用户解锁钱包以发送和签署交易。 由于无论如何都需要钱包与 dApp 进行交互，因此可以使用每个帐户的私钥对本地存储进行加密。

但是，这也有一些缺点：

使用 Swarm 和 Mist

Mist 是作为 dApp 和以太坊浏览器构建的，因此它为这个问题提供了一些特殊的优势。

默认情况下，Mist 支持 Swarm 的 bzz 协议，因此您可以设置一个 ens 地址指向您的 dApp 的哈希，然后使用 Mist 来无忧地浏览您的 dApp。

不幸的是，这只能解决用户通过 Mist 访问 dApp 的问题。

运行本地 Swarm 节点的用户仍然必须通过本地主机访问，这仍然（可能）将数据泄露给其他 dApp。

为你的 dApp 创建一个浏览器扩展

通过浏览器扩展程序运行你的应用程序将导致它获得一个单独的上下文（它不再位于 localhost:8080），但这有点违背了去中心化应用程序必须依赖于 Chrome 网上商店 A 之类的东西的目的管理和分配的中央权力机构。

此外，现在您必须为每个要支持的浏览器创建和维护单独的扩展，并通过其自己特定的集中式应用商店更新它们。 准确的。

创建独立的桌面应用程序

和以前一样，创建一个独立的应用程序是一种将 dApp 分离到它自己的上下文中的方法，这意味着它有自己的包装器（在本例中为 electron）。

独立的桌面应用程序具有捆绑外部库和您可能需要的任何其他内容的额外好处，包括 IPFS 本身的单独实例。

如前所述，有一些妥协：

将您的应用程序代理到域名

通过使用其他网络服务器来代理本地节点，有两个好处：

首先，您的 dApp 现在有了一个友好的、人类可读的地址，而不是冗长的哈希。 其次，您的应用程序将拥有自己的上下文并且不会共享 localStorage。

然而，代理确实跨越了“真正的”去中心化，用户将不得不再次依赖中央服务器来访问去中心化服务。 嘿。

对于分散的应用程序开发人员来说，现在还处于早期阶段。 这种问题在新兴的“去中心化协议栈”中普遍存在：我们可能还需要一段时间才能想出更优雅的解决方案。

将来以太坊内存，在浏览器中支持本机 IPFS 或 Swarm 节点可以解决这个问题，并且无需将 Web 服务器与去中心化文件存储捆绑在一起。 用户可以输入类似 ipfs://QmcefGgoVLMEPyVKZU48XB91T3zmtpLowbMK6TBM1q4Dw/ 的内容并直接访问 dApp，每个唯一的哈希都分配有自己的上下文。

下面介绍如何保证以太坊DApp的本地存储localStorage的安全。 希望以上内容能够对大家有所帮助，学到更多的知识。 如果觉得文章不错，可以分享出去，让更多人看到。