Репост из: Securlydev
🔴Many security vulnerabilities come from faulty assumptions
Identifying the assumptions made by the devs and evaluating if they are correct can uncover big discrepancies between what the code does vs what it is intended to do
Here are examples of common faulty assumptions: 📔
1. Initialization functions will only be called ONCE and/or can be called only by the contract deployer
2. Only admins can call certain functions(access control issues)
3. Functions will always be called in a certain order as expected by the system
Ex. what if there's a function that closes a position but expects that you opened one in the 1st place?
A function that checks if your payment is on time but expects you got a loan before that?
4. Parameters can only have non-zero values or values within a certain threshold
addresses will never be zero-valued
sender will always be different from the receiver
an element of a struct array will always exist so the values won't be the default ones
5. Certain addresses or data values can never be attacker-controlled
6. Function calls will always be successful and so checking for return values is not required
These are just a few examples of common assumptions that don't always hold true
Always try to identify what assumptions are made when writing the code and compare that to how the system could actually behave
@EthSecurity1
Identifying the assumptions made by the devs and evaluating if they are correct can uncover big discrepancies between what the code does vs what it is intended to do
Here are examples of common faulty assumptions: 📔
1. Initialization functions will only be called ONCE and/or can be called only by the contract deployer
2. Only admins can call certain functions(access control issues)
3. Functions will always be called in a certain order as expected by the system
Ex. what if there's a function that closes a position but expects that you opened one in the 1st place?
A function that checks if your payment is on time but expects you got a loan before that?
4. Parameters can only have non-zero values or values within a certain threshold
addresses will never be zero-valued
sender will always be different from the receiver
an element of a struct array will always exist so the values won't be the default ones
5. Certain addresses or data values can never be attacker-controlled
6. Function calls will always be successful and so checking for return values is not required
These are just a few examples of common assumptions that don't always hold true
Always try to identify what assumptions are made when writing the code and compare that to how the system could actually behave
@EthSecurity1