For SWC-106, Due to missing or insufficient access controls, malicious parties can self-destruct the contract resulting in a deletion of the contract code. The selfdestruct call can also be used to forcefully send ether to an address. If self-destruct is a necessity, it is recommended to implement a multi-signature scheme for approval.

For SWC-107, The Reentrancy vulnerability is infamously known for the DAO Attack. In this case, the attacker is able to make recursive calls to the contract resulting in draining the funds. One must use OpenZeppelin’s ReentrancyGuard or use the Checks-Effects-Interactions pattern.

The Problem

Due to Missing or Improper Access Control, malicious users can withdraw some or all Ether from the contract account.

The Solution

Use modifiers like onlyOwner or used RBAC (Role-Based Access Control) to allow selective users from accessing a critical function.

The Problem

Developers should make it a habit to always check for the return value of a function call. If a function throws an exception and there is no proper check to handle this, unexpected behavior can be seen which may turn out to be a security risk.

The Solution

Checking the return value of a call.

Ciao!!!

1. For SWC-102, developers should make sure they are using a stable version of solidity and also check if there are any known bugs against that particular compiler version
2. For SWC-103, developers should stay away from using floating pragma (refer to the example given below). The best practice is to lock a pragma version and deploy the contract to the mainnet. Using different pragma versions in test and mainnet may introduce unknown security risks.

pragma solidity >=0.4.0 < 0.6.0; 
pragma solidity >=0.4.0<0.6.0; 
pragma solidity >=0.4.14 <0.6.0; 
pragma solidity >0.4.13 <0.6.0; 
pragma solidity 0.4.24 - 0.5.2;

Ciao!!!

The Problem

As the name suggests, the issue is caused whenever an arithmetic operation reaches the maximum limit of a type. For simplicity, let take an example of uint8, it can hold values within the range(0, 255). If the value of a certain arithmetic operation turns out to be greater than 255, cascading occurs and all the bits are set to zero which results in Incorrect Calculation resulting in overflow. Similarly, if we subtract a small number with a larger number it may result in a negative result causing underflow.

The Solution

Use Safe Math libraries for arithmetic operations written by OpenZeppalin. if you are using solidity ≥ 0.8.0, then this is handled by default.

Hope you enjoyed reading it.

Ciao!!!

Imagine that a developer decides to allow only Externally Owned Addresses (EOA) to interact with his contract, then he/she can add a check via extcodesize, which returns a value greater than 1, in case some code is associated with the contract.

But, let us learn how can be bypass this check.

The simple hack to bypass the check is to define and call the protected function of the Target contract as part of our malicious contract. The code size(extcodesize) of our contract is currently 0 the contract is under creation and hasn't been deployed.

This article is gonna be a short one.

block.timestamp can be manipulated by miners with the following constraints

• It cannot be stamped with an earlier time than its parent
• t cannot be too far in the future

Imagine a user Eve, who has access to large computation power via which…