ช่องโหว่ทั่วไป (การเรียกซ้ำและอื่น ๆ)
ทำความเข้าใจและลดความเสี่ยงจากช่องโหว่ของสัญญาอัจฉริยะที่พบบ่อย เช่น การเรียกซ้ำ จำนวนเต็มล้นหรืออันเดอร์โฟลว์ และการโจมตีแบบแซงหน้า
ช่องโหว่ทั่วไป (การเรียกซ้ำและอื่น ๆ) เป็นบทเรียน Blockchain Smart Contracts with Solidity ฟรีบน CoddyKit นี่คือบทเรียนที่ 1 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Blockchain Smart Contracts with Solidity และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Blockchain Smart Contracts with Solidity มีบทเรียนทั้งหมด 4 บทเรียน
บางส่วนของบทเรียนนี้ยังไม่ได้รับการแปล และแสดงเป็นภาษาอังกฤษ
Smart Contract Security: Overview
Welcome to this crucial lesson on smart contract security! Unlike traditional software, bugs in smart contracts can lead to irreversible loss of funds.
Because contracts on the blockchain are often immutable, fixing vulnerabilities after deployment is incredibly difficult, if not impossible. Security must be a top priority from day one.
Understanding Reentrancy Attacks
Reentrancy is a critical vulnerability where an external call to an untrusted contract can 're-enter' the original contract before the first function call has completed its execution.
This allows the attacker to repeatedly drain funds or manipulate state by calling the vulnerable function multiple times.
Reentrancy: A Vulnerable Example
Consider this simplified withdrawal contract. Can you spot the potential issue?
The state (balances[msg.sender]) is updated *after* the external call to msg.sender.call. This delay creates a window for attack.
pragma solidity ^0.8.0;
contract VulnerableWithdraw {
mapping(address => uint) public balances;
constructor() payable {
// Fund contract for demo purposes
}
function deposit() public payable {
balances[msg.sender] += msg.value;
}
function withdraw(uint _amount) public {
require(balances[msg.sender] >= _amount, "Insufficient balance");
// External call FIRST, state update LATER
(bool success, ) = msg.sender.call{value: _amount}("");
require(success, "Transfer failed");
balances[msg.sender] -= _amount; // This line is vulnerable!
}
function getBalance() public view returns (uint) {
return address(this).balance;
}
}The Reentrancy Attack Flow
Here's how an attacker exploits the previous contract:
- 1. Deposit: Attacker deposits funds into
VulnerableWithdraw. - 2. Withdraw: Attacker calls
withdraw(amount). - 3. Re-enter: When
msg.sender.calltransfers Ether to the attacker, their malicious fallback function is triggered. - 4. Repeat: The fallback function immediately calls
withdraw(amount)again, before the original call updates the balance. This repeats until funds are drained.
Mitigating Reentrancy: The Fix
The most effective way to prevent reentrancy is to follow the Checks-Effects-Interactions (CEI) pattern:
- 1. Checks: Verify all conditions (e.g.,
requirestatements). - 2. Effects: Update all state variables (e.g.,
balances[msg.sender] -= _amount). - 3. Interactions: Make external calls (e.g.,
msg.sender.call).
This ensures state is updated *before* any untrusted external code can execute.
Reentrancy: The Fixed Contract
Here's the corrected version of the withdrawal contract, applying the CEI pattern. Notice the order of operations.
Now, the balance is decremented *before* the external call, closing the reentrancy window.
pragma solidity ^0.8.0;
contract SafeWithdraw {
mapping(address => uint) public balances;
constructor() payable {
// Fund contract for demo purposes
}
function deposit() public payable {
balances[msg.sender] += msg.value;
}
function withdraw(uint _amount) public {
// 1. Checks
require(balances[msg.sender] >= _amount, "Insufficient balance");
// 2. Effects: Update state BEFORE external call
balances[msg.sender] -= _amount;
// 3. Interactions: Make external call LAST
(bool success, ) = msg.sender.call{value: _amount}("");
require(success, "Transfer failed");
}
function getBalance() public view returns (uint) {
return address(this).balance;
}
}Integer Overflows & Underflows
Integer overflows occur when an arithmetic operation results in a value larger than the maximum that the variable type can hold. It 'wraps around' to its minimum value.
Integer underflows are the opposite: when a result is smaller than the minimum value, wrapping around to the maximum.
For example, a uint8 can hold values from 0 to 255. If it's 255 and you add 1, it becomes 0 (overflow). If it's 0 and you subtract 1, it becomes 255 (underflow).
Overflow/Underflow Example
Prior to Solidity 0.8.0, these operations would silently wrap around. Since Solidity 0.8.0, arithmetic operations default to checking for overflows/underflows and will revert if one occurs.
However, understanding the concept is vital, especially when working with older codebases or using unchecked blocks for gas optimization.
pragma solidity ^0.8.0;
contract MathVulnerabilities {
uint8 public smallNumber = 255; // Max for uint8
function triggerOverflow() public {
// In Solidity 0.8.0+, this transaction will revert.
// In older versions, smallNumber would become 0.
smallNumber = smallNumber + 1;
}
function triggerUnderflow() public {
smallNumber = 0; // Reset for demo
// In Solidity 0.8.0+, this transaction will revert.
// In older versions, smallNumber would become 255.
smallNumber = smallNumber - 1;
}
}Front-Running Attacks
Front-running is an attack where a malicious actor observes a pending transaction and submits their own transaction with a higher gas fee to have it executed first.
This is common in DeFi (Decentralized Finance) where transactions like large swaps or liquidations can be anticipated and exploited for profit.
Mitigating Front-Running
Preventing front-running is challenging due to the public nature of the mempool (pending transaction pool). However, some strategies exist:
- Commit-Reveal Schemes: Users submit a hashed version of their intent (commit), then later reveal the actual data.
- Batching: Grouping transactions together to reduce individual transaction visibility.
- Decentralized Sequencers/L2s: Using solutions that offer more private or controlled transaction ordering.
- Slippage Control: Users setting maximum acceptable price slippage for swaps.
Vulnerability Check
You've learned about three major smart contract vulnerabilities. Let's test your understanding!
Recap: Security First
In this lesson, we explored critical smart contract vulnerabilities: reentrancy, integer overflows/underflows, and front-running.
- We saw how reentrancy exploits external calls and how the Checks-Effects-Interactions pattern provides a robust defense.
- We understood how integer arithmetic can lead to unexpected values and the importance of compiler checks (Solidity 0.8.0+).
- Finally, we discussed front-running and methods like commit-reveal to mitigate it.
Always prioritize security in your smart contract development!
เรียนรู้ Blockchain Smart Contracts with Solidity ด้วย AI tutor — ฟรี
เขียนและเรียกใช้โค้ดจริงในเบราว์เซอร์ของคุณ รับความช่วยเหลือทันทีจาก AI tutor 24/7 และเรียนรู้ต่อจากที่คุณหยุดบนเว็บหรือในแอป
- คอร์ส
- 12
- บทเรียน
- 48
คำถามที่พบบ่อย
บทเรียน “ช่องโหว่ทั่วไป (การเรียกซ้ำและอื่น ๆ)” ฟรีหรือไม่
ใช่ — ข้อความเต็มของ “ช่องโหว่ทั่วไป (การเรียกซ้ำและอื่น ๆ)” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Blockchain Smart Contracts with Solidity ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Blockchain Smart Contracts with Solidity มีบทเรียนทั้งหมด 4 บทเรียน
คุณจะเรียนรู้อะไรในบทเรียน “ช่องโหว่ทั่วไป (การเรียกซ้ำและอื่น ๆ)”
ทำความเข้าใจและลดความเสี่ยงจากช่องโหว่ของสัญญาอัจฉริยะที่พบบ่อย เช่น การเรียกซ้ำ จำนวนเต็มล้นหรืออันเดอร์โฟลว์ และการโจมตีแบบแซงหน้า คุณปฏิบัติ Blockchain Smart Contracts with Solidity ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน
คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Blockchain Smart Contracts with Solidity หรือไม่
ไม่จำเป็นต้องมีประสบการณ์มาก่อน Blockchain Smart Contracts with Solidity บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 1 จากทั้งหมด 4 บทเรียน
บทเรียน “ช่องโหว่ทั่วไป (การเรียกซ้ำและอื่น ๆ)” ใช้เวลานานแค่ไหน
บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย
ฉันเขียนและรันโค้ดในบทเรียน Blockchain Smart Contracts with Solidity นี้ได้ไหม
ได้ บทเรียน Blockchain Smart Contracts with Solidity ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ
บทเรียนทั้งหมดในหลักสูตรนี้
- ช่องโหว่ทั่วไป (การเรียกซ้ำและอื่น ๆ)
- รูปแบบการควบคุมการเข้าถึง
- การเขียนโค้ดอย่างปลอดภัยด้วย SafeMath
- การตรวจสอบความปลอดภัย การทดสอบ และเงินรางวัลค้นหาข้อบกพร่อง