Shulou(Shulou.com)06/01 Report--

This article introduces how to ensure the security of DApp local storage localStorage in Ethernet Square. The content is very detailed. Interested friends can use it for reference. I hope it will be helpful to you.

Deploying a decentralized application, dapp, introduces some interesting security considerations that may not occur in more traditional development. How can we ensure the security of dApp local storage?

The reason for this problem is that we encounter an important obstacle when using Colony dApp, that is, how to deal with the dApp data security challenge of maintaining local storage using distributed storage systems such as IPFS or Swarm.

I'll look at this problem from the perspective of dApp developers, and then look at some possible solutions.

The problem of sharing local storage localStorage

IPFS runs the local node node, which is bundled with the Web server. Bundled Web servers make it easy for nodes to connect to each other and share data that may be needed elsewhere in the network.

As a decentralized application builder, you will rely on the Web server to push your content from one node to another, making it available to end users immediately as needed.

Assuming that you are completely decentralizing full decentralized and are avoiding using anything such as DNS or Web proxies to track the location of your content on the network, the way to access dApp is usually to query local node hashes through a browser, such as:

Http://localhost:8080/QmcefGgoVLMEPyVKZU48XB91T3zmtpLowbMK6TBM1q4Dw/

Now, suppose that during normal use, your application will save data in the browser's localStorage: you may need to pass some data, or maintain a queue of local user interaction to minimize chain transactions and save gas costs.

Local storage in the browser is limited to a specific address context (domain and port). The IPFS node acquires this context, which means that any decentralized application running through the IPFS Web server will use the same localStorage with read and write access.

This could be a big problem.

By default, some helper dependencies of dApp use localStorage to temporarily save the key in plain text. These data should not be seen one day.

Another potential leak problem is the package that saves its memory state so that it can be recovered later. Libraries like Flux-like are usually (relatively) safe because they only run in memory, but enabling persistence state puts that memory state into localStorage, opening it to potential attackers.

Strategies to alleviate the problem

Unfortunately, there is no panacea for security: as a dApp developer, any adjustments made for security reasons may require some concessions in other aspects of development.

Here are some compromises you can make:

Do not store any data

This is certainly the safest way, but it's kind of like burning down your house to get rid of cockroaches. There are many functions and basic behaviors in the dApp where data is stored locally, and it may not make sense for the application to exist after deleting too much.

In addition, there are many libraries that use localStorage by default, and you must manually check each dependency and delete any libraries that need it, or you will have to modify the library yourself.

Encrypting everything is theoretically more promising, especially since most dApp developers already keep the default encryption on Kanban.

Encrypted local storage value

In fact, encrypting all local storage is a bit of a hassle. To encrypt data, you must have a key: but the user cannot store the key in dApp because it will be placed in localStorage, and in doing so you will go back to where you started.

One solution is to use wallets: your dApp may interact with the blockchain in some way, asking users to unlock their wallets to send and sign transactions. Since you need the wallet to interact with dApp anyway, you can use the private key privatekey of each account to encrypt the local storage.

However, there are some drawbacks:

Every time you want to interact with localStorage, you must ask the user for the plain text private key.

Key management software like MetaMask doesn't work because it never exposes a user's private key.

Using Swarm and Mist

Mist is built as a dApp and ethernet square browser, so it provides some special advantages for this problem.

By default, Mist supports Swarm's bzz protocol, so you can set a hash of an ens address that points to dApp, and then use Mist to browse your dApp without worry.

Unfortunately, this will only solve the problem of users accessing dApp through Mist.

Users running local Swarm nodes must still be accessed through localhost, and localhost still (possibly) leaks data to other dApp.

Create a browser extension for your dApp

Running your application through a browser extension will cause it to get a separate context (it will no longer be in localhost:8080), but it somewhat weakens the purpose of decentralized applications and must rely on central authorities such as the Chrome online Store for management and distribution.

In addition, you must now create and maintain separate extensions for each browser you want to support and update them through its own specific centralized app store. I'm not happy.

Create a stand-alone desktop application

As before, creating a stand-alone application is a way to separate dApp from its own context, which means it will get its own wrapper (in this case, electron).

Stand-alone desktop applications have the added benefit of bundling external libraries with any other content you may need, including separate instances of IPFS itself.

As said before, there must be some concessions:

Unless you want to distribute applications exclusively on bittorrent, you need to find a centrally hosted solution for distribution and maintenance.

You must maintain a separate repository for electron desktop applications.

If you want to use IPFS for any other service, you may end up running multiple nodes on the same computer, which can become confusing.

Proxy your application to the domain name

By using another Web server to proxy the local node, there are two advantages:

First of all, now your dApp has a friendly human-readable address instead of a lengthy hash. Second, your application will have its own context and will not share localStorage.

However, agents do move beyond "real" decentralization, and users will once again have to rely on a central server to access decentralized services. Hey.

For decentralized application developers, it is still in the early stages. This problem is ubiquitous in the emerging "decentralized protocol stack": and it may take a while before we come up with a more elegant solution.

In the future, supporting native IPFS or Swarm nodes in browsers will solve this problem without bundling the Web server with decentralized file storage. Users can enter something like ipfs://QmcefGgoVLMEPyVKZU48XB91T3zmtpLowbMK6TBM1q4Dw/ and access the dApp directly, assigning their own context to each unique hash.

On how to ensure the security of DApp local storage localStorage in Ethernet Square is shared here. I hope the above content can be helpful to you and learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.