Tấn công tái nhập (Reentrancy Attack)

Tấn công tái nhập trong crypto là gì?

Tấn công tái nhập là một hình thức khai thác hợp đồng thông minh, trong đó hợp đồng bên ngoài gọi ngược lại hợp đồng dễ bị tấn công trước khi lệnh gọi hàm đầu tiên hoàn tất.

Trong crypto, kiểu tấn công này thường nhắm vào các hợp đồng thông minh nắm giữ tiền, theo dõi số dư, xử lý lệnh rút, tính phần thưởng, quản lý cổ phần trong vault hoặc tương tác với hợp đồng khác.

Vấn đề cốt lõi là hợp đồng dễ bị tấn công trao quyền kiểm soát cho hợp đồng khác trước khi cập nhật xong trạng thái nội bộ của mình.

Nếu kẻ tấn công có thể gọi lại hợp đồng khi trạng thái chưa được cập nhật xong, họ có thể lặp lại một hành động vốn chỉ được phép thực hiện một lần.

Ví dụ phổ biến là hàm rút tiền gửi crypto cho người dùng trước khi giảm số dư được ghi nhận của họ.

Nếu bên nhận là hợp đồng độc hại, hợp đồng này có thể dùng logic fallback hoặc callback để gọi lại hàm rút trước khi số dư được cập nhật.

Điều này có thể cho phép kẻ tấn công rút nhiều hơn số tiền họ được quyền nhận.

Trang về tấn công tái nhập trong Top 10 hợp đồng thông minh OWASP 2026 định nghĩa tái nhập là tình huống hợp đồng thực hiện lệnh gọi bên ngoài và hợp đồng được gọi gọi ngược vào hợp đồng ban đầu trước khi trạng thái được cập nhật đầy đủ.

Tái nhập là một trong những lỗ hổng hợp đồng thông minh nổi tiếng nhất vì nó trực tiếp tấn công mô hình tin cậy của hoạt động kế toán on-chain.

Kiểu tấn công này đặc biệt nguy hiểm trong tài chính phi tập trung vì hợp đồng thông minh thường quản lý các pool thanh khoản lớn và phụ thuộc vào hợp đồng khác để hoán đổi, thế chấp, nhận phần thưởng hoặc lấy dữ liệu giá.

Tấn công tái nhập hoạt động như thế nào?

Tấn công tái nhập bắt đầu khi hợp đồng thông minh dễ bị tấn công thực hiện lệnh gọi bên ngoài đến một hợp đồng hoặc địa chỉ khác.

Lệnh gọi bên ngoài đó có thể gửi tiền mã hóa gốc, chuyển token, gọi một hook, yêu cầu callback, thực thi chiến lược hoặc tương tác với giao thức khác.

Khi hợp đồng dễ bị tấn công thực hiện lệnh gọi đó, hợp đồng nhận tạm thời có cơ hội chạy mã của mình.

Nếu hợp đồng nhận do kẻ tấn công kiểm soát, kẻ tấn công có thể tận dụng thời điểm đó để gọi ngược vào hợp đồng dễ bị tấn công.

Hợp đồng dễ bị tấn công có thể vẫn đang sử dụng các giá trị trạng thái cũ vì chưa cập nhật số dư, khoản nợ, cổ phần, chỉ số phần thưởng hoặc cờ khóa.

Kẻ tấn công có thể lợi dụng các giá trị cũ để lặp lại lệnh rút, nhận phần thưởng hai lần, vay vượt mức cho phép hoặc thao túng phép tính.

Cuộc tấn công tiếp diễn cho đến khi hợp đồng dễ bị tấn công cạn tiền, giao dịch hết gas hoặc cơ chế bảo vệ ngăn chặn các lệnh gọi lặp lại.

Tài liệu Solidity về lệnh gọi bên ngoài cảnh báo rằng khi tương tác với hợp đồng khác, quyền kiểm soát được chuyển cho hợp đồng đó và hợp đồng được gọi có thể gọi ngược vào hợp đồng ban đầu trước khi lệnh gọi đầu tiên trả về.

Cảnh báo này là nền tảng của các biện pháp phòng vệ trước tấn công tái nhập.

Mọi lệnh gọi bên ngoài đều cần được xem là thời điểm mà các giả định của hợp đồng có thể bị phá vỡ.

Ví dụ đơn giản về tấn công tái nhập

Hãy tưởng tượng một hợp đồng cho vay ghi nhận số dư tiền gửi của từng người dùng.

Một người dùng nạp 10 ETH vào hợp đồng.

Hợp đồng ghi nhận số dư của người dùng là 10 ETH.

Sau đó, người dùng gọi hàm rút để nhận lại 10 ETH.

Hợp đồng an toàn sẽ giảm số dư của người dùng về 0 trước khi gửi ETH.

Hợp đồng dễ bị tấn công lại gửi ETH trước rồi mới cập nhật số dư.

Nếu người dùng thực chất là một hợp đồng độc hại, hàm receive của hợp đồng đó có thể chạy khi ETH được gửi đến.

Hàm receive có thể gọi ngay lại hàm rút trong khi hợp đồng dễ bị tấn công vẫn cho rằng người dùng có 10 ETH.

Lệnh rút tương tự có thể được thực hiện lặp đi lặp lại trong cùng một giao dịch.

Đây là lý do thứ tự logic trong hợp đồng thông minh rất quan trọng.

Trong phần mềm truyền thống, lỗi sắp xếp thứ tự nhỏ có thể gây ra sai sót kế toán thông thường.

Trong hợp đồng thông minh nắm giữ tài sản crypto, cùng lỗi sắp xếp thứ tự đó có thể trực tiếp tạo điều kiện đánh cắp tài sản.

Vì sao tấn công tái nhập nguy hiểm?

Tấn công tái nhập nguy hiểm vì hợp đồng thông minh thường kiểm soát tài sản khó thu hồi sau khi bị khai thác.

Blockchain công khai được thiết kế để thực thi các giao dịch hợp lệ và lưu giữ lịch sử của chúng.

Nếu giao dịch độc hại tuân theo quy tắc của blockchain nhưng khai thác lỗi hợp đồng, việc đảo ngược thiệt hại thường rất khó khăn.

Hướng dẫn bảo mật hợp đồng thông minh của Ethereum.org giải thích rằng mã hợp đồng thông minh đã triển khai thường khó thay đổi và tài sản bị đánh cắp rất khó thu hồi do tính bất biến của blockchain.

Điều này khiến việc phòng ngừa quan trọng hơn nhiều so với khắc phục sau sự cố.

Lỗi tái nhập có thể rút cạn pool thanh khoản, vault, bridge, hệ thống staking, sàn NFT, hợp đồng thưởng và giao thức cho vay.

Lỗi này cũng có thể làm tổn hại niềm tin của người dùng, ngay cả khi số tài sản bị đánh cắp được thu hồi sau đó.

Trong crypto, rủi ro hợp đồng thông minh không chỉ là vấn đề của nhà phát triển.

Rủi ro này có thể đồng thời trở thành vấn đề của người dùng, thanh khoản, quản trị và danh tiếng.

Tái nhập kiểu cổ điển

Tái nhập kiểu cổ điển xảy ra khi kẻ tấn công gọi lại chính hàm đã thực hiện lệnh gọi bên ngoài.

Ví dụ phổ biến nhất là hàm rút dễ bị tấn công.

Hàm kiểm tra số dư của người dùng, gửi tiền cho người dùng rồi mới cập nhật số dư.

Hợp đồng của kẻ tấn công nhận tiền và gọi lại chính hàm rút đó trước khi số dư bị giảm.

Điều này tạo ra vòng lặp, trong đó cùng một số dư được ghi nhận có thể bị sử dụng nhiều lần.

Tái nhập kiểu cổ điển dễ hiểu nhưng vẫn nguy hiểm vì nhiều nhà phát triển tiếp tục đặt logic gọi bên ngoài quá sớm.

Kiểu tấn công này cũng nguy hiểm vì hợp đồng hiện đại thường có hoạt động kế toán phức tạp hơn so với một bảng ánh xạ tiền gửi và rút tiền đơn giản.

Hàm dễ bị tấn công có thể liên quan đến cổ phần, vị thế nợ, hệ số nhân phần thưởng, tài sản vault, token thanh khoản hoặc việc tính phí.

Ngay cả khi cách thức trông khác với ví dụ cổ điển, vấn đề cốt lõi tương tự vẫn có thể tồn tại.

Tái nhập chéo hàm

Tái nhập chéo hàm xảy ra khi kẻ tấn công gọi lại một hàm khác trong cùng hợp đồng.

Kiểu này khó nhận biết hơn tái nhập cổ điển vì khi được xem xét riêng, hàm bị tấn công có thể trông như an toàn.

Ví dụ, một hàm có thể bắt đầu quy trình rút tiền và thực hiện lệnh gọi bên ngoài.

Trong khi lệnh gọi bên ngoài đang diễn ra, kẻ tấn công có thể gọi một hàm khác dựa trên cùng số dư, cổ phần hoặc trạng thái quyền hạn.

Nếu hàm đầu tiên chưa cập nhật xong trạng thái, hàm thứ hai có thể đọc thông tin cũ.

Điều này có thể cho phép kẻ tấn công nhận phần thưởng, chuyển cổ phần, vay tài sản hoặc thay đổi vị thế trước khi thao tác đầu tiên hoàn tất.

Tái nhập chéo hàm cho thấy nhà phát triển cần suy nghĩ về các bất biến của toàn bộ hợp đồng thay vì chỉ bảo vệ một hàm rút dễ thấy.

Bất biến hợp đồng là quy tắc cần luôn đúng trước và sau mọi thao tác hợp lệ.

Nếu lệnh gọi bên ngoài có thể tạm thời phá vỡ một bất biến, các hàm khác có thể trở thành đường tấn công.

Tái nhập chéo hợp đồng

Tái nhập chéo hợp đồng xảy ra khi đường callback đi qua nhiều hợp đồng.

Tình huống này có thể xảy ra trong hệ thống DeFi, nơi vault, chiến lược, router, hợp đồng token, bộ đọc oracle, mô-đun staking và đơn vị phân phối phần thưởng tương tác với nhau.

Vault có thể gọi một chiến lược.

Chiến lược có thể gọi token hoặc giao thức khác.

Hợp đồng được gọi có thể kích hoạt callback quay lại vault hoặc một hợp đồng liên quan mà vault phụ thuộc vào.

Trạng thái dễ bị tấn công có thể không nằm trong cùng hợp đồng đã thực hiện lệnh gọi bên ngoài đầu tiên.

Các lưu ý bảo mật của Solidity đề cập rằng tái nhập không chỉ xuất phát từ việc chuyển Ether và cần xem xét cả các tình huống liên quan đến nhiều hợp đồng.

Điều này quan trọng vì các ứng dụng crypto hiện đại có khả năng kết hợp cao.

Khả năng kết hợp cho phép các giao thức kết nối và xây dựng dựa trên nhau, nhưng cũng tạo thêm nhiều đường dẫn cho callback ngoài dự kiến.

Tái nhập chỉ đọc

Tái nhập chỉ đọc xảy ra khi hàm view hoặc hàm đọc trả về thông tin gây hiểu lầm trong lúc quá trình chuyển trạng thái chưa hoàn tất.

Thoạt nhìn, vấn đề này có vẻ vô hại vì hàm view không trực tiếp thay đổi trạng thái.

Tuy nhiên, hợp đồng khác có thể dùng hàm view để tính giá, cổ phần, giá trị tài sản thế chấp, tỷ giá hoặc số lượng phần thưởng.

Nếu callback xảy ra khi một hợp đồng đang ở trạng thái trung gian, hàm view có thể trả về giá trị tạm thời không đáng tin cậy.

Kẻ tấn công có thể sử dụng giá trị tạm thời đó trong một hợp đồng khác dựa vào giá trị này.

Điều này có thể gây ra thao túng kiểu oracle hoặc sai sót kế toán mà không cần trực tiếp rút cạn hợp đồng đầu tiên thông qua hàm rút thông thường.

Tái nhập chỉ đọc nhắc nhở rằng bảo mật không chỉ liên quan đến việc một hàm có ghi dữ liệu vào bộ nhớ hay không.

Bảo mật còn phụ thuộc vào việc hợp đồng khác có thể quan sát trạng thái chưa hoàn chỉnh và đưa ra quyết định tài chính dựa trên trạng thái đó hay không.

Tái nhập qua hook

Tái nhập qua hook xảy ra khi tiêu chuẩn token hoặc giao diện giao thức chủ động gọi logic của bên nhận trong quá trình chuyển hoặc thao tác.

Một số tiêu chuẩn token và NFT có hook nhận để hợp đồng có thể phản hồi khi nhận tài sản.

Hệ thống flash loan cũng sử dụng callback để bên vay có thể sử dụng thanh khoản đã vay và hoàn trả trong cùng một giao dịch.

Những hook này hữu ích nhưng cũng tạo cơ hội cho callback.

Nếu hợp đồng cho rằng chuyển token chỉ là thao tác đơn giản, không thực thi mã bên ngoài, giả định đó có thể không đúng.

Tùy vào tiêu chuẩn và cách triển khai token, một giao dịch chuyển có thể kích hoạt logic của bên nhận, hook của operator hoặc hành vi hợp đồng khác.

Nhà phát triển nên xem xét mọi tương tác token bên ngoài như một điểm có thể xảy ra tái nhập.

Điều này đặc biệt quan trọng với hợp đồng hỗ trợ nhiều token, nhiều tài sản vault hoặc nhiều tích hợp bên ngoài.

Các mục tiêu thường gặp của tấn công tái nhập

Hàm rút là mục tiêu tái nhập phổ biến nhất vì thường gửi tiền ra khỏi hợp đồng.

Hàm nạp và rút của vault cũng thường bị nhắm đến vì chúng cập nhật số dư cổ phần và hạch toán tài sản.

Giao thức cho vay có thể trở thành mục tiêu vì theo dõi tài sản thế chấp, khoản nợ, lãi suất, ngưỡng thanh lý và số dư đã vay.

Hợp đồng staking có thể trở thành mục tiêu vì tính phần thưởng theo thời gian và có thể chuyển token thưởng khi người dùng nhận thưởng.

Sàn NFT có thể trở thành mục tiêu vì việc mua bán và thanh toán có thể kích hoạt hook nhận token hoặc logic tiền bản quyền bên ngoài.

Hợp đồng bridge có thể trở thành mục tiêu vì quản lý thông điệp cross-chain, khóa tài sản và logic giải phóng tài sản.

Hợp đồng thực thi quản trị có thể trở thành mục tiêu vì gọi hợp đồng bên ngoài trong lúc thực thi đề xuất.

Hợp đồng nhận flash loan và nhà cung cấp flash loan có thể trở thành mục tiêu vì thiết kế của chúng phụ thuộc vào callback.

Mọi hợp đồng thông minh gửi giá trị hoặc gọi mã không đáng tin cậy trước khi hoàn tất kế toán nội bộ đều cần được xem là mục tiêu tiềm năng của tấn công tái nhập.

Mẫu Checks-Effects-Interactions

Mẫu Checks-Effects-Interactions là một trong những biện pháp phòng vệ quan trọng nhất trước tấn công tái nhập.

Checks (kiểm tra) nghĩa là hợp đồng xác minh trước rằng người dùng được phép thực hiện thao tác.

Effects (cập nhật trạng thái) nghĩa là hợp đồng cập nhật trạng thái nội bộ trước khi thực hiện bất kỳ lệnh gọi bên ngoài nào.

Interactions (tương tác) nghĩa là hợp đồng chỉ thực hiện lệnh gọi bên ngoài sau khi hoàn tất kiểm tra và cập nhật trạng thái.

Với hàm rút, hợp đồng nên kiểm tra số dư của người dùng, giảm số dư rồi mới gửi tiền.

Nhờ vậy, nếu bên nhận cố gắng gọi lại, hợp đồng đã ghi nhận số dư mới.

Tài liệu Solidity về Checks-Effects-Interactions mô tả mẫu này là phương pháp phổ biến để ngăn chặn tấn công tái nhập.

Mẫu này đơn giản nhưng không thể bỏ qua đối với hợp đồng tương tác với mã bên ngoài không đáng tin cậy.

Nhà phát triển nên mặc định áp dụng mẫu này bất cứ khi nào một hàm thay đổi trạng thái và gọi ra bên ngoài hợp đồng.

Reentrancy guard

Reentrancy guard là một khóa ngăn hàm được bảo vệ bị gọi lại trước khi lệnh gọi đầu tiên hoàn tất.

Trong hợp đồng Solidity, cơ chế này thường được triển khai bằng biến trạng thái đánh dấu hàm đang được thực thi.

Nếu lệnh gọi tái nhập cố gắng đi vào cùng đường dẫn đã được bảo vệ, guard sẽ từ chối lệnh gọi đó.

Tài liệu ReentrancyGuard của OpenZeppelin Contracts 5.x mô tả ReentrancyGuard là mô-đun cung cấp modifier nonReentrant để ngăn các lệnh gọi tái nhập lồng nhau.

Reentrancy guard hữu ích vì bổ sung một lớp bảo vệ rõ ràng cho các hàm rủi ro cao.

Tuy nhiên, guard không thay thế cho việc hạch toán chính xác.

Nhà phát triển vẫn cần áp dụng Checks-Effects-Interactions và rà soát mọi lệnh gọi bên ngoài.

OpenZeppelin cũng lưu ý rằng do chỉ có một guard nonReentrant, các hàm được đánh dấu nonReentrant không thể gọi trực tiếp lẫn nhau.

Một cách khắc phục phổ biến là đặt logic nội bộ ở hàm private và tạo các điểm truy cập bên ngoài riêng biệt được bảo vệ bằng nonReentrant.

Transient storage và khóa chống tái nhập

Transient storage là một tính năng EVM mới hơn, có thể được dùng cho các giá trị tạm thời chỉ tồn tại trong thời gian diễn ra một giao dịch.

Tính năng này có thể hữu ích cho khóa chống tái nhập vì khóa không phải lúc nào cũng cần được giữ trong bộ nhớ cố định sau khi lệnh gọi kết thúc.

Tài liệu ReentrancyGuardTransient của OpenZeppelin mô tả phiên bản ReentrancyGuard dùng transient storage dành cho các blockchain có EIP-1153.

Tài liệu Solidity về transient storage cho biết việc dùng transient storage cho khóa chống tái nhập, được xóa khi khung gọi kết thúc, là an toàn.

Điều này không có nghĩa hợp đồng nào cũng nên tự động sử dụng transient storage.

Nhà phát triển phải xác nhận blockchain mục tiêu hỗ trợ tính năng cần thiết và khóa được xóa đúng cách.

Khóa được quản lý kém có thể làm giảm khả năng kết hợp hoặc khiến hợp đồng khó sử dụng trong các giao dịch phức tạp.

Lựa chọn phù hợp nhất phụ thuộc vào blockchain mục tiêu, phiên bản compiler, phiên bản thư viện, phương thức nâng cấp và yêu cầu kiểm toán.

Vì sao transfer và send không phải biện pháp phòng vệ hoàn chỉnh?

Hướng dẫn Solidity trước đây thường xem việc giới hạn gas khi chuyển tiền là một biện pháp giảm thiểu tái nhập thiết thực.

Hướng dẫn hiện đại thận trọng hơn vì chi phí gas và hành vi EVM có thể thay đổi theo thời gian.

Tài liệu Solidity về các thành viên của kiểu address cảnh báo rằng send và transfer đã lỗi thời, đồng thời khuyến nghị sử dụng các biện pháp khác để phòng vệ trước tái nhập.

Điều này quan trọng vì chỉ dựa vào giới hạn gas có thể tạo cảm giác an toàn giả tạo.

Hợp đồng phải an toàn nhờ logic trạng thái chính xác, không phải vì giả định bên nhận sẽ không có đủ gas để thực hiện hành vi nguy hiểm.

Cách an toàn hơn là cập nhật trạng thái trước khi gọi bên ngoài, sử dụng reentrancy guard khi phù hợp, kiểm tra giá trị trả về và thiết kế cẩn thận quy trình rút tiền.

Nhà phát triển cũng nên rà soát mã cũ vẫn phụ thuộc vào transfer hoặc send như biện pháp bảo vệ chính trước tái nhập.

Thực tiễn bảo mật crypto thay đổi khi quy tắc giao thức, chi phí gas và kỹ thuật tấn công phổ biến phát triển.

Thanh toán theo yêu cầu để phòng vệ

Mẫu thanh toán theo yêu cầu cho phép người nhận tự rút tiền thay vì buộc hợp đồng chuyển tiền trong một thao tác khác.

Cách này giảm rủi ro vì hợp đồng có thể ghi nhận khoản tiền cần trả rồi để người nhận tự yêu cầu trong một bước riêng.

Ví dụ, marketplace có thể ghi nhận tiền bán hàng của người bán thay vì gửi tiền cho người bán ngay trong giao dịch mua của người mua.

Sau đó, người bán gọi hàm rút để nhận tiền.

Mẫu này có thể hạn chế thiệt hại do người nhận độc hại từ chối thanh toán hoặc cố gắng tái nhập trong lúc chi trả.

Tài liệu về các tiện ích bảo mật của OpenZeppelin mô tả PullPayment là mẫu có thể giúp ngăn chặn tấn công tái nhập.

Thanh toán theo yêu cầu không phù hợp hoàn toàn với mọi thiết kế vì có thể khiến người dùng phải thực hiện thêm thao tác.

Tuy nhiên, mẫu này có thể rất hữu ích khi nhiều người dùng hoặc hợp đồng cần nhận thanh toán từ cùng một hệ thống.

Biện pháp tạm dừng khẩn cấp

Biện pháp tạm dừng khẩn cấp cho phép tài khoản được ủy quyền hoặc hệ thống quản trị tạm dừng các hàm nhạy cảm khi xảy ra sự cố.

Biện pháp này có thể giúp hạn chế thiệt hại nếu phát hiện hành vi đáng ngờ hoặc nguy cơ khai thác tái nhập.

Hàm tạm dừng có thể ngăn việc rút, nạp, nhận thưởng, cấp khoản vay mới hoặc các thao tác rủi ro khác trong khi đội ngũ điều tra.

OpenZeppelin liệt kê Pausable là cơ chế ứng phó khẩn cấp phổ biến, có thể tạm dừng chức năng trong thời gian chờ khắc phục.

Cần thiết kế hệ thống tạm dừng cẩn thận vì hệ thống này tạo ra sự đánh đổi về quản trị và mức độ tập trung hóa.

Nếu quyền tạm dừng quá lớn, người dùng có thể lo ngại về kiểm duyệt hoặc lạm dụng quyền hạn.

Nếu quyền tạm dừng quá yếu hoặc phản ứng quá chậm, biện pháp này có thể không hữu ích trong một cuộc tấn công đang diễn ra.

Với giao thức crypto có giá trị lớn, kế hoạch ứng phó khẩn cấp nên là một phần trong thiết kế bảo mật ngay từ đầu.

Cách nhà phát triển phát hiện rủi ro tái nhập

Nhà phát triển có thể phát hiện rủi ro tái nhập bằng cách rà soát mọi lệnh gọi bên ngoài trong hợp đồng.

Lệnh gọi bên ngoài bao gồm chuyển coin gốc, chuyển token, lệnh gọi cấp thấp, lệnh gọi giao diện, callback flash loan, hook nhận NFT và lệnh gọi đến mô-đun giao thức.

Với mỗi lệnh gọi bên ngoài, nhà phát triển nên kiểm tra xem trạng thái nội bộ đã được cập nhật chưa.

Nhà phát triển cũng nên kiểm tra liệu có thể gọi hàm khác trong khi lệnh gọi bên ngoài diễn ra để đọc trạng thái cũ hay không.

Nhà phát triển nên xem xét liệu nhiều hợp đồng có dùng chung các giả định có thể bị phá vỡ bởi callback hay không.

Nhà phát triển nên kiểm thử bằng hợp đồng nhận độc hại, cố gắng gọi lại mọi hàm public và external.

Nhà phát triển nên kết hợp phân tích tĩnh, fuzz testing, kiểm thử đơn vị, kiểm thử bất biến và rà soát thủ công.

Tài liệu Solidity SMTChecker bao gồm các thuộc tính tái nhập như một dạng hành vi có thể phân tích quanh lệnh gọi bên ngoài đến mã không xác định.

Không có công cụ đơn lẻ nào có thể bảo đảm hợp đồng an toàn.

Việc phát hiện tái nhập hiệu quả nhất khi kết hợp công cụ tự động với hoạt động rà soát bảo mật của chuyên gia giàu kinh nghiệm.

Người dùng có thể đánh giá rủi ro tái nhập như thế nào?

Hầu hết người dùng không thể kiểm toán đầy đủ hợp đồng thông minh trước khi sử dụng.

Tuy nhiên, người dùng vẫn có thể giảm rủi ro bằng cách tìm các dấu hiệu cho thấy dự án áp dụng thực tiễn bảo mật chặt chẽ.

Giao thức nên cung cấp tài liệu rõ ràng về kiểm toán, chương trình thưởng phát hiện lỗi, biện pháp khẩn cấp, quyền nâng cấp và công bố rủi ro.

Người dùng nên cẩn trọng với các hợp đồng mới nắm giữ lượng tài sản lớn nhưng ít được rà soát công khai.

Người dùng cũng nên thận trọng khi giao thức đưa ra lợi suất cao bất thường mà không giải thích nguồn lợi nhuận và rủi ro hợp đồng thông minh.

Rủi ro tái nhập có thể tồn tại ngay cả khi giao diện người dùng trông chuyên nghiệp và được hoàn thiện tốt.

Giao diện đẹp không chứng minh logic của hợp đồng nền tảng an toàn.

Người dùng nên tránh nạp nhiều hơn số tiền họ có thể chấp nhận mất vào hợp đồng chưa được kiểm toán hoặc còn mang tính thử nghiệm.

Người dùng cũng cần hiểu rằng kiểm toán giúp giảm rủi ro nhưng không loại bỏ hoàn toàn rủi ro.

Tái nhập và khả năng kết hợp của DeFi

Khả năng kết hợp của DeFi nghĩa là các hợp đồng thông minh có thể kết nối với nhau như những khối cấu thành tài chính.

Đây là một trong những tính năng mạnh mẽ nhất của crypto vì cho phép ví, vault, thị trường cho vay, hoạt động hoán đổi, sản phẩm phái sinh, hệ thống staking và công cụ quản trị tương tác với nhau.

Tuy nhiên, khả năng kết hợp cũng làm tăng rủi ro tái nhập vì một giao dịch có thể đi qua nhiều hợp đồng.

Một thao tác có vẻ an toàn trong một hợp đồng có thể kích hoạt hành vi phức tạp ở hợp đồng khác.

Callback có thể đi đến hợp đồng thứ ba, làm thay đổi một giá trị mà hợp đồng đầu tiên phụ thuộc vào.

Giá, giá trị cổ phần hoặc số dư có thể được đọc trong một trạng thái tạm thời vốn không được thiết kế để bên ngoài quan sát.

Đây là lý do việc phân tích tái nhập hiện đại cần bao quát toàn bộ đường dẫn tương tác.

Nhà phát triển không nên rà soát từng hợp đồng như thể hợp đồng đó hoạt động độc lập.

Nhà phát triển nên xem xét cách các hợp đồng hoạt động khi kết hợp với router, token, vault, flash loan và chiến lược bên ngoài.

Tái nhập và flash loan

Flash loan có thể khiến tấn công tái nhập nguy hiểm hơn vì cho phép kẻ tấn công tiếp cận lượng thanh khoản tạm thời lớn trong một giao dịch.

Bản thân flash loan không phải là một cuộc tấn công tái nhập.

Đây là công cụ có thể được sử dụng cho arbitrage hợp pháp, tái cấp vốn, thanh lý và các hoạt động sử dụng vốn hiệu quả.

Tuy nhiên, nếu hợp đồng dễ bị tấn công có thể bị thao túng trong một giao dịch, flash loan có thể cung cấp đủ vốn để kẻ tấn công thu lợi từ việc khai thác.

Callback flash loan cũng cần được thiết kế cẩn thận vì hệ thống dựa trên callback chủ động trao quyền kiểm soát cho hợp đồng khác.

Nhà phát triển nên xem mọi callback là lệnh gọi bên ngoài không đáng tin cậy, trừ khi có lý do thuyết phục để làm khác.

Khi có thể, nhà phát triển nên cập nhật trạng thái trước callback và xác minh khoản hoàn trả cuối cùng, số dư và các bất biến sau khi callback trả về.

Tích hợp flash loan nên được kiểm thử với hợp đồng bên vay độc hại, không chỉ với các trường hợp vay thông thường.

Tái nhập và hợp đồng có thể nâng cấp

Hợp đồng có thể nâng cấp cần được chú ý đặc biệt khi sử dụng biện pháp bảo vệ chống tái nhập.

Proxy có thể nâng cấp tách biệt bộ nhớ mà người dùng tương tác với logic triển khai.

Nếu reentrancy guard sử dụng bộ nhớ, nhà phát triển phải bảo đảm bố cục bộ nhớ chính xác và tương thích qua các lần nâng cấp.

Thay đổi sai bố cục bộ nhớ có thể làm hỏng guard hoặc biến đổi các biến trạng thái quan trọng.

Nhà phát triển nên sử dụng thư viện tương thích với hợp đồng có thể nâng cấp.

Nhà phát triển cũng nên kiểm thử các lần nâng cấp dựa trên trạng thái hợp đồng trước đó thay vì chỉ kiểm thử lần triển khai mới.

Hợp đồng có thể an toàn ở phiên bản đầu nhưng trở nên dễ bị tấn công sau khi nâng cấp làm thay đổi thứ tự gọi hoặc bổ sung tích hợp bên ngoài mới.

Hoạt động rà soát nâng cấp cần bao gồm phân tích tái nhập đối với mọi lệnh gọi bên ngoài mới.

Hệ thống quản trị hoặc quản trị viên thực hiện nâng cấp cũng nên có độ trễ, quy trình rà soát và biện pháp khẩn cấp khi giao thức nắm giữ giá trị đáng kể.

Thông lệ tốt nhất để ngăn chặn tấn công tái nhập

Cập nhật trạng thái nội bộ trước khi thực hiện lệnh gọi bên ngoài.

Áp dụng mẫu Checks-Effects-Interactions cho các thao tác rút, nhận thưởng, chuyển, hoán đổi và thay đổi kế toán.

Áp dụng reentrancy guard cho các điểm truy cập bên ngoài có rủi ro cao.

Không cho rằng chuyển token luôn là thao tác đơn giản vì một số tiêu chuẩn và cách triển khai token có thể kích hoạt hook hoặc callback.

Không chỉ dựa vào giới hạn gas của transfer hoặc send để phòng vệ trước tái nhập.

Sử dụng mẫu thanh toán theo yêu cầu khi việc thanh toán trực tiếp tạo ra rủi ro không cần thiết.

Rà soát tái nhập chéo hàm và chéo hợp đồng, không chỉ tái nhập cổ điển trong cùng một hàm.

Kiểm thử bằng hợp đồng nhận độc hại cố gắng tái nhập trong mỗi lệnh gọi bên ngoài.

Sử dụng kiểm thử bất biến để xác nhận tổng số dư, cổ phần, khoản nợ và dự trữ luôn chính xác trong các tương tác phức tạp.

Đưa biện pháp tạm dừng khẩn cấp và kế hoạch ứng phó sự cố vào các hệ thống có giá trị lớn.

Rà soát bảo mật độc lập trước khi triển khai hợp đồng nắm giữ tiền của người dùng.

Cập nhật các thành phần phụ thuộc và kiểm tra ghi chú chuyển đổi thư viện trước khi thay đổi phiên bản lớn.

Các sai lầm thường gặp của nhà phát triển

Một sai lầm thường gặp là cập nhật số dư sau khi gửi tiền.

Một sai lầm khác là chỉ bảo vệ hàm rút trong khi để các hàm liên quan có nguy cơ bị tái nhập chéo hàm.

Một sai lầm khác là cho rằng chuyển token không thể thực thi mã bên ngoài.

Một sai lầm khác là dùng reentrancy guard ở một hợp đồng nhưng bỏ qua lệnh gọi đến các hợp đồng liên quan có chung giả định kế toán.

Một sai lầm khác là dựa vào các giả định cũ về transfer và send thay vì thiết kế logic trạng thái chính xác.

Một sai lầm khác là bổ sung tích hợp bên ngoài mới trong quá trình nâng cấp mà không kiểm tra lại toàn bộ đường dẫn gọi.

Một sai lầm khác là cho rằng hàm view vô hại, ngay cả khi hợp đồng khác dựa vào giá trị của hàm trong các giao dịch phức tạp.

Một sai lầm khác là quên rằng hợp đồng độc hại có thể chủ động hoạt động khác với người dùng thông thường.

Kiểm thử bảo mật cần giả định có hành vi thù địch, không chỉ cách sử dụng giao diện bình thường.

Câu hỏi thường gặp

Tấn công tái nhập nghĩa là gì?

Tấn công tái nhập là khi hợp đồng độc hại gọi ngược vào hợp đồng thông minh dễ bị tấn công trước khi lệnh gọi hàm đầu tiên hoàn tất và trước khi trạng thái được cập nhật an toàn.

Vì sao tái nhập nguy hiểm trong crypto?

Tái nhập nguy hiểm vì có thể cho phép kẻ tấn công rút cạn tiền, nhận phần thưởng nhiều lần, thao túng kế toán hoặc phá vỡ giả định của hợp đồng chỉ trong một giao dịch.

Tái nhập chỉ liên quan đến giao dịch chuyển ETH phải không?

Không. Tài liệu Solidity cảnh báo rằng tái nhập không chỉ liên quan đến việc chuyển Ether vì mọi lệnh gọi hợp đồng bên ngoài đều có thể tạo ra rủi ro callback.

Biện pháp phòng vệ nổi tiếng nhất trước tái nhập là gì?

Mẫu Checks-Effects-Interactions là một trong những biện pháp phòng vệ nổi tiếng nhất vì cập nhật trạng thái hợp đồng trước khi thực hiện lệnh gọi bên ngoài.

ReentrancyGuard là gì?

ReentrancyGuard là tiện ích hợp đồng thông minh cung cấp modifier nonReentrant để ngăn các lệnh gọi lồng nhau vào những hàm được bảo vệ.

ReentrancyGuard có ngăn chặn mọi lỗi tái nhập không?

Không. ReentrancyGuard giúp bảo vệ một số điểm truy cập, nhưng nhà phát triển vẫn cần hạch toán chính xác, sắp xếp lệnh gọi an toàn và rà soát tương tác giữa các hợp đồng.

Tái nhập chéo hàm là gì?

Tái nhập chéo hàm xảy ra khi kẻ tấn công gọi lại một hàm khác trong cùng hợp đồng trong lúc hàm đầu tiên chưa hoàn tất.

Tái nhập chỉ đọc là gì?

Tái nhập chỉ đọc xảy ra khi hàm view trả về trạng thái tạm thời gây hiểu lầm trong lúc thao tác chưa hoàn tất và hợp đồng khác dựa vào giá trị đó.

Chuyển token có thể gây tái nhập không?

Có. Một số tiêu chuẩn và cách triển khai token có thể kích hoạt hook hoặc callback, vì vậy cần rà soát việc chuyển token như một lệnh gọi bên ngoài tiềm ẩn.

Người dùng có nên tránh mọi hợp đồng thông minh vì nguy cơ tái nhập không?

Không. Người dùng không cần tránh mọi hợp đồng thông minh nhưng nên ưu tiên giao thức có kiểm toán chặt chẽ, tài liệu rõ ràng, giám sát chủ động và biện pháp kiểm soát rủi ro có trách nhiệm.

Kết luận

Tấn công tái nhập là hình thức khai thác hợp đồng thông minh lợi dụng trạng thái chưa hoàn tất trong khi lệnh gọi bên ngoài đang diễn ra.

Kẻ tấn công gọi lại hợp đồng dễ bị tấn công trước khi lệnh gọi đầu tiên hoàn tất và lợi dụng dữ liệu kế toán cũ để chiếm đoạt giá trị vượt mức cho phép.

Dù ví dụ cổ điển là lặp lại lệnh rút, tái nhập hiện đại còn có thể liên quan đến lệnh gọi chéo hàm, luồng chéo hợp đồng, trạng thái chỉ đọc, hook token, callback flash loan và khả năng kết hợp của DeFi.

Bài học chính là cần xem mọi lệnh gọi bên ngoài như một khả năng trao quyền kiểm soát cho mã không đáng tin cậy.

Nhà phát triển có thể giảm rủi ro tái nhập bằng cách áp dụng Checks-Effects-Interactions, dùng reentrancy guard, tránh các phương thức thanh toán không an toàn, kiểm thử callback độc hại và rà soát toàn bộ đường dẫn tương tác giữa các hợp đồng.

Người dùng có thể giảm mức độ tiếp xúc với rủi ro bằng cách chọn giao thức coi trọng bảo mật hợp đồng thông minh và tránh các hệ thống chưa được kiểm toán nhưng nắm giữ giá trị đáng kể.

Tái nhập vẫn là một khái niệm bảo mật quan trọng trong crypto vì một lỗi nhỏ về thứ tự logic có thể trở thành vụ khai thác tài chính nghiêm trọng.

Hiểu về tái nhập giúp nhà phát triển xây dựng hợp đồng an toàn hơn và giúp người dùng hiểu vì sao kiểm toán hợp đồng thông minh, mẫu bảo mật và biện pháp kiểm soát rủi ro lại quan trọng.