The race for WEB3 is on. Venture capitalists, cryptocurrency startups, engineers and visionaries are developing WEB3 (or Web 3.0) powered by blockchain. A new frontier emerged, more democratic, decentralized, independent and ideal for data recovery.
But is everything so perfect when it comes to decentralization and security of infrastructures? No, and countless cases of man-in-the-middle attacks are proof of 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 authority over their data and identification. So at what technology level are these unfortunate incidents of security breaches happening in your blockchain infrastructure? Let’s figure it out.
To focus on the internal aspects of WEB3, technologies such as EVM, Solidity and JavaScript still play a major role. However, we use Node providers and WEB3 API providers when discussing backend functions.
Node providers are companies that allow you to use their services instead of managing your nodes. This is very useful because instead of setting up your node and experiencing all the stress and costs that come with it, you can send your dApp transaction requests over the internet to the node provider. If you are interested in smart contract development, you can use one or two node providers (for redundancy).
There are many WEB3 API providers; However, in many cases these companies work with nodes behind the scenes. With these tools applied, you can get all the pre-compiled and pre-calculated data in the chain.
In addition, it is easy to establish reliable communication and interaction between different applications through these WEB3 APIs. In addition, quality APIs ensure that the coding remains consistent and stable. That’s why we rely most on reliable WEB3 APIs when building applications.
Difference between Node providers and WEB3 API providers: The WEB3 provider allows your application to communicate with a blockchain node by making JSON-RPC requests to a server. Node service providers run distributed node clients behind the scenes, letting them write to and read from a blockchain using an API key.
What is the security threat to dApps developers?
Nodes are still relatively primitive technologies, but they are still valuable. For example, a WEB3 node cannot tell you what users have deposited into their accounts. Beyond simply providing raw blockchain information, nodes cannot process multiple smart contracts. In addition, nodes have limited capabilities and can only process one chain. Fortunately, APIs are available to help you get around this limitation.
APIs define and standardize application interactions so you can use raw blockchain data. This is why WEB3 APIs are useful for dApp development. WEB3 APIs are a key component in dApp development; they not only provide a simple interface, but also allow a piece of software to communicate with other applications. Because reliable APIs enable consistent coding in a stable environment, dApp developers don’t have to reinvent the wheel.
In addition, by using these WEB3 provider APIs, you can easily link nodes. Therefore, you don’t have to worry about connecting to nodes when using these APIs. When you interact with these providers, you may also receive a variety of valuable pre-calculated and pre-compiled on-chain data.
But such services do not completely exclude developers’ requests in the security plans, and in most cases you have to pay upfront for using them.
The fact is that there are more and more cases where dApps are hacked using the man-in-the-middle attack mentioned above.
This is when an attacker, using vulnerabilities in DNS servers (for example), switched servers to serve traffic from jsonrpc endpoints.
One victim is known have lost 16.5 WBTC (~$350,840). And about 23 cryptocurrency projects have already encountered a similar DNS attack.
With a very simple solution, you can protect yourself against such man-in-the-middle attacks. And we will come back to this.
And if you have a development team, you can go your own way and try to build your solution, but you need a super-skilled team of like-minded people to make it work.
The difficulty of this process is that you can significantly overestimate your strength. A task that seems simple then raises many questions, which are solved by years of experience in one’s work. Therefore, if you have a lot of time and resources, you should accept this path.
Violation of 3 major blockchain principles in the WEB3
So now let’s take a deep breath and look at the current security challenges in the WEB3 world from an infrastructure perspective.
The main principles of blockchain are
- decentralization
- transparency
- trustlessness
But does it work in practice? Have a look at the most popular dApp architecture.
We can see users on the front end sending requests to JSON-RPC providers (could be Infura, Alchemy, Quicknode, etc.).
So the requests are forwarded to a shared environment where we have no control over the data transformation at the API gateway, caching engine, blockchain nodes or anything else.
And this is where the first problem arises because a shared environment means that many users, especially bots and hackers, work in the same environment. This is a real black box for the developer that draws too much attention from attackers.
Well, this approach contradicts all 3 principles of WEB3 because:
- It centralizes access to the Blockchain, with everything passing through a shared environment;
- It’s not transparent – we can’t verify the answers from such an API;
- Therefore, it cannot be called true distrust, as the security problems of such an infrastructure are simply based on trust. See for yourself in the following diagram.
The second problem is that the described infrastructure version enables man-in-the-middle attacksthat criminals periodically use.
The following services can be attacked:
-
- Domain or DNS registrars
- JSON-RPC providers
- All aggregated third-party services
A self-hosted cluster of blockchain nodes is the only solution
But is there a solution? Yes — configured on-premises environment.
First, it uses a self-hosted cluster of blockchain nodes. All nodes are initialized from the official genesis and synchronized using p2p. This ensures data consistency.
Nodes should be periodically updated with fewer snapshots to run at peak efficiency. The ideal solution is to automatically create new nodes from the resized snapshot while zooming. If you initialize the node from scratch, this approach can get you a new node in 30 minutes instead of several days.
Another critical point is the automatic update of the blockchain software after its release – this can also be done. The most important thing is to take a snapshot with the new version (as sometimes it may require some data operations, which may take some time), and then the new nodes should automatically start 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 status and exclude the nodes that are behind the upstream stream. This can be done, for example, with the help of health checks.
In addition to the fact that access can be restricted by IP address, it’s worth noting that the good old JWT token can protect against domain registrars or DNS attacks. JWT token is easy to integrate into web3js and other libraries and must be deployed on the API gateway side in our blockchain cluster.
In this way we make the blockchain endpoint secure and decentralized.
Sum up
Web3 is still in its infancy. But the race for decentralization has already begun. And you will see that the most secure applications are probably the most innovative and open-source approaches.
And that’s why you shouldn’t ignore the basics of WEB3, because then your newly created dApp won’t provide security to other participants. The only option currently available is one autonomous cluster of geo-distributed blockchain nodes.
Author:
Daniel Yavorovich
