In traditional software development, there are various security issues that we can fix by patching. When you find a big in a traditional system, a fix can be written, deployed, and prevented from future exploits. Essentially, you can easily and frequently use Patches.
However, patching security vulnerabilities in Ethereum blockchain based decentralized applications is not so straightforward. It is because of the unalterable nature of smart contracts. Indeed, the upgrade of the already deployed smart contract is complex and sometimes impossible. So, let’s analyze a few common security vulnerabilities in Solidity smart contracts and how to address them.
Here is a list of common vulnerabilities in Solidity code written for smart contracts,
a) Unprotected Function
For all your publically accessible smart contract functions, you need to add further modifiers on them like in the example, which require the msg.sender to be the current owner.
Here in this example, the modifier only owner does the above work. Code Reference (https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/math/SafeMath.sol)
The function _changeOwnership is internal, which means it can be called from within our smart contract or its derivatives.
b) Integer Overflow and Underflow
This error is related to simple Math functions that you use in your contracts with soliidty data types, like addition, division, etc.
For example data type uint8, ha a range 0 to 255 ,but adding 1 to 255 will result in overflowing to 0 value and similarly underflow errors if you subtract 1 from 0 value.
Instead one should use the following SafeMath library, which keeps care of these issues, for example
For more info on SafeMath library , follow this link - SafeMath Library
c) Transaction Dependence
This type of attack takes place when a user compares the gas price value sent per unit by all the transactions in the tx pool, and updates the gas price in such a way that his transaction gets the highest priority. This can be seen in contracts related to auctions etc.
These attacks are related to state changes in your smart contract functions. An example of this is a contract where your balance is reset to 0 only after the transfer occurs, so a hacker could keep calling this even after they’ve received the withdrawal to hack more ether from the contract. Basically, they can call another function halfway through the first function’s execution to hack your contract.
Here’s an example:
The balance is not set to 0 until after the other function is called. The attacker can call this recursively and successfully hack the smart contract. One way to protect against this attack is to update the balance before executing call.value on the sending address:
e) Gas Limits
Each operation on the EVM results in consumption of the gas amount you send when initiating the transaction, if your functions consist of too many steps, or increasing number of steps with the data you hold, each transaction made to execute that function will result in out of gas errors and making your contract unusable.