SlowMist: Web3 Project Security Practice Requirements

The SlowMist security team has open-sourced the Web3 Project Security Practice Requirements, which provides detailed practice requirements and recommendations to help Web3 project development teams identify and prevent potential security risks. Web3 project teams can refer to the security practice requirements provided in this article, master the corresponding security skills, improve the security of Web3 projects, and better protect the asset security of projects and users.

This article was first published on GitHub:

https://github.com/slowmist/Web3-Project-Security-Practice-Requirements

The related links in the article can be accessed on GitHub. Everyone is welcome to read, share, and save this article through GitHub.

The Web3 Project Security Practice Requirements include the following content:

0x00 Background Overview

At present, attacks against Web3 projects emerge in an endless stream, and the interactions between projects are becoming more and more complex. The interaction between various projects often introduces new security issues, and most Web3 development teams generally lack experience in cutting-edge security attack and defense.while in the development of Web3 projects, the focus is on the business demonstration of the project and the realization of business functions, and there is no more energy to complete the construction of the security system. Therefore, in the absence of a security system, it is difficult to ensure the security of a Web3 project throughout its life cycle.

Usually, the project team will find an excellent blockchain security team to conduct security audits on its code in order to ensure the security of Web3 projects. When conducting security audits, various security practice requirements can be better achieved, but blockchain security the team’s audit is only a short-term guidance, and does not allow the project team to establish its own security system.

Therefore, the SlowMist security team has open-sourced Web3 Project Security Practice Requirements to continuously help the project team in the blockchain ecosystem to master the corresponding Web3 project security skills, It is hoped that the project team can establish and improve its own security system based on Web3 Project Security Practice Requirements, and also have certain security capabilities after security audits.

0x01 Development Preparation

1.Requirements Analysis Document Requirements

• Make sure to include a thorough description of the project;
• Make sure to include the specific problem that the project is to address;
• Make sure to include a security/privacy risk assessment;

2.Development Design Documentation Requirements

• Make sure to include the project’s architectural design diagram;
• Make sure to include functional descriptions of functions in the code;
• Make sure to include a description of the relationship between the contracts in the code;
• Make sure to include security/privacy requirements;

3.Business Process Documentation Requirements

• Make sure to include a description of each business process in the project;
• Make sure to include a detailed business process diagram;
• Make sure to include a detailed funding link diagram;

0x02 Development Process

1. Smart Contract Security Coding Requirements

• Make sure to develop based on well-known libraries such as OpenZeppelin as much as possible;
• Make sure to include a compiler that uses SafeMath or 0.8.x to avoid most overflow issues;
• Make sure to follow function naming conventions, see: solidity style guide;
• Make sure that function and variable visibility are explicitly declared;
• Make sure that the function return value is explicitly assigned;
• Make sure that functions and parameters are well-annotated;
• Make sure that external calls correctly check the return value, including: transfer, transferFrom, send, call, delegatecall, etc.;
• Make sure that the implementation of the parameter type and return value of the interface is correct;
• Make sure that the key parameters of the contract are set up with authentication and use events to record;
• Make sure that the data structure of the new implementation contract of the upgradeable model is compatible with the data structure of the old implementation contract;
• Make sure that the logic involved in arithmetic operations in the code fully considers the precision problem, and avoids the problem of possible loss of precision caused by dividing and then multiplying;
• Make sure that the target address and function of low-level calls such as call are expected;
• When using low-level calls such as call, limit Gas according to business needs;
• Coding specifications are constrained, follow: first judge, then write variables, and then make external calls (Checks-Effects-Interactions);
• Make sure that external contracts that interact in business are compatible with each other, such as: deflation/inflation tokens, reentrant tokens such as ERC-777, ERC-677, ERC-721, see: Reentrancy Vulnerability Case;
• Make sure that external calls fully consider the risk of reentrancy;
• Avoid using a lot of loops to assign/read the contract’s storage variable;
• Avoid the problem of excessive concentration of authority as much as possible, especially the authority to modify the key parameters of the contract, separate authority, and use governance, timelock contract or multi-signature contract to manage as much as possible;
• The inheritance relationship of contracts should maintain linear inheritance, and ensure that the inherited contracts are really needed for business;
• Avoid using on-chain block data as a seed source for random;
• Make sure that the acquisition and use of random numbers fully consider the possibility of rollback attacks;
• Use Chainlink’s VRF to obtain reliable random, see: Chainlink VRF;
• Avoid using the token quantity of the third-party contract to directly calculate the LP Token price, see: How to get the price of LP correctly;
• Avoid a single price source when obtaining prices through third-party contracts. It is recommended to use at least 3 price sources;
• Use events as far as possible in key business processes to record the status of execution for data analysis when the project is running;
• Reserve the switch for an emergency suspension of the global and core business, so that it is convenient to stop losses in time when a black swan event occurs;

2. Test Case Code Requirements

• Make sure to include business process/function functional usability testing;
• Make sure that the unit test coverage rate is more than 95%, and the core code coverage rate must reach 100%;

3. Basic Security Configuration Requirements

• Make sure that the official email uses well-known service providers, such as Gmail;
• Make sure that the official email account opens MFA function;
• Make sure that the use of well-known domain name service providers, such as GoDaddy;
• Make sure that the use of excellent CDN service providers, such as Akamai and Cloudflare;
• Make sure that DNS configuration turns on DNSSec, set a strong password for the management account on the domain name service management platform, and turn on MFA authentication;
• Make sure that all mobile phones and computer devices use anti-virus software, such as Kaspersky, AVG, etc.;

4. Web front-end Security Configuration Requirements

• Make sure that the HTTP communication of the whole site adopts HTTPS;
• Make sure HSTS is configured to prevent man-in-the-middle attacks like: DNS hijacking, BGP hijacking,see：HSTS Configuration Introduction;
• Make sure X-FRAME-OPTIONS is configured to prevent Clickjacking attacks, see: X-FRAME-OPTIONS Configuration Introduction;
• Make sure X-Content-Type-Options are configured to combat the risks caused by browser sniff behavior, see：X-Content-Type-Options Configuration Introduction;
• Make sure CSP policies are configured to prevent XSS attacks, see: CSP Configuration Introduction;
• Make sure cookies related to permissions and user credentials are configured with HttpOnly, Secure, Expires, SameSite flags, see: Cookie Configuration Introduction;
• Make sure that the sub-domains of different businesses are strictly separated to avoid the XSS problems of the sub-domains affecting each other;
• Make sure that the referenced third-party resources are restricted by the integrity attribute, so as to avoid the third-party being hacked and the project’s site from being affected, see：SRI Configuration Introduction;
• Make sure CORS is properly configured to only allow the specified origin domain, protocol and port to access the project’s resources, see: CORS Configuration Introduction;
• Make sure that the addEventListener/postMessage implemented in the business has the origin and target of the check message, see：postMessage Configuration Introduction;

5. Server Environment Security Configuration Requirements

• Make sure that the selection of excellent cloud server providers, such as AWS, Google Cloud, etc.;
• Make sure that the cloud platform management account used by the project uses a strong password and turns on MFA;
• Make sure that the security reinforcement of the server before the project code is deployed to the server, such as installing HIDS, using SSH Key to log in, setting SSH login alert, setting SSH login google-auth, etc.;
• Make sure that the use of professional software monitoring services and server availability, such as APM and Zabbix;
• Make sure the use of professional institutions to regularly test the safety of projects, such as SlowMist, Trail of Bits, etc.;

0x03 Release Process

A complete security online release process is required, which can be refined by referring to the following content

1. Code Freeze Requirements

• The estimated launch time is pushed back 2 days, that is, the code must be frozen and no code changes will be made 2 days before the launch;

2. Unit Test Requirements

• Make sure that the unit test coverage rate is above 95%, and the core code coverage rate is 100%;
• Make sure to output coverage reports for unit tests;

3.Regression Testing Requirements

• Make sure to output coverage reports for unit tests;

4.Test Report Requirements

• 0.5 days before the launch, the development and testing will jointly complete the test report. If the test report is not passed (including unit testing and regression testing), the launch time will be postponed, and the code freezing stage will be re-entered after the development is completed and modified (that is, postponed for at least 2 days);

5.Security Audit Requirements

• Security auditors enter the overall security regression after the code is frozen. If any vulnerability or security risk (serious, high-risk, medium-risk) is found, the launch time will be postponed, and the code will be frozen again after the development and modification are completed (that is, delayed for at least 2 days).
• Security audit requires at least three teams to conduct independent audits, and can use 1 internal team + 2 external teams;

0x04 Runtime Process

1.Runtime Security Monitoring

As far as possible through the events triggered in the key business processes to discover the security problems of the project runtime, such as:

• Update of important contract permissions/parameters: monitor the events that the management role changes, and the events that the management role modifies the key parameters of the contract, and promptly discover the possible theft of the private key;
• Changes in contract funds: monitor price changes and changes in contract funds, and timely detect possible attacks such as flash loans;
• Periodic reconciliation: Periodically reconcile events and transactions on the chain to discover possible business logic problems in a timely manner;

2.Runtime environment security hardening

• Make sure the security hardening of the server where the front-end code is located,such as：Install HIDS,Login with SSH Key,Set SSH login alert,Set up SSH login to google-auth etc;
• 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 authentications;
• Make sure that the cloud platform management account used by the project uses a strong password and has 2 authentications enabled;

3.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,code4rena,immunefi;

4.Form Emergency Response Group

• Set up a nominal emergency response group and provide contact information to the outside world. The emergency response group is responsible for dealing with problems found by white hats or leading team members to carry out an emergency response when a black swan event occurs;

0x05 Emergency Response

1.Establish A Complete Emergency Response 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;

2.Stop Loss Disposal Requirements

• According to the scope of the problem and the degree of harm, stop the loss through the emergency pause switch in time;
• Notify community members of black swan events to prevent users from continuing to interact with the project and cause losses;

3.Tracking Hacker Requirements

• Quickly analyze the hacker’s profitable address, and keep the access log of the PC/Web/server (if there is a Trojan, please keep the Trojan file);
• Take a snapshot of the server and keep the hacked scene in time;
• Contact a professional security team to assist in tracking, such as: MistTrack ,Chainalysis;

4.Problem-solving Requirements

• Discuss the best fixes for the problem with a professional security team;
• Correctly implement the fixed plan and ask a professional security team to verify it;

5.Security Release Requirements

• Enforce release process requirements to ensure all code changes are tested and security audited;

6.Issue Analysis Requirements

• Disclose autopsy reports and synchronize restoration plans and remedies with community members;
• 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.

Summary

Security is a critical and ever-evolving aspect of Web3 project management. Relying solely on short-term audits from third-party security teams is not sufficient to ensure the long-term security and stability of a project. Therefore, it is vital to establish and proper measures and visit [Link] by SlowMist | Web3 Project Security Practice Requirements in order to ensure the continuity of security when it comes to Web3 projects. Project teams should develop a comprehensive understanding of security and possess the necessary capabilities to better ensure the secure and stable operations of their Web3 projects.

We strongly advise project teams to actively engage with the security community and stay up-to-date with the latest security attack and defense technologies and experiences. By collaborating with other project teams and security experts, they can work together to enhance the security of the entire ecosystem. Additionally, providing internal security training and knowledge dissemination can increase the security awareness and capabilities of all staff, which is a critical step in establishing and improving the security system.

Ultimately, it should be noted that Web3 project security practices are currently at the v0.1 stage and are continuously being refined. Thus, we welcome any feedback and suggestions to further enhance the security of Web3 projects.