Overflow and Underflow Attacks on Smart Contracts

Smart contracts often use integer variables to store balances, counters, or other numeric values. However, integers in Solidity have finite sizes, meaning they can only represent values within a specific range:

• uint8: Unsigned integers from 0 to 255
• uint16: Unsigned integers from 0 to 65,535

Overflow: An overflow occurs when a calculation exceeds the maximum value the data type can store. For example, adding 1 to a uint8 with value 255 wraps it back to 0. This happens due to arithmetic wrapping caused by the finite range of the integer type.

Underflow: Conversely, an underflow occurs when a calculation goes below the minimum value (0), wrapping around to the maximum value of the data type.

Impact: Overflow and underflow vulnerabilities can allow attackers to manipulate balances, bypass limits, or mint unlimited tokens. While modern Solidity versions have built-in overflow/underflow protection, understanding this vulnerability is crucial for analyzing legacy contracts.

Hands-on Hint: In this experiment, you will attempt to overflow a uint8 balance to observe how arithmetic wrapping affects contract behavior.

Re-entrancy

The re-entrancy attack is one of the most destructive attacks in Solidity smart contracts. A re-entrancy attack occurs when a function makes an external call to another untrusted contract, and then the untrusted contract makes a recursive call back to the original function in an attempt to drain funds.

A re-entrancy attack involves two smart contracts: a vulnerable contract and an untrusted attacker’s contract.

Accessing Private Data

In Solidity, declaring a variable private only prevents other contracts from accessing it directly; it does not hide the value from the public. Blockchains are transparent — anyone can read contract storage using blockchain explorers or by inspecting on-chain storage.

Example:

pragma solidity ^0.6.0;
          
          
contract PrivateData {
          string private password = "mySecret123"; // still visible on the blockchain
          }
          

Exploit Impact:

• If sensitive information (passwords, private keys, API tokens, secret salts) is stored on-chain, attackers can retrieve it directly even when declared private.
• Leaked secrets can lead to credential theft, unauthorized access, token minting, or other downstream compromises.

Best practices:

• Never store secrets on-chain. Keep sensitive values off-chain (secure servers, secret managers).
• If you must reference secret material, store only hashes or use commit–reveal schemes so the secret itself is not publicly exposed.
• Use secure oracles or middleware to handle confidential data and perform sensitive operations off-chain.