Advertisement
The race for WEB3 has begun. Venture capitalists, cryptocurrency startups, engineers, and visionaries are developing WEB3 (or Web 3.0) with blockchain technology. A new frontier emerged, more democratic, decentralized, independent and ideal for data recovery.
But, is everything so perfect in terms of decentralization and infrastructure security? No, and numerous cases of man-in-the-middle attacks are proof of this.
But to solve the security issue, let’s remember what WEB3 is. The core concept of WEB3 is to solve security problems caused by centralization and give people authority over their data and identification. So at what level of technology do these unfortunate incidents of security breaches in your blockchain infrastructure occur? Let’s find out.
In order to focus on the internal aspects of WEB3, technologies such as EVM, Solidity and JavaScript still play an important role. However, we use node providers and WEB3 API providers when we talk about the back-end functions.
node providers they are companies that let you use their services instead of running their nodes. This is very convenient because instead of setting up your node and experiencing all the stress and expense that comes 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; howeverIn many cases, these companies work with nodes behind the scenes. With these tools applied, you can get any precompiled and precomputed data in the string.
Furthermore, it is easy to establish reliable communication and interaction between different applications through these WEB3 APIs. Additionally, quality APIs keep coding consistent and stable. Therefore, we rely more on trusted 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 sending JSON-RPC requests to a server. Node service providers run distributed node clients behind the scenes and allow them to write to and read from a blockchain using an API key.
What is the security threat for dApp developers?
Nodes are still relatively primitive technologies, but they are still valuable. For example, a WEB3 node cannot tell you what users have deposited in their accounts. Apart from simply providing raw blockchain information, nodes cannot process multiple smart contracts. Also, nodes have limited capabilities and can only process one string. Fortunately, there are APIs available to help you get around this limitation.
APIs define and standardize application interactions, allowing you to use raw blockchain data. This is the reason why WEB3 APIs are useful for dApp development. WEB3 APIs are a key component in dApp development; In addition to offering a simple interface, they allow a piece of software to interact with other applications. Because trusted APIs allow for consistent coding in a stable environment, dApp developers don’t need to reinvent the wheel.
Also, by using these WEB3 provider APIs, you can easily link to nodes. So you don’t have to worry about connecting to nodes when using these APIs. By interacting with these providers, you can also receive all kinds of valuable on-chain pre-compiled and pre-compiled data.
But such services do not completely close developer requests in security plans, and in most cases you have to pay upfront for their use.
The fact is that there are more and more cases of dApps being hacked using the man-in-the-middle attack that we mentioned above.
This is when an attacker, using vulnerabilities in the DNS servers (for example), changed the servers to serve traffic from jsonrpc endpoints.
It is known that a victim they have lost 16.5 WBTC (~$350,840). And around 23 cryptocurrency projects have already encountered a similar DNS attack.
A very simple solution allows you to protect yourself from such man-in-the-middle attacks. And we will come back to this.
Also, 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 easy raises many questions, which are solved by many years of work experience. Therefore, if you have a lot of time and resources, you should accept this path.
Violation of 3 main principles of blockchain in WEB3
So let’s take a breath now and look at the current security challenges in the WEB3 world from an infrastructure perspective.
The fundamental principles of blockchain are
- decentralization
- transparency
- lack of trust
But does it work in practice? Take a look at the most popular dApp architecture.
We can see that users on the front-end are sending requests to JSON-RPC providers (this could be Infura, Alchemy, Quicknode, etc.).
So the requests are routed to a shared environment where we have no control over the data transformation in 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, bots and hackers in particular, work in the same environment. This is a true black box for the developer that attracts too much attention from attackers.
Well, this approach contradicts the 3 principles of WEB3 because:
- Centralizes access to the Blockchain, passing everything through a shared environment;
- It’s not transparent: we can’t verify responses from that API;
- Therefore, it cannot be called true mistrust as the security problems of such infrastructure are simply based on trust. See for yourself in the following diagram.
The second problem is that the infrastructure version described allows man-in-the-middle attacksthat criminals use regularly.
The following services can be attacked:
-
- Domain registrars or DNS
- JSON-RPC Providers
- Any third-party add-on services
A self-hosted cluster of blockchain nodes is the only solution
But is there a solution? Yes: locale configured.
First, it uses a self-hosted cluster of blockchain nodes. All nodes are initialized from the official genesis and synchronized via p2p. This ensures data consistency.
Nodes need to be regularly updated with reduced snapshots to run as efficiently as possible. The ideal solution is to automatically create new nodes from the reduced snapshot when zoomed. If you seed the node from scratch, this approach allows you to get a new node in 30 minutes instead of several days.
Another critical point is the automatic updating of the blockchain software after its release; this can also be done. The main thing is to create a snapshot with the new version (as it can sometimes require some data operations, which can take 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 synchronization status and exclude those nodes that are behind the upstream. This can be done, for example, with the help of health checks.
Besides the fact that access can be limited by IP address, it’s worth mentioning that the old JWT token can protect against domain registration or DNS attacks. The JWT token is easily integrated into web3js and other libraries and should be implemented on the API gateway side of our blockchain cluster.
In this way, we make the blockchain endpoint secure and decentralized.
summarizing
Web3 is still in its early stages. But the race for decentralization has already begun. And you’ll see that the most secure applications are likely to be the ones that use the most innovative and open source approaches.
And therefore you should not ignore the basic principles of WEB3 because then your newly created dApp will not provide security to other participants. The only option currently available is a autonomous cluster of geographically distributed blockchain nodes.
Author:
daniel yavorovich
Co-Founder and CTO at RPCFast and disnix
