How to solve the blockchain infrastructure security problem while creating a dApp

The race for WEB3 has begun. Venture capitalists, cryptocurrency startups, engineers and visionaries are developing his WEB3 (or Web 3.0) powered by blockchain. A new frontier has been born that is more democratic, decentralized, independent and ideal for data recovery.

But is everything perfect when it comes to decentralization and infrastructure security? No, the numerous cases of man-in-the-middle attacks prove that.

But to solve the security problem, let’s remember what WEB3 is. The core concept of WEB3 is to solve the security problems caused by centralization and give people the power over their data and identity. So at what level of technology are these unfortunate security breach incidents occurring in blockchain infrastructure?

Technologies such as EVM, Solidity, and JavaScript still play a big role in focusing on the inner workings of WEB3. However, when discussing the backend functionality, we will use the Node provider and the WEB3 API provider.

node provider A company that allows you to use services instead of running nodes. This is very convenient. Because instead of setting up a node and going through all the stress and costs that come with it, you can send your dApp transaction requests over the internet to your node provider. If you are interested in developing smart contracts, you can use one or two node providers (for redundancy).

there are many WEB3 API provider; but, often these companies work with nodes behind the scenes. Applying these tools, you can get pre-compiled and computed data on-chain.

Additionally, you can easily establish reliable communication and interaction between different applications through these WEB3 APIs. Additionally, a high-quality API keeps your coding consistent and stable. Therefore, when writing applications, we mostly rely on the reliable WEB3 API.

💡 Difference between Node provider and WEB3 API provider: The WEB3 provider allows applications to communicate with blockchain nodes by sending JSON-RPC requests to the server. A node service provider runs a distributed node client in the background, allowing it to read and write to the blockchain using an API key.

What are the security threats for dApps developers?

Nodes are still a relatively primitive technology, but they are still valuable. For example, a WEB3 node cannot tell what a user has deposited into their account. Besides providing raw blockchain information, a node cannot process multiple smarthi contracts. Additionally, nodes have limited capabilities and can only handle one chain. Fortunately, we have an API to help you get around this limitation.

APIs define and standardize application interactions and allow the use of raw blockchain data. This is why the WEB3 API is useful for dApp development. WEB3 API is a key component in the development of dApps. It not only provides a simple interface, but also allows pieces of software to interact with other applications. A reliable API enables consistent coding in a stable environment, so dApp developers don’t have to start over.

Furthermore, by using these WEB3 provider APIs, you can easily link to nodes. So you don’t have to worry about connecting to a node when using these APIs. When interacting with these providers, you may also receive all sorts of valuable pre-computed and pre-compiled on-chain data.

However, such services do not fully address the needs of developers with a security plan, and in most cases must be paid upfront for their use.

In fact, more and more dApps are being hacked using the aforementioned man-in-the-middle attack.

This is when an attacker takes advantage of a vulnerability in (for example) a DNS server and switches the server to handle jsonrpc-endpoints traffic.

one known victim Lost 16.5 WBTC (~$350,840). Also, about 23 cryptocurrency projects have already encountered similar DNS attacks.

A very simple solution can protect you from such man-in-the-middle attacks. And back to this.

Also, having a development team allows you to try and build your own solution, but you need a highly skilled team of like-minded people to make it work.

The difficulty with this process is that you can greatly overestimate your strength. Even the seemingly simple task raises many questions, which are answered by many years of work experience. Therefore, if you have the time and resources, you should accept this path.

Violation of Three Key Blockchain Principles in WEB3

Let’s take a breather and look at the current security challenges in the WEB3 world from an infrastructure perspective.

The main principle of blockchain is

• decentralization
• Transparency
• Sense of distrust

But does it actually work?please see Most popular dApp architecture.

You can see that the frontend user is sending requests to a JSON-RPC provider (Infura, Alchemy, Quicknode, etc.).

As such, requests are routed to a shared environment where you have no control over data transformations in API gateways, cache engines, blockchain nodes, etc.

Here comes the first problem. Shared environment means especially many users, bots and hackers working in the same environmentThis is a true black box for developers that attracts too much attention from attackers.

This approach contradicts all three principles of WEB3 for the following reasons:

1. Centralize access to blockchain and pass everything to a shared environment.
2. Not transparent. Responses from such APIs cannot be validated.
3. Therefore, the security problem of such infrastructure is based solely on trust, not true distrust. Look at the following illustration.

The second issue is that the version of the infrastructure mentioned is Allows man-in-the-middle attacksregularly used by criminals.

The following services can be attacked:

• • Domain or DNS registrar
  • JSON-RPC provider
  • Third party aggregation services

A self-hosted cluster of blockchain nodes is the only solution

But is there any solution? Yes — configured on-premises environment.

First, use a self-hosted cluster of blockchain nodes. All nodes are initialized from official genesis and synced using p2p. This ensures data consistency.

Nodes should be refreshed regularly with reduced snapshots in order to run as efficiently as possible. The ideal solution would be to automatically create new nodes from the reduced snapshot when zooming. When initializing a node from scratch, this approach allows you to get a new node within 30 minutes instead of days.

Another key point is automatic updates of blockchain software after release. You can do this too. The main thing is to create a snapshot with the new version (which may require data manipulation and may take some time). A new node is then automatically started with the new snapshot and updated software.

Below is an infrastructure diagram that solves most of the problems described.

It is also important to monitor the sync state and exclude nodes behind upstream flows. This can be done using health checks, for example.

Besides the fact that you can restrict access by IP address, it’s also worth mentioning that good old JWT tokens can protect you from domain registrars and DNS attacks. JWT tokens can be easily integrated into web3js or other libraries and need to be implemented on the API gateway side of the blockchain cluster.

In this way, blockchain endpoints are secure and decentralized.

summary

Web3 is still in its early stages. But the decentralization race has already begun. We also find that the most secure applications are likely to use the most innovative and open source approaches.

So don’t ignore the basic principles of WEB3, as newly created dApps offer no security to other participants.The only option currently available is autonomous cluster of geographically distributed blockchain nodes.

author:

Daniel Javorovic

Co-founder and CTO of RPCFast and DISNIX