Skip to content

Create VulnerabilityList.md #28

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
renardbebe wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Create VulnerabilityList.md #28

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
57 changes: 57 additions & 0 deletions backend/secure_check/VulnerabilityList.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,57 @@
| Ind | Name | Description | SWC-ID | Level |
| :--: | :--------------------------------------------------: | :----------------------------------------------------------: | :----: | :-----: |
| 1 | Function or Variable Default Visibility | Functions or variables that do not have a visibility type specified are public by default. This can lead to a vulnerability if a developer forgot to set the visibility and a malicious user is able to make unauthorized or unintended state changes. | 100 | warning |
| 2 | Integer Overflow or Underflow | An overflow/underflow happens when an arithmetic operation reaches the maximum or minimum size of a type. | 101 | error |
| 3 | Outdated Compiler Version | Using an outdated compiler version can be problematic especially if there are publicly disclosed bugs and issues that affect the current compiler version. | 102 | warning |
| 4 | Unchecked Call Return Value | The return value of a message call is not checked. Execution will resume even if the called contract throws an exception. If the call fails accidentally or an attacker forces the call to fail, this may cause unexpected behaviour in the subsequent program logic. | 104 | error |
| 5 | Unprotected Ether Withdrawal | Due to missing or insufficient access controls, malicious parties can withdraw some or all Ether from the contract account. | 105 | error |
| 6 | Unprotected SELFDESTRUCT Instruction | Due to missing or insufficient access controls, malicious parties can self-destruct the contract. | 106 | error |
| 7 | Reentrancy | One of the major dangers of calling external contracts is that they can take over the control flow. In the reentrancy attack (a.k.a. recursive call attack), a malicious contract calls back into the calling contract before the first invocation of the function is finished. This may cause the different invocations of the function to interact in undesirable ways. | 107 | error |
| 8 | Assert Violation | Properly functioning code should never reach a failing assert statement. | 110 | error |
| 9 | Use of Deprecated Solidity Functions | Several functions and operators in Solidity are deprecated. Using them leads to reduced code quality. With new major versions of the Solidity compiler, deprecated functions and operators may result in side effects and compile errors. | 111 | warning |
| 10 | Delegatecall to Untrusted Callee | Calling into untrusted contracts is very dangerous, as the code at the target address can change any storage values of the caller and has full control over the caller's balance. | 112 | error |
| 11 | DoS with Failed Call | External calls can fail accidentally or deliberately, which can cause a DoS condition in the contract. | 113 | error |
| 12 | Transaction Order Dependence | A race condition vulnerability occurs when code depends on the order of the transactions submitted to it. | 114 | error |
| 13 | Authorization through tx.origin | tx.origin is a global variable in Solidity which returns the address of the account that sent the transaction. Using the variable for authorization could make a contract vulnerable if an authorized account calls into a malicious contract. | 115 | warning |
| 14 | Timestamp Dependence | Developers can't rely on the preciseness of the provided timestamp. | 116 | error |
| 15 | Signature Malleability | A system that performs signature verification on contract level might be susceptible to attacks if the signature is part of the signed message hash. Valid signatures could be created by a malicious user to replay previously signed messages. | 117 | error |
| 16 | Weak Sources of Randomness from Chain Attributes | Uable to create a strong enough source of randomness. | 120 | error |
| 17 | Write to Arbitrary Storage Location | The contract is responsible for ensuring that only authorized user or contract accounts may write to sensitive storage locations. If an attacker is able to write to arbitrary storage locations of a contract, the authorization checks may easily be circumvented. | 124 | error |
| 18 | Arbitrary Jump with Function Type Variable | The problem arises when a user has the ability to arbitrarily change the function type variable and thus execute random code instructions. | 127 | error |
| 19 | Call-stack Depth Limit Exceeding | The Ethereum Virtual Machine implementation limits the call-stack's depth to 1024 frames. The call-stack's depth increases by one if a contract calls another via the send or call instruction. This opens an attack vector to deliberately cause the send instruction to fail. | | error |
| 20 | Contract contains unknown address | The contract contains an unknown address. This address might be used for some malicious activity. | | warning |
| 21 | Checking for strict balance equality | An adversary can forcibly send ether to any address via selfdestruct() or by mining. | | warning |
| 22 | Use bytes instead of byte[] | For lower gas consumption, byte[] is unsafe. | | warning |
| 23 | Use of call function with no data | Use of low-level call function with no arguments provided. | | warning |
| 24 | Use of in constructor | Return statement is used in the contract's constructor. With return the process of deployment will differ from the intuitive one. For instance, deployed bytecode may not include functions implemented in the source. | | error |
| 25 | Deletion of dynamically-sized storage array | Applying delete or .length = 0 to dynamically-sized storage arrays may lead to Out-of-Gas exception. | | warning |
| 26 | Deprecated constructions | Deprecated constructions: years, sha3, suicide, throw and constant functions.Use keccak256 instead of sha3. | | warning |
| 27 | Multiplication after division | Solidity operates only with integers. Thus, if the division is done before the multiplication, the rounding errors can increase dramatically. | | warning |
| 28 | Using continue in the do-while loop | Prior to version 0.5.0, Solidity compiler handles continue inside do-while loop incorrectly: it ignores while condition. | | warning |
| 29 | Using approve function of the ERC-20 token standard | The approve function of ERC-20 is vulnerable. Using front-running attack one can spend approved tokens before change of allowance value. | | warning |
| 30 | Return value is always false | The transfer, transferFrom or approve functions do not return true for any values of input parameters. | | warning |
| 31 | Use of unindexed arguments in ERC-20 standard events | Address arguments of Transfer and Approve events of ERC-20 token standard must be indexed. | | warning |
| 32 | ERC-20 transfer should throw | Functions of ERC-20 Token Standard should throw in special cases: a) transfer should throw if the _from account balance does not have enough tokens to spend; b) transferFrom should throw unless the _from account has deliberately authorized the sender of the message via some mechanism. | | error |
| 33 | Extra gas consumption | State variable, .balance, or .length of non-memory array is used in the condition of for or while loop. In this case, every iteration of loop consumes extra gas. | | warning |
| 34 | Incorrect blockhash function | Blockhash function returns a non-zero value only for 256 last blocks. Besides, it always returns 0 for the current block. | | warning |
| 35 | Locked money | Contracts programmed to receive ether should implement a way to withdraw it. | | warning |
| 36 | Overpowered role | This function is callable only from one address. Therefore, the system depends heavily on this address. In this case, there are scenarios that may lead to undesirable consequences for investors, e.g. if the private key of this address becomes compromised. | | warning |
| 37 | Private modifier | Contrary to a popular misconception, the private modifier does not make a variable invisible. Miners have access to all contracts' code and data. | | warning |
| 38 | Redundant fallback function | The payment rejection fallback is redundant. | | warning |
| 39 | Output overwrites input of assembly CALLs | Dangerous use of inline assembly instruction of CALL family, which overwrites the input with the output. | | warning |
| 40 | Send instead of transfer | The send function is called inside checks instead of using transfer. | | warning |
| 41 | Incorrect Pure-functions | In Solidity, functions that do not read from the state or modify it can be declared as pure. | | warning |
| 42 | Incorrect View-functions | In Solidity, functions that do not read from the state or modify it can be declared as view. | | warning |
| 43 | ETH transfer inside the loop | ETH is transferred in a loop. If at least one address cannot receive ETH (e.g. it is a contract with default fallback function), the whole transaction will be reverted. | | warning |
| 44 | Non-strict comparison with zero | Variables of uint type cannot be negative. Thus, comparing uint variable with zero (greater than or equal) is redundant. Also, it may lead to an underflow issue. Moreover, comparison with zero used in for-loop condition results in an infinite loop. | | warning |
| 45 | Use inline assembly | Inline assembly is a way to access the Ethereum Virtual Machine at a low level. This discards several important safety features of Solidity. | | warning |
| 46 | Unsafe type inference | May cause overflow error. | | warning |
| 47 | Incorrect function signature | In Solidity, the function signature is defined as the canonical expression of the basic prototype without data location specifier, i.e. the function name with the parenthesised list of parameter types. Parameter types are split by a single comma - no spaces are used. | | warning |
| 48 | Worse readability with revert | Using the construction ''if (condition) {revert();}'' instead of ''require(condition);'' | | warning |
| 49 | Using uintless number | Vyper allows you to use unit label to either uint256, int128, or decimal type. This feature is implemented to increase code readability and security. Use of as_unitless_number() function can endanger contract security. | | warning |
| 50 | ArbitraryTransfer problem | When a hacker gets access to controlling this function, he can transfer tokens from one account to another one arbitrarily. | | error |
| 51 | GenerateToken problem | When a hacker gets access to controlling this function, he can generate any amount of tokens. | | error |
| 52 | DestroyToken problem | When a hacker gets access to controlling this function, he can destory any amount of tokens. | | error |
| 53 | FrozeAccount problem | When a hacker gets access to controlling this function, he can freeze any account. | | error |
| 54 | DisableTransfer problem | When a hacker gets access to controlling this function, he can disable all the transferations. | | error |