Aaruni

Its tempting to use Tx.Origin as a way to verify the original sender of a transaction but this approach is vulnerable to a phishing attack. For example, consider a contract C that only likes to be called by an address A: Now an attacker B can create an innocuous contract B and have A call … Read more

Solidity does not support floating point types and as such any such calculation needs to be simulated carefully with uint. This however can produce a vulnerability if not done right. Lets look at the contract FunWithNumbers from https://github.com/sigp/solidity-security-blog#15-floating-points-and-precision This line below is converting ETH to some token. The problem is in the division – if … Read more

Miners have the ability to manipulate block.timestamp so it can be exploited if there is an incentive to do so. There are some restrictions on how miners can change block.timestamp: It has to be greater than the last parent block and it can not be too far in the future otherwise other nodes will reject … Read more

These attacks can leave a contract inoperable either temporarily or permanently. There are many ways a contract can become inoperable; some are presented below: External function calls: An external function may maliciously use all gas when called, making a contract temporarily or even permanently inoperable. For example, the TrickleWallet at https://github.com/sigp/solidity-security-blog#the-vulnerability-10 issues a function call … Read more

Miners get to choose what transaction they would pick up from the pool to form a block and this means the transactions that carry a high gasPrice will likely be picked up first. A Race condition occurs when an attacker can read a transaction on the blockchain and create a similar transaction with a higher … Read more

We can use .transfer() to send Ether which is considered safe as it reverts in case the transfer fails. We can also use .send() and .call() to transfer Ether but they only return a value of false if they fail. This creates a security vulnerability where an attacker can target a transaction that should have … Read more

Prior to Solidity v0.5.0, Smart Contracts suffered from vulnerability resulting from attacker using a shorter than required address as function parameter. The vulnerability resulted from EVM’s tendency to append zero’s at the end of calldata in case a parameter(in this case, an address) was shorter in length than it is by definition. Looking at example … Read more

There is no random() function in Solidity so the developers end up using other means of achieving randomness such as using hash of next block as a random value. If this source of entropy is not selected carefully, it can be used by an attacker to predict the next “random” value and exploit a contract.

Earlier version of solidity did not enforce defining visibility on functions. This created situations where an attacker would be able to call a function that he/she shouldn’t be. Recent Solidity versions enforce setting up visibility on every function so this vulnerability has been mitigated. However it is still important to review the visibility of all … Read more

There are two kinds of low level functions invocations: call() and delegatecall(). The latter is used when we wish to execute an external function in the context of the caller contract. This means the target function can manipulate the state variables of the caller contract. So, if contract A issues a delegatecall to B.foo(), then … Read more