DeFiVulnLabs - To learn common smart contract vulnerabilities usi

项目说明

DeFi

This was an internal Web3 solidity security training in XREX. I want to share these materials with e interested in Web3 security and how to find in code and exploit them. Every testing uses Foundry. Faster and easier!

Currently supports 48 types of . it compiles with Solidity 0.8.18 except the cases like o, underflow where we need older solidity to reproduce the bug.

Disclaimer: This content ser as a proof of concept showcasing Solidity common bugs. It is strictly intended for educational purposes and should not be interpreted as encouraging or endorsing any form of illegal acti or actual hacking attempts. The provided information is for informational and learning purposes only, and any actions taken based on this content are solely the responsibility of the indi. The usage of this information should adhere to applicable laws, regulations, and ethical standards.

DeFi Solidity Security Testing Guide

* Notion

Getting Started

* Follow the instructions to install Foundry.
* Clone and install dependencies:
* Test :

Who Support Us? DeFiHackLabs Recei From

![gcc PM]()

Donate us

If you appreciate our work, please consider donating. Even a small amount helps us continue de and improving our projects, and promoting web3 security.

E - 0xD7d6215b4EF4b9B5f40baea48F41047Eb67a11D5

Giveth

List of

* Integer O 1 | Integer O 2 :
* In previous of Solidity (prior Solidity 0.8.x) an integer would automatically roll-over to a lower or higher number.
* Without SafeMath (prior Solidity 0.8.x)
* Selfdestruct 1 | Selfdestruct 2 :
* Due to missing or insufficient access controls, malicious parties can self-destruct the contract.
* The selfdestruct(address) function removes all bytecode from the contract address and sends all ether stored to the specified address.
* Unsafe Delegatecall :
* This allows a smart contract to dynamically load code from a different address at runtime.
* Reentrancy :
* One of the major dangers of calling external contracts is that they can take over the control flow.
* Not following checks-effects-interactions pattern and no ReentrancyGuard.
* Read Only Reentrancy :
* An external call from a secure smart contract "A" invokes the fallback() function in the attacker's contract. The attacker executes the code in the fallback() function to run against a target contract "B", which some how indirectly related to contract "A".
* In the gi, Contract "B" derives the price of the LP token from Contract "A"
* ERC777 callbacks and reentrancy :
* ERC777 tokens allow arbitrary callbacks that are called during token transfers. Malicious contract addresses may cause reentrancy on such callbacks if reentrancy guards are not used. REF1, REF2, Cream POC
* ERC667 reentrancy | ERC827 reentrancy
* Unchecked external call - call injection :
* Use of low level "call" should be a whene. If the call data is controllable, it is easy to cause arbitrary function execution.
* Private data :
* Private data ≠ Secure. It's readable from slots of the contract.
* Because the storage of each smart contract is public and transparent, and the content can be read through the corresponding slot in the specified contract address. Sensiti is not recommended to be placed in smart contract programs.
* Unprotected callback - ERC721 SafeMint reentrancy :
* _safeMint is secure? Attacker can reenter the mint function inside the onERC721Recei.
* Hidden Backdoor in Contract :
* An attacker can manipulate smart contracts as a backdoor by writing inline assembly. Any sensiti can be changed at any time.
* Bypass iscontract :
* The attacker only needs to write the code in the constructor of the smart contract to bypass the detection mechanism of whether it is a smart contract.
* DOS :
* External calls can fail accidentally or deliberately, which can cause a DoS condition in the contract. For example, contracts that recei do not contain fallback or recei. (DoS with unexpected revert)
* Real case : Charged Particles
* Randomness :
* Use of global like block hash, block number, block timestamp and other fields is insecure, miner and attacker can control it.
* :
* The default of the function is Public. If there is an unsafe setting, the attacker can directly call the sensiti in the smart contract.
* Real case : FlippazOne NFT | 88mph NFT | CoinstoreNFT Public Burn | Sandbox LAND Public Burn
* txorigin - phishing :
* tx.origin is a global in Solidity; using this for authentication in a smart contract makes the contract to phishing attacks.
* Uninitialized state :
* Uninitialized local storage may contain the value of other storage in the contract; this fact can cause unintentional , or be exploited deliberately.
* Storage collision 1 | Storage collision 2 (Audius) :
* If ’s storage location is fixed and it happens that there is another that has the same index/offset of the storage location in the implementation contract, then there will be a storage collision. REF
* Approval scam :
* Most current scams use approve or setAppro to defraud your transfer rights. Be especially careful with this part.
* Signature replay 1 | Signature replay 2 (NBA):
* Missing protection against signature replay attacks, Same signature can be used multiple times to execute a function. REF1, REF2, REF3, REF4, REF5
* Data location - storage :
* Incorrect use of storage slot and memory to sa state can easily cause contracts to use not updated for calculations. REF1, REF2
* DirtyBytes :
* Copying `bytes` arrays from memory or calldata to storage may result in dirty storage .
* In :
* Assert is used to check in. Those are states our contract or should ne, ever. For example, if we decrease a value then it should never get bigger, only smaller.
* NFT Mint Metadata :
* The contract is to C, this could lead to the early disclosure of metadata of all NFTs in the project. As a result, attacker can find out NFTs and then target mint of specific NFTs by monitoring mempool and sell the NFTs for a profit in secondary market
* The issue is the metadata should be after the minting is completed
* Divide before multiply :
* Performing multiplication before di is generally better to avoid loss of precision because Solidity integer di might truncate.
* Unchecked return value :
* Some tokens (like USDT) don't correctly implement the EIP20 standard and their transfer/ transferFrom function return void instead of a success boolean. Calling these functions with the correct EIP20 function signatures will always revert.
* No Revert on Failure :
* Some tokens do not revert on failure but instead return false, for example, ZRX.
* Incompatibility with deflationary / fee-on-transfer tokens :
* The actual deposited amount might be lower than the specified depositAmount of the function parameter. REF1 ,REF2, REF3
* Phantom function - Permit Function :
* Accepts any call to a function that it doesn't actually define, without re. For example: WETH. REF1, REF2
* Attack
* Token that does not support EIP-2612 permit.
* Token has a fallback function.
* First deposit bug :
* First depositor can break minting of shares: The attack and impact is the same as TOB-YEARN-003, where users may not recei in exchange for their deposits if the total asset amount has been manipulated through a large “donation”. REF1, REF2, REF3
* Empty loop :
* Due to insufficient , An attacker can simply pass an empty array to bypass the loop & signature . REF
* Unsafe downcasting :
* Downcasting from a larger integer type to a smaller one without checks can lead to unexpected behavior if the value of the larger integer is outside the range of the smaller one. This could lead to unexpected results due to o. REF1 , REF2
* Price manipulation :
* Incorrect price calculation o, getReverse may refer to a situation where the price of a token or asset is not accurately calculated based on the balanceOf function. REF
* ecReco address(0) :
* If isn't 27 or 28. it will return address(0). REF
* Oracle stale price :
* Oracle data feed is insufficiently . REF
* Precision Loss - Rounded down to zero :
* Avoid any situation that if the numerator is smaller than the denominator, the result will be zero. REF
* Slippage - Incorrect deadline & slippage amount :
* If both the slippage is set to 0 and there is no deadline, users might potentially lose all their tokens. REF
* abi.encodePacked() Hash Collisions :
* Using abi.encodePacked() with multiple length arguments can, in certain situations, lead to a hash collision.REF
* Struct Deletion O :
* Incomplete struct deletion lea data. If you delete a struct containing a mapping, the mapping won't be deleted.REF
* Array Deletion O :
* Incorrect array deletion leads to data inconsistency. REF
* txGasPrice manipulation :
* Manipulation of the txGasPrice value, which can result in unintended consequences and potential financial losses. REF
* Return :
* Use of return in inner loop iteration leads to unintended termination. REF
* Incorrect use of payable.transfer() or send() :
* Fixed 2300 gas, these shortcomings can make it impossible to successfully transfer ETH to the smart contract recipient. REF
* Unauthorized NFT Transfer in custom ERC721 implementation :
* Custom transferFrom function in contract , does not properly check if msg.sender is the current owner of the token or an appro. REF
* Missing Check for Self-Transfer Allows Funds to be Lost :
* The in the code stems from the absence of a check to prevent self-transfers. REF
* Incorrect implementation of the reco() function in the StakingRewards :
* The reco() function in StakingRewards.sol can potentially serve as a backdoor for the owner to retrie. REF
* Missing flash loan initiator check :
* Missing flash loan initiator check refers to a potential security in a flash loan implementation. REF
* Incorrect sanity checks - Multiple Unlocks Before Lock Time Elapse :
* This allows tokens to be unlocked multiple times before the lock period has elapsed, potentially leading to significant financial loss. REF
* Transient Storage Misuse :
* Transient storage (introduced in Solidity 0.8.24 with the Cancun network upgrade ) can be manipulated during callback functions, allowing attackers to bypass access controls by injecting arbitrary . This occurs due to de errors in handling transient storage, not due to inherent flaws in the EIP-1153 feature itself. REF

Bug Reproduce

20220714 Sherlock Yield Strategy Bug - Cross-protocol Reentrancy

#### Bounty: $250K POC | Reference

20220623 Sense Finance - Access control

Missing access control in onSwap()
#### Bounty: $50,000
Testing

#### Link reference

Spotthebugchallenge

* Immunefi #spotthebugchallenge 1 :
* Incorrect check msg.value, we can mint many NFTs with 1 ETH.
* Immunefi #spotthebugchallenge 2

Link reference

* Mastering Ethereum - Smart Contract Security

* Ethereum Smart Contract Best Practices

* Awesome-Smart-Contract-Security

* (Not So) Smart Contracts

* Smart Contract Attack

* Secureum Security Pitfalls 101

* Secureum Security Pitfalls 201
* How to Secure Your Smart Contracts: 6 Solidity and how to avoid them (Part 1)(Part 2)
* Top 10 DeFi Security Best Practices

项目信息

开发语言：Solidity

Star 数：1980

技术要点

该项目属于漏洞知识库方向的开源资源，代码结构清晰，适合安全研究人员学习参考。项目围绕To learn common smart contract vulnerabilities using Foundry!展开，提供了可运行的实现，对理解相关安全机制、工具原理与攻防技术具有较高的研究价值。

从技术实现角度看，此类项目的核心在于对底层原理的深入理解与工程化落地。开发者在研究过程中可以结合官方文档与社区讨论，梳理项目的初始化流程、核心模块职责与数据流转，逐步掌握其中的技术细节与设计思路。

使用与学习建议

1. 下载源码压缩包，解压到本地环境。

2. 根据项目类型准备对应的运行环境与依赖。

3. 按照 README 中的步骤完成配置与部署。

4. 在隔离的测试环境中运行验证，避免影响生产系统。

免责声明

本资源来源于开源社区，仅供安全研究、技术学习与合法授权范围内的攻防演练使用，请勿用于任何非法或侵害他人权益的用途。使用本项目产生的一切后果由使用者自行承担。