Tìm hiểu sâu về tấn công Reentrancy và cách phòng chống hiệu quả

2026-03-19 09:06:37

Tấn công reentrancy là một trong những mối đe dọa bảo mật nghiêm trọng nhất đối với các smart contract. Bài viết này sẽ hướng dẫn bạn không chỉ cách hoạt động của reentrancy mà còn cách bảo vệ dự án của bạn một cách toàn diện.

Để có cái nhìn hoàn chỉnh, chúng ta sẽ bắt đầu từ những khái niệm cơ bản, sau đó phân tích mã nguồn của các cuộc tấn công thực tế, và cuối cùng khám phá ba kỹ thuật phòng chống được chứng minh: từ modifier nonReentrant() cho đến GlobalReentrancyGuard() và mẫu kiểm tra-hiệu ứng-tương tác.

Reentrancy là một loại cuộc tấn công gì?

Hãy tưởng tượng hai smart contract tương tác với nhau. ContractA và ContractB hoàn toàn có khả năng gọi lẫn nhau. Điều đó có vẻ bình thường, nhưng đó chính là lỗ hổng mà kẻ tấn công có thể khai thác.

Khái niệm cốt lõi của reentrancy là: một smart contract có thể gọi ngược lại một hợp đồng khác khi hợp đồng kia vẫn đang thực thi. Điều này tạo ra một vòng lặp vô tận nếu không được kiểm soát đúng cách.

Để minh họa, hãy xem xét tình huống sau: ContractA nắm giữ 10 Ether, trong đó ContractB đã gửi 1 Ether vào đó. Về mặt bình thường, khi ContractB yêu cầu rút tiền, nó sẽ được kiểm tra (số dư > 0), nhận Ether, rồi số dư được đặt về 0. Nhưng với reentrancy, quá trình này có thể được lặp lại nhiều lần trước khi bước cập nhật số dư diễn ra.

Cơ chế hoạt động của tấn công Reentrancy

Kẻ tấn công cần hai thành phần chính: một hàm attack() và một hàm fallback().

Hàm fallback là một hàm đặc biệt trong Solidity - một hàm bên ngoài không có tên, không có tham số và không có giá trị trả về. Nó được kích hoạt tự động khi:

Ai đó gọi một hàm không tồn tại trong hợp đồng
Dữ liệu được gửi đến hợp đồng mà không có chỉ định hàm
Ether được chuyển đến hợp đồng mà không có bất kỳ dữ liệu nào

Bây giờ hãy theo dõi cách cuộc tấn công diễn ra từng bước:

Bước 1: Kẻ tấn công gọi hàm attack(), bên trong gọi hàm rút tiền từ ContractA.

Bước 2: ContractA kiểm tra xem số dư của ContractB có lớn hơn 0 hay không. Vì đúng như vậy, nó gửi 1 Ether đến ContractB và kích hoạt hàm fallback.

Bước 3: Lúc này là điểm mấu chốt - chưa ai cập nhật số dư về 0. ContractA vẫn đang chạy mã của hàm rút.

Bước 4: Hàm fallback được kích hoạt và ngay lập tức gọi lại hàm rút tiền của ContractA.

Bước 5: ContractA kiểm tra lại - số dư ContractB vẫn còn 1 Ether (vì bước cập nhật chưa diễn ra). Nó lại gửi 1 Ether và kích hoạt fallback lần nữa.

Quá trình này lặp đi lặp lại cho đến khi ContractA cạn kiệt tất cả Ether. Đó là lý do tại sao reentrancy lại nguy hiểm đến vậy.

Phân tích mã tấn công cụ thể

Để hiểu rõ hơn, hãy xem một ví dụ cụ thể với smart contract EtherStore. Contract này có hai hàm chính:

deposit(): lưu trữ và cập nhật số dư người gửi
withdrawAll(): rút toàn bộ số dư cùng lúc

Hàm withdrawAll() thực hiện theo thứ tự: kiểm tra (xác minh số dư > 0), gửi Ether, rồi cập nhật số dư về 0.

Đó chính là lỗ hổng. Vì gửi Ether diễn ra trước khi cập nhật, kẻ tấn công có cơ hội can thiệp.

Contract Attack được thiết kế để khai thác điều này. Nó có:

Một constructor nhận địa chỉ của EtherStore
Một hàm fallback() sẽ gọi lại withdrawAll() miễn là còn Ether
Một hàm attack() để bắt đầu cuộc tấn công

Quy trình tấn công rất đơn giản:

Kẻ tấn công gọi attack() với đủ Ether
attack() gửi 1 Ether vào EtherStore để tạo số dư > 0
attack() gọi withdrawAll() từ EtherStore
EtherStore gửi 1 Ether → kích hoạt fallback của Attack
fallback gọi lại withdrawAll() vì số dư vẫn chưa được cập nhật
Vòng lặp này tiếp tục cho đến khi EtherStore cạn Ether

Ba kỹ thuật phòng chống tấn công Reentrancy

Kỹ thuật 1: Sử dụng Modifier nonReentrant

Cách đơn giản nhất để bảo vệ một hàm duy nhất là sử dụng modifier nonReentrant. Modifier là một loại hàm đặc biệt trong Solidity cho phép bạn thêm các điều kiện hoặc chức năng bổ sung vào các hàm khác mà không cần viết lại toàn bộ logic.

Cách hoạt động của nonReentrant:

Nó khóa contract khi hàm bắt đầu thực thi
Bất kỳ lệnh gọi lại nào trong khi đó sẽ bị từ chối
Chỉ khi hàm hoàn thành, khóa mới được mở

Nhược điểm: nonReentrant chỉ bảo vệ một hàm duy nhất, không che phủ các cuộc tấn công reentrancy chéo giữa các hàm khác nhau.

Kỹ thuật 2: Mẫu Check-Effect-Interaction

Đây là cách tinh vi hơn để bảo vệ multiple functions. Thay vì khóa contract, bạn thay đổi thứ tự thực thi mã.

Mẫu này yêu cầu:

Check (Kiểm tra): Xác minh tất cả các điều kiện trước (require statements)
Effect (Hiệu ứng): Cập nhật tất cả trạng thái sau ngay lập tức
Interaction (Tương tác): Chỉ cuối cùng mới gọi external contracts hoặc gửi Ether

So sánh mã dễ bị tấn công với mã an toàn:

Dễ bị tấn công: Check → Gửi Ether → Cập nhật số dư (lỗ hổng nằm giữa gửi và cập nhật)
An toàn: Check → Cập nhật số dư → Gửi Ether

Bằng cách đặt cập nhật số dư ngay sau kiểm tra, bạn đảm bảo rằng ngay cả khi có lệnh gọi lại, số dư sẽ luôn được cập nhật trước, làm vô hiệu hóa cuộc tấn công.

Kỹ thuật 3: GlobalReentrancyGuard cho Multiple Contracts

Kỹ thuật này dành cho các dự án có nhiều smart contracts tương tác với nhau. Ý tưởng là tạo một hợp đồng trung tâm giúp kiểm tra reentrancy trên toàn bộ hệ thống.

Thay vì mỗi contract có biến khóa riêng, tất cả đều tham chiếu đến một GlobalReentrancyGuard. Điều này cho phép:

Kiểm soát reentrancy giữa các contracts khác nhau
Tránh các cuộc tấn công chain-reentrancy phức tạp

Ví dụ trong thực tế: nếu ScheduledTransfer gửi Ether cho AttackTransfer, hàm fallback của AttackTransfer có thể cố gắng gọi lại các hàm khác trong ScheduledTransfer. GlobalReentrancyGuard sẽ phát hiện và chặn điều này.

Chọn kỹ thuật phòng chống phù hợp

Sử dụng nonReentrant khi:

Bạn chỉ cần bảo vệ một hoặc vài hàm nhất định
Overhead chi phí không phải là vấn đề quan trọng
Không cần lo lắng về reentrancy giữa các hàm

Sử dụng Check-Effect-Interaction khi:

Bạn muốn tối ưu hóa chi phí gas
Smart contract của bạn có nhiều hàm cần bảo vệ
Bạn muốn áp dụng best practice toàn bộ project

Sử dụng GlobalReentrancyGuard khi:

Dự án của bạn có hệ thống contracts phức tạp
Các contracts thường xuyên tương tác với nhau
Bạn cần một lớp bảo vệ tập trung và thống nhất

Cách tốt nhất là kết hợp cả ba kỹ thuật này tùy theo nhu cầu cụ thể của từng phần trong dự án của bạn.

Kết luận

Tấn công reentrancy không phải là một mối đe dọa quá khó để phòng chống, miễn là bạn hiểu rõ cách hoạt động của nó và áp dụng đúng kỹ thuật. Từ modifier nonReentrant đơn giản cho đến GlobalReentrancyGuard toàn diện, mỗi công cụ đều có vai trò riêng trong hệ sinh thái bảo mật smart contract.

Hãy nhớ rằng, bảo mật không phải là một lựa chọn mà là một bắt buộc. Bằng cách hiểu rõ các cuộc tấn công reentrancy và triển khai các phòng chống thích hợp, bạn sẽ xây dựng được các smart contracts vừa an toàn vừa hiệu quả.

Để cập nhật thêm về bảo mật Web3, Solidity, kiểm tra smart contract và các vấn đề liên quan, hãy theo dõi @TheBlockChainer trên Twitter.

Trang này có thể chứa nội dung của bên thứ ba, được cung cấp chỉ nhằm mục đích thông tin (không phải là tuyên bố/bảo đảm) và không được coi là sự chứng thực cho quan điểm của Gate hoặc là lời khuyên về tài chính hoặc chuyên môn. Xem Tuyên bố từ chối trách nhiệm để biết chi tiết.