Các cuộc tấn công tái nhập trong Hợp đồng thông minh: Hướng dẫn phòng ngừa toàn diện

Các cuộc tấn công tái nhập đại diện cho một trong những lỗ hổng nghiêm trọng nhất trong bảo mật hợp đồng thông minh. Bài viết này cung cấp một phân tích kỹ thuật chi tiết về các cuộc tấn công tái nhập, trình bày cơ chế của chúng thông qua các ví dụ mã và trình bày ba kỹ thuật phòng ngừa đã được kiểm chứng qua thực tế để bảo vệ hợp đồng thông minh của bạn.

Hiểu về Reentrancy: Khái niệm cơ bản

Về bản chất, một cuộc tấn công tái nhập xảy ra khi một hợp đồng (ContractB) gọi lại vào hợp đồng gọi (ContractA) trước khi việc gọi hàm đầu tiên hoàn tất. Lỗ hổng này tạo ra một vòng lặp đệ quy của các cuộc gọi hàm có thể bị khai thác để rút tiền hoặc thao túng trạng thái hợp đồng.

Thông tin chính: Lỗ hổng tái nhập tồn tại khi một hợp đồng thực hiện các cuộc gọi bên ngoài trước khi cập nhật trạng thái nội bộ của nó.

Hãy xem xét kịch bản này:

• ContractA có 10 ETH trong số dư
• ContractB đã gửi 1 ETH vào ContractA
• ContractA có một hàm rút tiền dễ bị tổn thương

Khi ContractB khai thác lỗ hổng này, nó có thể thực hiện một loạt các cuộc gọi đệ quy để rút cạn quỹ của ContractA trước khi bất kỳ cập nhật số dư nào xảy ra.

Giải phẫu của một cuộc tấn công tái nhập

Mô hình tấn công thường bao gồm hai thành phần thiết yếu:

1. Một chức năng tấn công() khởi xướng khai thác
2. Một chức năng fallback() được thực hiện khi nhận ETH, tạo ra vòng lặp đệ quy

Cuộc tấn công thực hiện theo trình tự sau:

1. Kẻ tấn công gọi attack() trong hợp đồng độc hại của họ
2. Hợp đồng độc hại gọi withdraw() trong hợp đồng dễ bị tổn thương
3. Hợp đồng dễ bị tổn thương gửi ETH cho kẻ tấn công, kích hoạt hàm fallback
4. Trong hàm fallback, kẻ tấn công gọi lại withdraw() một cách đệ quy.
5. Chu trình này lặp lại cho đến khi hợp đồng dễ bị tổn thương bị rút cạn tiền.

Ý nghĩa lịch sử: Cuộc tấn công DAO nổi tiếng vào năm 2016, dẫn đến việc mất khoảng $60 triệu worth of ETH, là một cuộc tấn công tái nhập nổi bật đã dẫn đến việc phân tách Ethereum.

Phân tích mã dễ bị tổn thương

Hãy xem xét một triển khai hợp đồng dễ bị tổn thương:

solidity hợp đồng EtherStore { mapping(address => uint) public balances;

function deposit() public payable {
    balances[msg.sender] += msg.value;
}

function withdrawAll() public {
    uint bal = balances[msg.sender];
    require(bal > 0);
    
    (bool sent, ) = msg.sender.call{value: bal}("");
    require(gửi, "Gửi Ether không thành công");
    
    balances[msg.sender] = 0;
}

}

Lỗ hổng nghiêm trọng trong mã này là hợp đồng gửi ETH (msg.sender.call{value: bal}("")) trước khi cập nhật số dư của người gửi (balances[msg.sender] = 0). Chuỗi lệnh này tạo ra lỗ hổng reentrancy.

Khai thác lỗ hổng

Một kẻ tấn công sẽ triển khai một hợp đồng như thế này để khai thác EtherStore dễ bị tổn thương:

solidity hợp đồng Attack { EtherStore công khai etherStore;

constructor(địa chỉ _etherStoreAddress) {
    etherStore = EtherStore(_etherStoreAddress);
}

// Hàm dự phòng - được gọi khi EtherStore gửi Ether
fallback() bên ngoài có thể trả {
    nếu (địa chỉ(etherStore).số dư >= 1 ether) {
        etherStore.withdrawAll();
    }
}

function attack() external payable {
    require(msg.value >= 1 ether);
    etherStore.deposit{value: 1 ether}();
    etherStore.rútTấtCả();
}

}

Luồng tấn công:

1. Kẻ tấn công gọi attack(), gửi 1 ETH
2. Kẻ tấn công gọi withdrawAll() trên EtherStore
3. EtherStore gửi 1 ETH trở lại, kích hoạt chức năng fallback
4. Trong hàm fallback, kẻ tấn công gọi đệ quy withdrawAll() một lần nữa
5. Vì số dư chưa được cập nhật, chu kỳ này tiếp tục cho đến khi EtherStore bị cạn kiệt.

Ba kỹ thuật phòng thủ chống lại reentrancy

1. Bảo vệ Cấp Chức năng: Bộ sửa đổi noReentrant

Bộ sửa đổi này tạo ra một cơ chế khóa ngăn chặn một hàm được gọi lại khi nó vẫn đang thực thi:

solidity hợp đồng ReentrancyGuard { bool private locked = false;

modifier noReentrant() {
    require(!locked, "Reentrant call");
    locked = true;
    _;
    locked = false;
}

}

hợp đồng SecureEtherStore là ReentrancyGuard { mapping(address => uint) public balances;

function withdrawAll() public noReentrant {
    uint bal = balances[msg.sender];
    require(bal > 0);
    
    (bool sent, ) = msg.sender.call{value: bal}("");
    require(gửi, "Gửi Ether thất bại");
    
    balances[msg.sender] = 0;
}

}

Phân tích kỹ thuật: Bộ sửa đổi thiết lập một biến trạng thái (locked) để ngăn chặn việc tái nhập. Nếu một hàm với bộ sửa đổi này được gọi khi đã đang thực thi, giao dịch sẽ bị hoàn lại.

2. Bảo vệ Chéo Chức Năng: Mô Hình Kiểm Tra-Hiệu Ứng-Interaksi

Mẫu này giải quyết vấn đề gọi lại giữa các chức năng bằng cách đảm bảo rằng các thay đổi trạng thái xảy ra trước khi tương tác bên ngoài:

solidity // CÓ THỂ BỊ TỔN THƯƠNG function withdrawAll() công cộng { uint bal = balances[msg.sender]; require(bal > 0);

(bool sent, ) = msg.sender.call{value: bal}("");
require(gửi, "Gửi Ether không thành công");

balances[msg.sender] = 0; // Trạng thái được cập nhật SAU cuộc gọi bên ngoài

}

// AN TOÀN function withdrawAll() public { uint bal = balances[msg.sender]; require(bal > 0);

balances[msg.sender] = 0; // Trạng thái được cập nhật TRƯỚC khi gọi bên ngoài

(bool sent, ) = msg.sender.call{value: bal}("");
require(sent, "Gửi Ether không thành công");

}

Phân tích kỹ thuật: Bằng cách cập nhật các biến trạng thái trước khi thực hiện các cuộc gọi bên ngoài, hợp đồng đảm bảo rằng ngay cả khi cuộc gọi bên ngoài cho phép tái nhập, trạng thái đã được sửa đổi đúng cách, ngăn chặn việc khai thác.

3. Bảo vệ Chéo Hợp đồng: GlobalReentrancyGuard

Đối với các dự án có nhiều hợp đồng tương tác, việc triển khai một bộ bảo vệ tái nhập toàn cầu cung cấp sự bảo vệ trên toàn hệ thống:

solidity hợp đồng GlobalReentrancyGuard { bool private _notEntered;

constructor() {
    _notEntered = true;
}

modifier globalNonReentrant() {
    require(_notEntered, "ReentrancyGuard: reentrant call");
    _notEntered = false;
    _;
    _notEntered = true;
}

}

hợp đồng ContractA là GlobalReentrancyGuard { function transferFunds() public globalNonReentrant { // Triển khai an toàn } }

hợp đồng ContractB là GlobalReentrancyGuard { function withdrawFunds() public globalNonReentrant { // Triển khai an toàn } }

Phân tích kỹ thuật: Cách tiếp cận này sử dụng trạng thái hợp đồng chia sẻ để ngăn chặn việc gọi lại giữa nhiều hợp đồng trong cùng một hệ sinh thái, cung cấp sự bảo vệ ở cấp độ hệ thống thay vì chỉ ở cấp độ hàm.

Ma trận triển khai các thực tiễn tốt nhất về bảo mật

| Kỹ Thuật Ngăn Ngừa | Mức Độ Bảo Vệ | Chi Phí Gas | Độ Phức Tạp Triển Khai | Tốt Nhất Cho | |----------------------|------------------|----------|---------------------------|----------| | noReentrant Modifier | Cấp độ hàm | Thấp-Trung bình | Đơn giản | Các hàm dễ bị tổn thương đơn lẻ | | Kiểm tra-Tác động-Phản hồi | Cấp độ hợp đồng | Thấp | Trung bình | Bảo mật hợp đồng chung | | GlobalReentrancyGuard | Cấp hệ thống | Trung bình | Phức tạp | Hệ thống đa hợp đồng |

Các yếu tố cần xem xét trong việc triển khai kỹ thuật

Khi triển khai bảo vệ reentrancy, các nhà phát triển nên xem xét:

1. Tối ưu hóa gas: Bảo vệ tái nhập thêm chi phí vào việc thực thi hàm. Cân nhắc tác động đến hiệu suất trong các hoạt động tần suất cao.

2. Trường hợp đặc biệt: Một số trường hợp sử dụng hợp pháp yêu cầu hành vi tái nhập. Đảm bảo rằng các cơ chế bảo vệ của bạn không phá vỡ chức năng dự kiến.

3. Yêu cầu kiểm toán: Ngay cả khi có các cơ chế bảo vệ, các cuộc kiểm toán an ninh chuyên nghiệp vẫn rất cần thiết để phát hiện những lỗ hổng phức tạp hơn.

4. Phạm vi bảo vệ: Các cơ chế bảo vệ tái nhập khác nhau giải quyết các vector tấn công khác nhau. Hiểu rõ các lỗ hổng cụ thể của hợp đồng của bạn là điều cần thiết để chọn lựa biện pháp bảo vệ phù hợp.

Bằng cách hiểu cơ chế của các cuộc tấn công tái nhập và triển khai các cơ chế bảo vệ thích hợp, các nhà phát triển có thể nâng cao đáng kể tính bảo mật của các hợp đồng thông minh của họ chống lại một trong những lỗ hổng phổ biến và nguy hiểm nhất trong hệ sinh thái blockchain.