BNB Chain is one of the most popular blockchains in the Web3 world. Its reasonable fees, fast transactions, and rich project ecosystem attract a large number of users. As with any blockchain, developers on BNB Chain should first consider security issues during the development process: because any loss of funds will lead to a weakening of user confidence in the protocol and platform, and security vulnerabilities and hacker attacks are One of the biggest risks developers face.
In this article, we provide ten practical security tips so that developers can reduce risks and develop more secure smart contracts on the BNB Chain.
01
╱Definition ╱
Replay Attacks, also known as replay attacks and replay attacks, are a common type of attack in the blockchain environment. In network security, replay attack"” is a type of cyber attack in which valid data transmissions are maliciously or fraudulently repeated or delayed.
In the context of Web3 and smart contracts, this generally means that an attacker is able to repeat a transaction or action in a smart contract without the original users permission. This can lead to various forms of fraud such as double spending etc.
These attacks can have serious consequences for users and developers because they allow attackers to reuse the same signature to gain unauthorized access to all funds or other assets on the smart contract.
To prevent replay attacks, developers must carefully design and implement their smart contract code and follow signature verification as well as industry best security standards.
02
╱Case Analysis ╱
The following code snippet represents the transfer implementation process of a token on the BNB chain. The code is vulnerable to replay attacks, allowing an attacker to reuse the same signature.
This feature lacks nonce or replay protection, allowing an attacker to replay a signed transfer multiple times. An attacker can intercept a signed transaction and send it again to the same contract or another contract, and the contract will still consider it valid, so the attacker can exploit this vulnerability to steal assets.
03
╱Improvement methods ╱
Add a nonce to the signature or use a mapping variable to record the signature. The more specific solutions will vary depending on the project design.
01
╱Definition ╱
A reentrancy attack occurs when a malicious contract repeatedly calls a vulnerable contract before the initial call is completed. In other words, an attacker can trick a vulnerable contract into thinking it has completed one transaction and is free to move on to the next, but in reality it is still executing the attackers malicious code.
This could result in an attacker being able to manipulate the state of the contract in unexpected ways and potentially obtain unauthorized funds.
02
╱Case Analysis ╱
In the code snippet below, users can withdraw funds from their account by calling the withdraw function and specifying the amount they want to withdraw. However, since the withdraw function does not protect against recursive calls to the function, it is vulnerable to reentrancy attacks.
An attacker could exploit the vulnerability by creating a malicious contract that calls the withdraw function multiple times before the balance is actually debited from their account. The function msg.sender.call sends funds to the malicious contract, and the attacker drains all the funds of the victim contract by repeatedly withdrawing funds through the malicious contracts receive() function before its balance is reduced to zero.
03
╱Improvement methods ╱
State updates are made before any external calls.
This pattern is called the Check-Effects-Interact pattern and is a design pattern used to prevent reentrancy attacks in smart contracts. This pattern separates state changes from external calls to other contracts by first checking preconditions and then updating the state before making any external calls. This way, if an external call triggers a callback that attempts to call back to the contract, but the state has already been updated, other unexpected effects are prevented.
By following this pattern, developers can ensure that their contracts are more secure and less susceptible to reentrancy attacks.
Another possible fix is to use a modifier to limit multiple calls to the same function, much like OpenZeppelins ReentrancyGuard.
01
╱Definition ╱
Oracles can help smart contracts retrieve information from outside the blockchain. Usually the price of a decentralized exchange (DEX) asset is determined by the price extracted by the oracle from the last successful transaction on the DEX.
However, the problem is that the price can be easily manipulated by anyone, causing problems with the smart contract. We often see cases of price oracles being manipulated through flash loans. The reason is that flash loans allow users to borrow huge amounts of money without collateral as long as they repay the loan within the same block. This makes it easy for attackers to influence or even manipulate prices, profiting from false liquidations, excessive lending, or unfair trading.
02
╱Case Analysis ╱
Below is a code snippet that is vulnerable to oracle manipulation attacks.
This contract allows users to swap Token A for Token B using a routing contract, but it relies on an external oracle (Uniswap Pair Contract) to get the reserves of Token A and Token B to calculate the price. An attacker was able to manipulate the reserves of the Uniswap Pair contract as well as the getAmountOut function, ultimately causing the swap to be executed at an unreasonable price.
03
╱Improvement methods ╱
To prevent this attack, developers should use a decentralized oracle network that captures volume-weighted average price (VWAP) or time-weighted average price (TWAP) on-chain for centralized and decentralized exchanges. This way, data is collected from multiple sources and over a wide range of time, making the code less vulnerable to attack and manipulation. It is important for developers to be able to remove any attack vectors for manipulating oracles in smart contracts to prevent potential vulnerabilities.
01
╱Definition ╱
Properly setting the visibility of functions ensures the security and integrity of smart contracts. Using incorrect function visibility settings can allow unintended users to manipulate contract state, leading to serious issues such as stolen funds or controlled contract functionality.
By setting the visibility of functions to private or internal, you can ensure that developers have limited access to certain functions, and only authorized parties can call these functions. Private functions can only be called from the contract itself, while internal functions can also be called from inheriting the current contract. This allows developers to create more powerful and complex contracts while maintaining control over access to functionality.
02
╱Case Analysis ╱
The function setAdmin() allows anyone to set any address as the contract administrator. Depending on the permissions granted within the contract to manage addresses, this could result in the developer losing control of the contract itself or even losing funds.
Some contract functions internally may allow certain users to be set as administrators by setting the visibility of the function to internal.
03
╱Improvement methods ╱
Access modifiers are an important security feature that dictate who can access specific functions or variables in a contract. These modifiers can be used to restrict the visibility of certain functions or variables to specific roles or addresses, and prevent malicious actors from gaining unauthorized access or manipulating the contract state.
For example, a contract might have a function that only the contract owner can call, or a variable that can only be accessed by a certain set of addresses.
By changing the visibility modifier to external and setting the access modifier to onlyOwner, access to the setAdmin function can be limited to the address of the contract owner. This will prevent malicious external parties from taking control of certain privileged functions.
Proper use of visibility and restriction modifiers can make contract management easier and reduce common attacks such as reentrancy attacks (where the attacker repeatedly calls a function to manipulate the state of the contract) or run-ahead attacks (where the attacker monitors pending transactions and manipulating the contract state before legitimate transactions are executed).
By using these features appropriately, developers can enhance their contract security and reliability, reduce the risk of unauthorized access, and improve the overall quality and maintainability of their code.
01
╱Definition ╱
When deciding whether to upgrade a contract in the future, it is important to carefully consider the design of the contract initially. Contract upgradeability refers to the property that the logic of a smart contract can be modified or updated after it is deployed on the blockchain. While upgradability can provide many advantages (such as fixing bugs, improving efficiency, or adding new functionality), it also introduces some risks. Contract upgrades may introduce new vulnerabilities, increase contract complexity, or cause unintended consequences.
Contract upgradeability also raises trust issues because agent administrators can upgrade contracts without community consensus. Developers need to carefully weigh the advantages and disadvantages of upgradability and determine whether the introduction of upgradable contracts is truly necessary for their project. In some cases, it is safer to design a contract that is immutable from the start rather than relying on the ability to modify it later.
02
╱Improvement methods ╱
When it comes to contract upgradeability, there are several important practices to follow. First and foremost, dont modify the proxy library. The Proxy contract library is extremely complex, especially in terms of storage management and upgrade mechanisms. Even small errors can significantly affect the operation of Proxy and logic contracts. In fact, many of the proxy-related severity errors found during the audit were caused by inappropriate modifications to the proxy library.
Another key aspect of contract upgradeability is the inclusion of a storage gap in the base contract. Logic contracts must include a storage gap in the contract code to account for new variables that may be introduced when deploying new logic implementations. After adding new state variables, it becomes more important to update the size of the gap. This practice ensures that future upgrades will run smoothly without issues.
Finally, using selfdestruct() or doing delegatecall()/call() to untrusted contracts must be avoided. An attacker can exploit these functions to subvert the logic implementation or execute custom logic. To prevent this, its important to validate the users input! Do not allow contracts to perform delegatecall()/call() on untrusted contracts. Also, it is not recommended to use delegatecall() in logic contracts because managing storage layout across multiple contracts would be difficult. By following these practices, developers can minimize bugs and risks in their contract upgrades.
01
╱Definition ╱
Front-running has always been a stubborn and difficult-to-solve problem, where users are able to profit from the delay between submitting a transaction and confirming it on the blockchain. This delay is caused by mempool.
The mempool is a temporary storage area for unconfirmed transactions that have been broadcast to the network. All nodes in the network maintain a mempool that allows anyone to see pending transactions and potentially intercept them to profit from them. Mempool also offers miners an opportunity to rearrange transactions to maximize their profits, creating what is known as miner (or maximum) extractable value (MEV).
02
╱Case Analysis ╱
Below is an example of an auction bidding feature that is prone to front-running.
This feature allows users to place bids in auctions, but it can be vulnerable to front-running attacks. Suppose a malicious user monitors the blockchain and sees that another user has submitted a high bid. The malicious user can quickly submit a higher bid and be prioritized, ultimately winning the auction.
In the following version, users submit unknown bid prices, and these bids are stored in a mapping. Bid amounts are encrypted until the end of the bidding period.
03
╱Improvement methods ╱
At the end of the bidding period, users can reveal their bid by submitting the original bid amount and a secret value. The contract verifies that the bid amount and secret hash match the stored secret bid, ensuring that the bid was submitted before the end of the auction period. If that bid is higher than the current maximum bid, it becomes the new maximum bid. This feature mitigates front-running attacks by masking bid amounts until the end of the auction period.
Front-running and MEV have become major concerns in the blockchain community, and various solutions, such as transactions and Fair Ordering Services (FSS), have been proposed to address these issues. Transactions can help prevent front-running by hiding transaction details from other users until the transaction is executed on the blockchain. On the other hand, FSS can reduce the impact of front-running transactions and MEV through secure off-chain transaction ordering.
Having a clear and comprehensive response plan in place is critical to dealing with emergency security incidents. The plan should be regularly reviewed, updated, and tested for effectiveness. When it comes to emergency security incidents, time is of the essence. Therefore, the plan should be customized in advance and include detailed operational steps such as identification, control and sustained release.
The plan should be effectively in place and keep all stakeholders informed. At the same time, regular backup of data is also important to prevent data loss. The plan outlines the recovery process for restoring data and systems to their previous state. Team members should receive systematic training on the program to ensure everyone understands their roles and responsibilities.
A well-prepared response plan may not be able to fix the problem, but it can minimize the impact of the incident and maintain trust with users and stakeholders.
Regular code auditing is critical to maintaining application security. Working with professional auditors who specialize in smart contract security is an important step in the development process. Auditors will check for vulnerabilities in the code and provide recommendations for improving overall security.
Prioritizing and addressing identified issues and maintaining open communication with auditors is critical to improving security.
In addition to this, communication with auditors is also critical. Auditors can explain in detail the issues and vulnerabilities they found, and provide guidance and practical help on how to resolve the vulnerability. By cooperating with professional audit institutions/personnel, security will be raised to the next level.
For developers of the BNB chain, conducting regular audits is an integral part of any comprehensive security strategy. Proactively identifying and addressing vulnerabilities in your code minimizes the risk of security breaches.
Using a bounty program is an effective way to incentivize a community of white hat hackers to report security vulnerabilities in a projects code. By providing incentives such as tokens or other rewards, any project can encourage experienced people to review the code and report any potential problems they find.
It is important to have a clear and transparent bug bounty program. The plan needs to include: what types of vulnerabilities are found to be eligible for rewards, how to evaluate the value of these vulnerabilities, etc. At the same time, including a credible third party in a bug bounty program can help ensure the smooth running of the program and the fair distribution of rewards.
At the same time, it is also important to have a diverse group of bounty hunters. Different white hat hackers have different areas of expertise and can focus on finding problems that others may miss.
Finally, once vulnerabilities are reported, action must be taken quickly and efficiently to address them. Bounty programs can be an effective tool for identifying vulnerabilities, but it has to be up to the development team to actually fix the issue to be meaningful.
Security education for Web3 users is a critical step in building a security ecosystem. Keeping customers safe helps keep the platform safe. Users should be educated about best practices for protecting their accounts and sensitive information.
One of the most important parts is learning how to avoid phishing scams.
Phishing scammers will deceive users by posing as legitimate websites or services, causing users to disclose private keys or passwords. CertiK recommends that users always double-check any email, source, etc. website URL being used when receiving any information, and never enter private keys or passwords on untrusted websites.
Another important part is having a secure and strong password. CertiK hereby advises users to use unique and complex passwords for each account and to avoid reusing passwords across different services. Also, use a password manager or other secure storage mechanism to securely store passwords.
Finally, protecting private keys is extremely important. The private key is equivalent to the users password, and should be guaranteed not to be accessed by others at any time. Users should refrain from sharing their private keys with anyone and store them in a safe place.
Summarize
Developers building smart contracts and dApps on BNB Chain must take a comprehensive security approach to keep their users funds and assets safe. Whats more important is to be proactive rather than reactive when dealing with security breaches; have a plan in place when or even before a breach occurs, and provide appropriate security education to all relevant users and stakeholders. By combining all of the above measures, it can help projects greatly reduce the risk of security breaches and hacking attacks.
