This guide aims at supporting ink! developers who want to deploy their project on the Aleph Zero blockchain. It has been developed as part of the partnership between Aleph Zero and Kudelski Security.
Development Environment
Use Substrate multichain framework to build and deploy programs.
Use Ink! version 4. Check ink_lang version in Cargo.toml file.
Set the compiler flags debug-assertion and overflow-checks to true. These can be set in Cargo.toml for profile.release.
Use rustfmt formatter. Customize your guidelines by creating a rustfmt.toml in the root of you project and perform the following commands:
cargo+nightlyfmt \-- \--checkcargo+nightlyfmt
Use a linter, such as clippy, regularly during the development of a secure application.
Use rust clippy which is a collection of lints to catch common mistakes and improve your Rust code.
Install Rustup. If you already have Rustup installed, update to ensure you have the latest Rustup and compiler:
rustupupdate
Install Clippy
rustupcomponentaddclippy
Run Clippy
cargoclippy
If necessary, fix Clippy suggestions automatically
cargoclippy--fix
Use rustfix which reads and applies the suggestions made by rustc.
Install rustfix
cargoaddrustfixcargoinstallcargo-fixcargofix
Open the rust files to manually verify the fixes.
Verify all dependencies are up to date.
Use cargo audit which audits your dependencies for crates with security vulnerabilities reported to the RustSec Advisory Database.
Install cargo-audit
cargoinstallcargo-audit
Run cargo audit
cargoaudit
Use cargo outdated which displays when Rust dependencies are out of date.
Install cargo-outdated
cargoinstall--lockedcargo-outdated
Run cargo outdated
cargooutdated
Use cargo update which updates dependencies as recorded in the local lock file.
cargoupdate
Design
Ensure that the design documents of your smart contract contain the following components:
Threats/Risk assessment
While designing the smart contract, a threat assessment needs to be performed with the following five steps. A threat is an element which can hurt, harm, tamper with, or attack the smart contract.
Context establishment
How will the project be used?
Who is the target audience?
Threat assessment
This includes a list of all assets used in the project and their associated risks or threats
Threat analysis & evaluation
Assets are classified by their risks/threats and their likelyhood.
Mitigation treatment
What can be done to mitigate these risks/threats?
Risk and control monitoring
Which operation can be done to conrol these risks/threats?
Conventions
Rust API Guidelines Checklist is a set of recommendations on how to design and present APIs for the Rust programming language.
[ ] If a function or asset should be available only to a restricted set of entities, you need to verify that the call has been signed by the appropriate entity.
[ ] Ensure that unencrypted private data is not stored in the contract code or state. In particular, items in the `#[ink(storage)]` section should not contain passwords, private keys, etc.
https://swcregistry.io/docs/SWC-136
[ ] UnverifiedParsedAccount - SVE1007
[ ] The account should be validated before parsing its data.
[ ] Ensure that access controls are implemented so withdrawals can only be triggered by authorized parties or according to the specs of the smart contract system.
https://swcregistry.io/docs/SWC-105
[ ] Unprotected self destruction or burning instruction(s)
[ ] If the contract allows for removal of items from storage, these instructions should be properly authorized
[ ] Use delegator call with caution and make sure to never call into untrusted contracts. If the target address is derived from user inputs, ensure to check it against a whitelist of trusted contracts.
https://swcregistry.io/docs/SWC-112
https://use.ink/basics/cross-contract-calling
[ ] Authorization through use of Self.env()
[ ] Signature Malleability: Valid signatures might be created by an attacker replaying previously signed messages.
[ ] Ensure that a signature is never included into a signed message hash to check if previously messages have been processed by the contract.
[ ] Missing Protection against Signature Replay Attacks
[ ] Lack of Proper Signature Verification and Data Authenticity
Numerics
[ ] Integer overflow / underflow
[ ] If `doverflow-checks = false` in `Cargo.tolm` file please wrap arithmetic operations with safe math functions or validate all arithmetic to prevent overflows. * https://github.com/crytic/not-so-smart-contracts/tree/master/integer_overflow * https://swcregistry.io/docs/SWC-101 * https://medium.com/coinmonks/understanding-arithmetic-overflow-underflows-in-rust-and-solana-smart-contracts-9f3c9802dc45
[ ] Division by zero: Contracts go to panic mode when dividing by zero
[ ] Use a safe math function for division or validate the divisor not zero.
https://github.com/rust-lang/rust/issues/944
Memory management
When it comes to memory management, the following checks need to be done:
Error Handling
When it comes to memory management, the following checks need to be done:
[ ] Be careful when you use the following patterns that may cause panics.
using unwrap or expect,
using assert,
an unchecked access to an array,
integer overflow (in debug mode),
division by zero,
large allocations,
string formatting using format!.
Bad Programming practices
[ ] Incorrect Interface
[ ] A different type of interfaces are implemented, causing a different method ID to be created. For example, `Alice.set(uint)` takes an `uint` in Bob.rs but `Alice.set(int)` a `int` in Alice.rs. The two interfaces will produce two differents method IDs. As a result, Bob can call the fallback function of Alice rather than of `set`.
[ ] `if ... { return Err(Error::SomeError) }` should be used for `require` or `revert`. When a `Result::Err` is returned in ink!, then all state is reverted.
[ ] DoS With Block Gas Limit: The cost of executing a function exceeds the block gas limit.
[ ] Presence of Unused Variables
[ ] Code with No Effects (Dead Code)
[ ] Account Reinitialization - SVE1013
[ ] Incorrect Calculation of Boundary Cases
[ ] Check the edge cases e.g. `>` instead of `>=`.
[ ] The contract is upgradeable.
[ ] Upgradeable contracts may change their rules over time.
[ ] The contract is pausable.
[ ] Having a way to pause your contract can help to limit the damage in case of attack or security breach.
Token Specific issues
[ ] Token Race Conditions: A transaction-ordering attack or a front running attack.
[ ] An attacker who is running a node can tell which transactions are going to occur before they are finalized. A race condition vulnerability occurs when code depends on the order of the transactions submitted to it.
This part aims to help preparing for a security audit which is necessary in order to achieve the best security possible. It is important to see an audit as a partnership between you and the company performing the audit. Therefore, it is important that you prepare some documents to the good functionning of audit.
Are the following elements ready?
[ ] Complete Documentations
[ ] Setup a communication channel with the audit team
[ ] Use a secure communication channel using end-to-end encryption.
[ ] Code ready to be frozen
[ ] Verify that the audit team can answer the following questions
