常见智能合约漏洞
研究智能合约中常见的安全漏洞，例如重入攻击、整数溢出与下溢，以及访问控制问题
常见智能合约漏洞 是 CoddyKit 上的免费 Web3 & DApp Development Fundamentals 课时。 这是第 1 节课，共 3 节。 你可以在下方免费阅读本课时的完整内容 — 然后在浏览器中使用内置代码编辑器和全天候 AI 导师进行实践。 这是 Web3 & DApp Development Fundamentals 学习路径的一部分，你的进度在网页和 CoddyKit 应用中同步。 Web3 & DApp Development Fundamentals 课程共包含 3 节课。
本课时的部分内容尚未翻译，以英文显示。
Why Security Matters
Smart contracts manage valuable assets and execute irreversible actions on the blockchain. A single vulnerability can lead to significant financial losses or unauthorized contract manipulation.
Unlike traditional software, deployed smart contracts are often immutable. This means that once a contract is live, fixing bugs or vulnerabilities can be extremely challenging, sometimes requiring complex upgrade mechanisms or even redeployment.
Reentrancy Explained
Reentrancy is a critical vulnerability where an external call from your contract to another contract or an external address can 're-enter' the calling contract before its original function call has completed its execution.
This allows an attacker to repeatedly execute certain parts of a function, often leading to unauthorized fund withdrawals or state manipulation, draining the contract's balance.
Vulnerable Reentrancy Example
In this example, the withdraw function first sends Ether (an external call) and then updates the user's balance. An attacker could re-enter withdraw multiple times before their balance is set to zero.
pragma solidity ^0.8.0;
contract VulnerableWithdraw {
mapping(address => uint) public balances;
constructor() payable {
balances[msg.sender] = msg.value;
}
function withdraw() public {
uint amount = balances[msg.sender];
require(amount > 0, "No funds to withdraw");
// Vulnerable: External call BEFORE state update
(bool success, ) = msg.sender.call{value: amount}("");
require(success, "Transfer failed");
balances[msg.sender] = 0; // State updated AFTER call
}
function deposit() public payable {
balances[msg.sender] += msg.value;
}
function getBalance() public view returns (uint) {
return address(this).balance;
}
}Preventing Reentrancy
The most effective defense against reentrancy is the Checks-Effects-Interactions pattern. This pattern dictates the order of operations within your functions:
- Checks: Verify all conditions (e.g.,
requirestatements). - Effects: Make all necessary state changes (e.g., update balances, modify variables).
- Interactions: Perform any external calls (e.g., sending Ether, calling another contract).
Always update the contract's state *before* sending Ether or calling external contracts.
Secure Withdrawal Function
Here's the corrected withdraw function. Notice how the user's balance is updated (an 'effect') *before* the Ether is sent (an 'interaction').
pragma solidity ^0.8.0;
contract SecureWithdraw {
mapping(address => uint) public balances;
constructor() payable {
balances[msg.sender] = msg.value;
}
function withdraw() public {
uint amount = balances[msg.sender];
require(amount > 0, "No funds to withdraw");
balances[msg.sender] = 0; // Effect: State updated BEFORE call
(bool success, ) = msg.sender.call{value: amount}(""); // Interaction
require(success, "Transfer failed");
}
function deposit() public payable {
balances[msg.sender] += msg.value;
}
function getBalance() public view returns (uint) {
return address(this).balance;
}
}Integer Overflow & Underflow
Integer types in Solidity (like uint or int) have a fixed size. An overflow occurs when an arithmetic operation results in a value larger than the maximum an integer type can hold, causing it to 'wrap around' to its minimum value (e.g., 255 + 1 on a uint8 becomes 0).
An underflow occurs when an operation results in a value smaller than the minimum (usually 0 for uint), causing it to wrap around to its maximum value (e.g., 0 - 1 on a uint8 becomes 255).
Vulnerable Integer Logic
Before Solidity 0.8.0, these wrap-around behaviors were not automatically checked. This example, using an older Solidity version, shows how an attacker could exploit an underflow to gain a massive balance.
pragma solidity ^0.7.0; // Using 0.7.x to demonstrate vulnerability
contract VulnerableCounter {
uint public count = 0;
// If count is 0 and _amount is 1, count becomes type(uint).max
function decrement(uint _amount) public {
count -= _amount; // Vulnerable to underflow
}
// If count + _amount exceeds type(uint).max, count wraps around to a small number
function increment(uint _amount) public {
count += _amount; // Vulnerable to overflow
}
}Mitigating Overflow/Underflow
Since Solidity 0.8.0, arithmetic operations automatically revert (fail) on overflow or underflow. This provides robust protection against these issues by default, making your contracts much safer.
For contracts written in older Solidity versions (pre-0.8.0), it was common to use libraries like OpenZeppelin's SafeMath. SafeMath provided functions (add, sub, mul, div) that performed checked arithmetic, reverting if an overflow or underflow would occur.
Access Control Issues
Access control ensures that only authorized users or roles can perform specific, sensitive actions within a smart contract. Incorrect access control is a very common source of vulnerabilities.
Common mistakes include:
- Missing authorization checks for critical functions (e.g., administrative functions).
- Using
msg.senderdirectly without verifying ownership or role. - Weak or easily guessable authorization mechanisms.
Vulnerable Access Control
In this example, the setCriticalValue function is intended to be for the contract owner only, but it lacks any check to enforce this. Any user could call this function and change the critical value.
The onlyOwner modifier shows the correct way to restrict access.
pragma solidity ^0.8.0;
contract VulnerableAccess {
address public owner;
uint public criticalValue;
constructor() {
owner = msg.sender;
criticalValue = 100;
}
// Vulnerable: This function should be owner-only, but it's public!
function setCriticalValue(uint _newValue) public {
criticalValue = _newValue; // Anyone can call this!
}
// Correct way to restrict access using a modifier
function setCriticalValueSecure(uint _newValue) public onlyOwner {
criticalValue = _newValue;
}
modifier onlyOwner() {
require(msg.sender == owner, "Not owner");
_;
}
}Vulnerability Check
Which of the following patterns is designed to prevent reentrancy attacks by ensuring state changes occur before external calls?
Recap: Secure Smart Contracts
Today, we've covered some of the most common and critical smart contract vulnerabilities:
- Reentrancy: Prevented by following the Checks-Effects-Interactions pattern.
- Integer Overflow/Underflow: Mitigated by using Solidity 0.8.0+ (automatic checks) or SafeMath for older versions.
- Access Control Issues: Secured by implementing proper authorization checks using modifiers like
onlyOwner.
Always prioritize security in your smart contract development. Thoroughly auditing your code and adhering to best practices are essential steps to protect assets and ensure the reliability of your decentralized applications.
常见问题解答
「常见智能合约漏洞」课时是免费的吗？
是的 — 「常见智能合约漏洞」的完整文本可在网页上免费阅读。要进行交互式练习（内置代码编辑器和全天候 AI 导师）并解锁 Web3 & DApp Development Fundamentals 课程的其余内容，请升级到 CoddyKit PRO。 Web3 & DApp Development Fundamentals 课程共包含 3 节课。
「常见智能合约漏洞」这节课中我会学到什么？
研究智能合约中常见的安全漏洞，例如重入攻击、整数溢出与下溢，以及访问控制问题 你通过在浏览器中直接运行的动手代码来练习 Web3 & DApp Development Fundamentals，全天候 AI 导师会在你学习这节课的过程中回答你的问题。
学习 Web3 & DApp Development Fundamentals 需要有经验吗？
无需任何先前经验。CoddyKit 上的 Web3 & DApp Development Fundamentals 课程适合初学者到高级学习者，你可以从这里开始或从头开始，按照自己的节奏学习。 这是第 1 节课，共 3 节。
「常见智能合约漏洞」课时需要多长时间？
大多数 CoddyKit 课程大约需要 5–10 分钟。每节课都很精短且互动，所以你能稳步进步，并在网页和应用中从离开的地方继续。
我能在这节 Web3 & DApp Development Fundamentals 课中编写并运行代码吗？
能。每节 Web3 & DApp Development Fundamentals 课都包含内置代码编辑器，你可以在浏览器中直接编写并运行真实代码，并获得即时 AI 反馈 — 无需本地设置。