This article first appeared on GitHub:
https://github.com/slowmist/Web3-Project-Security-Practice-Requirements
Related links in this article can be opened in GitHub. Welcome to Watch, Fork and Star this article on GitHub.
Table of contents
Web3 project security practice requirements include the following:
0x00 Background Overview
Nowadays, attack methods against Web3 projects emerge in endlessly, and the interaction between projects is becoming more and more complex. The interaction between various projects often introduces new security issues, and most Web3 project R&D teams generally lack first-line security attack and defense experience. And when developing the Web3 project, the focus is on the overall business argument and the realization of business functions, and there is no more energy to complete the construction of the security system. Therefore, it is difficult to ensure that the Web3 project is in the entire Lifecycle security.
Usually, in order to ensure the security of the Web3 project, the project team will hire an excellent blockchain security team to conduct a security audit of its code. Only when the security audit is performed can various security practice requirements be better implemented, but blockchain security The team's audit is only a short-term guide, and it does not allow the project team to establish its own security system.
Therefore, the SlowMist security team has open sourced the security practice requirements of the Web3 project to continuously help the project teams in the blockchain ecosystem to master the security skills of the corresponding Web3 projects. It is hoped that the project teams can establish and improve their own security practices based on the Web3 project requirements. An advanced security system can also have certain security capabilities after the audit.
0x01 Development preparation
-
Requirements Analysis Documentation Requirements
1. Make sure to include a thorough description of the project
2. Make sure you include the problem your project solves
3. Make sure to include a security/privacy risk assessment
-
Development Design Documentation Requirements
1. Make sure to include an architectural design diagram of the project
2. Make sure to include a functional description of the functions in your code
3. Make sure to include a description of the relationship between the contracts in the code
4. Ensure security/privacy requirements are properly implemented
-
Business Process Documentation Requirements
1. Make sure to include a description of each business process in the project
2. Make sure to include a detailed business process diagram
3. Make sure to include a detailed funding link diagram
0x02 Development process
-
Smart Contract Secure Coding Requirements
1. Make sure to include development based on well-known libraries such as OpenZeppelin as much as possible
2. Make sure to include a compiler that uses SafeMath or 0.8.x to avoid most overflow problems
3. Make sure to follow the function naming convention, refer to: solidity style guide
(https://docs.soliditylang.org/en/v0.8.14/style-guide.html)
4. Make sure function and variable visibility are explicitly declared
5. Make sure function return values are explicitly assigned
6. Make sure that the function function and parameter comments are complete
7. Make sure that the return value of the external call is checked correctly, including: transfer, transferFrom, send, call, delegatecall, etc.
8. Make sure that the implementation of the parameter type and return value of the interface is correct
9. Ensure that the key parameters of the contract are authenticated and recorded using events
10. Ensure that the data structure of the new implementation contract of the upgradeable model is compatible with the data structure of the old implementation contract
11. Ensure that the logic involved in arithmetic operations in the code fully takes into account precision issues, avoiding the possible loss of precision caused by division first and then multiplication
12. Make sure that the target address and function of low level calls such as call are expected
13. When using call and other low level calls, limit Gas according to business needs
14. The coding standard is constrained, follow: judge first, then write variables, and then make external calls (Checks-Effects-Interactions)
15. Ensure that the external contracts that interact in the business are compatible with each other, such as: deflation/inflation tokens, ERC-777, ERC-677, ERC-721 and other reentrant tokens, refer to: reentrant vulnerability case
(https://medium.com/amber-group/preventing-re-entrancy-attacks-lessons-from-history-c2d96480fac3)
16. Make sure that external calls fully consider the risk of reentrancy
17. Avoid using a lot of loops to assign/read contract storage variables
18. Try to avoid the problem of excessive concentration of authority, especially the authority to modify the key parameters of the contract, separate authority, and use governance, timelock contract or multi-sign contract for management as much as possible
19. The inheritance relationship of the contract should maintain linear inheritance, and ensure that the inherited contract business needs
20. Avoid using block data on the chain as a seed source for random numbers
21. Ensure that the acquisition and use of random numbers fully consider the possibility of rollback attacks
22. Try to use Chainlink VRF to obtain reliable random numbers, refer to: Chainlink VRF
(https://docs.chain.link/vrf/v2/introduction)
23. Avoid using the number of tokens in third-party contracts to directly calculate the price of LP Token, refer to: How to correctly obtain the price of LP
(https://blog.alphaventuredao.io/fair-lp-token-pricing/)
24. Avoid a single price source when obtaining prices through third-party contracts. It is recommended to use at least 3 price sources
25. Use events to record execution status in key business processes as much as possible for data analysis when the project is running
26. Reserve the switch for the emergency suspension of the global and core business, so as to stop the loss in time when a black swan event occurs
-
Test case code requirements
1. Make sure to include business process/function functional usability testing
2. Ensure that the unit test coverage rate is more than 95%, and the core code coverage rate must reach 100%
-
Basic Security Configuration Requirements
1. Make sure that the official mailbox uses a well-known service provider, such as Gmail
2. Make sure that the official email account is forced to enable the MFA function
3. Make sure to use a reputable domain name provider such as GoDaddy
4. Make sure that the account of the domain name service provider platform has MFA security configuration enabled
5. Make sure to use a good CDN service provider like Akamai, Cloudflare
6. Make sure that DNSSec is enabled in the DNS configuration, set a strong password for the management account on the domain name service management platform and enable MFA authentication
7. Make sure all employees use anti-virus software on mobile phones and computer equipment, such as Kaspersky, AVG, etc.
-
Web front-end security configuration requirements
1. Ensure that the HTTP communication of the whole site adopts HTTPS
2. Make sure that HSTS is configured to prevent man-in-the-middle attacks, such as: DNS hijacking, BGP hijacking, refer to: HSTS configuration introduction
(https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security)
3. Make sure X-FRAME-OPTIONS is configured to prevent Clickjacking attacks, refer to: X-FRAME-OPTIONS configuration introduction
(https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options)
4. Make sure that X-Content-Type-Options is configured to combat risks caused by browser sniff behavior, refer to: X-Content-Type-Options Configuration Introduction
(https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options)
5. Make sure that the CSP policy is configured to prevent XSS attacks, refer to: Introduction to CSP Content Security Policy
(https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP)
6. Make sure that cookies related to permissions and user credentials are configured with HttpOnly, Secure, Expires, SameSite flags, refer to: Introduction to Cookie Configuration
(https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies)
7. Ensure that the subdomains of different businesses are strictly separated to avoid the XSS problems of subdomains affecting each other
8. Make sure that the referenced third-party resources are restricted using the integrity attribute to prevent the third party from being hacked and causing the project site to be affected. Refer to: Introduction to SRI Configuration
(https://developer.mozilla.org/zh-CN/docs/Web/Security/Subresource_Integrity)
9. Make sure that CORS is configured correctly, and only the specified origin domain, protocol and port are allowed to access the resources of the project. Refer to: Introduction to CORS Configuration
(https://developer.mozilla.org/zh-CN/docs/Web/HTTP/CORS)
10. Make sure that the addEventListener/postMessage implemented in the business has the origin and target of the check message, refer to: postMessage security introduction
(https://developer.mozilla.org/zh-CN/docs/Web/API/Window/postMessage)
-
Back-end environment security configuration requirements
1. Make sure to choose an excellent cloud server provider, such as: AWS, Google Cloud, etc.
2. Make sure that the cloud platform management account used by the project uses a strong password and enables MFA authentication
3. Ensure that the server is secured before the project code is deployed to the server, such as: install HIDS, use SSH Key to log in, set SSH login alert, set SSH login google-auth, etc.
4. Make sure to monitor service, server availability with professional software like APM, Zabbix
5. Make sure to use professional institutions to regularly test project security, such as SlowMist, Trail of Bits, etc.
0x03 release process
A complete security release process is required, which can be refined by referring to the following content:
-
Code Freeze Requirements
The estimated launch time is reversed by 2 days, that is, the code must be frozen and no code changes will be made 2 days before the launch
-
unit testing requirements
1. Ensure that the unit test coverage rate is above 95%, and the core code coverage rate is 100%
2. Make sure to output unit test coverage report
-
Regression Testing Requirements
Execute unit tests and run regression tests 1 day before going live
-
Test Report Requirements
0.5 days before the launch, the test report will be completed by the development and test together. If it fails (including unit test and regression test), the launch time will be postponed. After the development is completed and revised, it will re-enter the code freezing stage (that is, postponed for at least 2 days)
-
Security Audit Requirements
1. Security auditors enter the overall security regression after the code is frozen. If any loopholes or security risks (serious, high-risk, and medium-risk) are found, the online time will be postponed. )
2. The security audit requires at least three teams to conduct independent audits, and can use 1 internal team + 2 external teams
0x04 During operation
-
Runtime Security Monitoring
As much as possible, through events triggered in key business processes to discover security issues during project runtime, such as:
1. Change of key authority/parameters of the contract: monitor the events of the change of the management role, the event of the management role modifying the key parameters of the contract, and timely discover the situation that the private key may be stolen
2. Changes in contract funds: monitor price changes and changes in contract funds, and detect possible lightning loans and other attacks in a timely manner
3. Periodic reconciliation: Periodically reconcile the events and transactions on the chain to detect possible business logic problems in time
-
Operating environment security hardening
1. Make sure to implement security reinforcement on the server where the front-end code resides, such as: install HIDS (https://www.aliyun.com/product/aegis), use SSH Key to log in, set SSH login alert (https://medium.com /@alessandrocuda/ssh-login-alerts-with-sendmail-and-pam-3ef53aca1381), set up SSH login google-auth (https://goteleport.com/blog/ssh-2fa-tutorial/) etc.
2. Make sure that DNS Sec is enabled in the DNS configuration, set a strong password for the management account on the domain name service management platform and enable 2-factor authentication
3. Make sure that the cloud platform management account used by the project uses a strong password and enables 2 authentications
-
Release bug bounty program
Publish a bug bounty program or enter a well-known bug bounty platform to attract community white hats to escort the project; you can choose BugRap (https://bugrap.io/), code4rena (https://code4rena.com/), immunefi (https://immunefi.com/)
-
Formation of Nominal Emergency Response Team
Establish a nominal emergency team and provide contact information to the outside world. The emergency team is responsible for dealing with the problems discovered by the white hats or leading the team members to deal with the emergency when the black swan incident breaks out
0x05 Emergency treatment
-
Complete emergency handling process
Develop a complete emergency response process as much as possible, and deal with black swan events in an orderly manner according to the emergency response process
-
Stop Loss Disposal Requirements
1. According to the scope and degree of harm of the problem, timely stop the loss through the emergency stop switch
2. Notify community members of black swan events to avoid losses caused by users continuing to interact with the project
-
Hacker Tracking Requirements
1. Quickly analyze the hacker's profit-making address, and save the access log of the PC/Web/server (if there is a Trojan horse, please keep the Trojan horse file)
2. Take a snapshot of the server and keep the hacked site in time
3. Contact a professional security team to assist in tracking, such as: MistTrack tracking analysis platform (https://misttrack.io/), Chainalysis (https://www.chainalysis.com/)
-
fix problem request
1. Discuss the best fix for the issue with a professional security team
2. Correctly implement the fix and have a professional security team verify it
-
Security Release Requirements
Execute release process requirements to ensure that all code changes are tested and security audited
-
Review Analysis Requirements
1. Disclose post-mortem reports and synchronize fixes and remedies with community members
2. The autopsy report needs to synchronize the essential cause of the problem, the scope of the problem, the specific loss, the repair of the problem, the tracking of the hacker and other related progress
Summarize
Security is a dynamic management process, and relying only on short-term audits by third-party security teams cannot truly guarantee long-term safe and stable operation of the project. Therefore, it is very important to establish and improve the security system of the Web3 project. Only when the project team has certain security capabilities can it better guarantee the safe and stable operation of the Web3 project.
In addition, we suggest that the project team should also actively participate in the security community, learn the latest security attack and defense technologies and experiences, communicate and cooperate with other project teams and security experts, and jointly improve the security of the entire ecosystem. At the same time, strengthening internal safety training and knowledge popularization, and improving the safety awareness and capabilities of all employees are also important steps to establish and improve the safety system.
Finally, the security practice requirements of the Web3 project currently belong to the v0.1 version and are still being improved. If you have better suggestions, please submit feedback.