Why Is the Security of Blockchain Bridges Crucial?

Blockchain bridges are responsible for holding the tokens that users wish to transfer from one chain to another. These bridges are typically deployed in the form of smart contracts, and as cross-chain transfers increase, they accumulate a significant amount of tokens, making them prime targets for hackers.

Given that blockchain bridges involve multiple components, their attack surface is relatively large. Consequently, hackers are highly interested in cross-chain applications, seeking to extract substantial funds from them.

Estimates indicate that losses resulting from blockchain bridge attacks can be considerable, often accounting for a significant portion of total losses in a given year.

Common Security Vulnerabilities in Cross-Chain Bridges

To enhance the security of blockchain bridges, it is essential to understand common security vulnerabilities associated with cross-chain bridges and to conduct thorough testing before deployment. These vulnerabilities typically arise from several key areas:

Insufficient On-Chain Validation

For some simpler blockchain bridges, particularly those designed specifically for certain decentralized applications, on-chain validation is often minimal. These bridges rely on centralized backends to perform basic operations such as minting, burning, and token transfers, with most validations occurring off-chain.

Other types of bridges utilize smart contracts for on-chain validation. In these cases, when users deposit funds, the smart contract generates a signed message and returns it as proof of the deposit. This process aims to prevent various security attacks, such as replay attacks and forged deposit records.

However, if there are vulnerabilities in the on-chain validation process, it could lead to significant losses. For example, if a blockchain uses a Merkle tree to verify transaction records, an attacker might generate a forged proof to bypass validation and mint new tokens in their account.

Certain blockchain bridges adopt the concept of "wrapped tokens." For instance, when a user transfers a token from one chain to another, the token is withdrawn from the contract on the source chain, and a corresponding wrapped token is issued on the target chain.

If this transaction fails to verify correctly, an attacker could deploy a malicious contract to manipulate the functions, transferring the wrapped tokens to an incorrect address.

Token Approval Issues

Attackers also need users to approve the cross-chain bridge contract first, allowing them to use the "TransferFrom" function to transfer tokens and steal assets.

Many cross-chain bridges require users to grant unlimited approval for tokens. While this practice can reduce transaction fees, it introduces additional risks, as the smart contract can access unlimited tokens in the user's wallet. Attackers may exploit these insufficient validations and excessive approvals to transfer tokens from other users' accounts to their own.

Insufficient Off-Chain Validation

In some cross-chain bridge systems, off-chain backend servers play a crucial role in verifying the legitimacy of messages coming from the blockchain. Particular attention needs to be given to the validation process for deposit transactions.

The operation of these bridges can be summarized as follows:

Users interact with a decentralized application (dApp) and deposit tokens into a smart contract on the source chain.

The dApp then sends the hash of the deposit transaction to the backend server via an API.

This transaction hash undergoes multiple validations; if deemed legitimate, a signer will sign a message and return the signature to the user interface through the API.

Upon receiving the signature, the dApp verifies it and allows the user to withdraw tokens from the target chain.

The backend server must ensure that the deposit transactions it processes are genuine and not forged. Since it determines whether users can withdraw tokens on the target chain, the backend server becomes a primary target for attackers.

The backend server must validate the structure of the transaction initiation event and the contract address that initiated it. If these details are overlooked, attackers may forge legitimate deposit events through malicious contracts.

If the backend server fails to verify the address that initiated the event, it might mistakenly consider it a valid transaction and sign the corresponding message. Attackers could then send transaction hashes to the backend server, bypassing validation and successfully withdrawing tokens.

Improper Handling of Native Tokens

Cross-chain bridges employ different methods when dealing with native tokens versus utility tokens. For instance, in certain networks, native tokens represent specific tokens, while most utility tokens adhere to particular standards.

When a user wants to transfer their native tokens to another chain, they must first deposit them into the cross-chain bridge contract. The user simply attaches the tokens to the transaction, and the cross-chain bridge contract can retrieve the token amount by reading the relevant fields.

Depositing utility tokens differs significantly from depositing native tokens. When depositing utility tokens, users must first authorize the cross-chain bridge contract to use their tokens. After user approval, the contract will process the transfer using either the burnFrom() or transferFrom() functions.

To distinguish between these two operations, conditional statements can be used within the same function, or separate functions can be created for each case. However, due to the differing handling methods, if users attempt to use the utility token deposit function to deposit native tokens, it may lead to token loss.

When processing utility token deposit requests, users typically need to provide the token address as an input parameter. This practice carries risks, as untrusted external calls may arise during the transaction process. Implementing a whitelist strategy—only allowing supported tokens to be listed—is a common method to mitigate risks. Only addresses on the whitelist can be passed as parameters, thereby preventing external calls.

However, handling the cross-chain transfer of native tokens complicates matters since native tokens do not have an address. Native tokens can be represented by a special address known as the "zero address." If the whitelist validation logic is not correctly implemented, using the zero address as a parameter may bypass validation.

When the cross-chain bridge contract calls TransferFrom to transfer user assets to the contract, external calls to the zero address will return false, as that address does not implement the transferFrom function. However, if the contract does not handle this return value correctly, the transaction may still proceed, providing attackers with an opportunity to execute transactions without actually transferring any tokens to the contract.

Misconfiguration

In many blockchain bridges, specific roles are assigned to whitelist or blacklist tokens and addresses, allocate or change signers, and manage other critical configurations. Ensuring the accuracy of all configurations is vital, as even seemingly minor oversights can lead to significant losses.

In fact, there have been incidents where misconfigurations allowed attackers to successfully bypass transfer record validations. Before one particular hacking incident, the project team conducted a protocol upgrade that modified a default variable used to denote trusted messages. This change caused all messages to be automatically considered verified, enabling attackers to easily submit any message for validation.

How to Improve the Security of Cross-Chain Bridges

The four common vulnerabilities mentioned above highlight that the security challenges in an interconnected blockchain ecosystem should not be underestimated. To effectively address these vulnerabilities, a case-by-case analysis is necessary, as there is no one-size-fits-all solution.

For example, since the validation requirements vary for each cross-chain bridge, it is difficult to provide universal guidelines to ensure the correctness of the validation process. The most effective way to prevent validation bypasses is to conduct comprehensive testing against all potential attack vectors and ensure the soundness of the validation logic.

In summary, rigorous testing against potential attacks is essential, with particular attention paid to the most common security vulnerabilities in cross-chain bridges.

Conclusion

Given the substantial funds involved, cross-chain bridges have long been prime targets for attackers. Builders can enhance the security of cross-chain bridges by conducting thorough pre-deployment testing and incorporating third-party audits, thereby reducing the risk of catastrophic hacks that have occurred in recent years. Cross-chain bridges are critical in a multi-chain environment, but security must always be prioritized when designing and constructing effective Web3 infrastructure.