Hướng Dẫn Kiểm Toán Hợp Đồng Thông Minh: Những Bước Cơ Bản và Bài Học Quan Trọng

Kiểm toán hợp đồng thông minh đang trở thành một phần thiết yếu trong việc đảm bảo an toàn cho các ứng dụng blockchain. Bài viết này dựa trên khóa học an toàn hợp đồng thông minh của Updraft và kho mã PasswordStore trên GitHub để chia sẻ quy trình kiểm toán, đồng thời nêu bật một số sai lầm phổ biến mà nhà phát triển thường gặp.

Bước 1: Xác Định Ranh Giới Tin Cậy (Trust Boundaries)

Để kiểm toán hiệu quả, trước hết bạn cần trả lời các câu hỏi:

• Ai có thể ghi dữ liệu vào hợp đồng?
• Ai có thể đọc dữ liệu đó?
• Constructor giả định điều gì khi khởi tạo hợp đồng?
• Hợp đồng che giấu điều gì?
• Điều gì xảy ra nếu dữ liệu được công khai?

Ví dụ, trong PasswordStore.sol, chủ sở hữu (owner) được gán trong constructor, và hàm setter kiểm tra msg.sender để đảm bảo chỉ chủ sở hữu mới được phép cập nhật mật khẩu:

function setPassword(string memory newPassword) external {
    if (msg.sender != s_owner) {
        revert PasswordStore__NotOwner();
    }
    s_password = newPassword;
}

Hàm này đã có cơ chế bảo vệ cơ bản, nhưng điều đó chưa đủ để đảm bảo an toàn toàn diện.

Bước 2: Phân Tích Kho Mã và Phát Hiện Lỗ Hổng

Kho mã PasswordStore chỉ xoay quanh vài chục dòng code nhưng vẫn lộ hai vấn đề nghiêm trọng:

1. Thiếu kiểm soát truy cập (Access Control) ở hàm getPassword. Bất kỳ ai cũng có thể gọi hàm lấy mật khẩu mà không bị giới hạn.

2. Mật khẩu bị lộ trực tiếp trong bộ nhớ blockchain. Biến private trong Solidity chỉ ngăn truy cập qua ABI từ hợp đồng khác, chứ không ngăn được việc đọc trực tiếp dữ liệu trong blockchain. Ví dụ biến s_password ở slot lưu trữ số 1 có thể được lấy bằng lệnh Foundry:

cast parse-bytes32-string $(cast storage <CONTRACT_ADDRESS> 1)

Điều này cho thấy việc dữ liệu bảo mật được lưu trong hợp đồng blockchain không hề bí mật về mặt kỹ thuật — vì blockchain được thiết kế minh bạch mọi giao dịch và trạng thái.

Bước 3: Quy Trình Kiểm Toán Đơn Giản Nhưng Hiệu Quả

Với các hợp đồng nhỏ (dưới 100 dòng mã nguồn), tác giả đề xuất 4 bước kiểm tra quan trọng:

1. Đọc kỹ code, xác định ranh giới tin cậy và mục tiêu của hợp đồng trước khi bắt đầu kiểm tra chi tiết.

2. Kiểm tra xem hàm nào được phép gọi bởi ai, đảm bảo các hàm nhạy cảm đều có cơ chế bảo vệ thích hợp với mọi điểm truy cập.

3. Kiểm tra dữ liệu trong bộ nhớ (storage hoặc calldata) xem có bị lộ ra ngoài không, vì biến private không đồng nghĩa dữ liệu được bảo mật trên blockchain.

4. Viết các test xác nhận các trường hợp lỗ hổng, ví dụ test kiểm tra mật khẩu có bị lộ qua truy cập trực tiếp bộ nhớ:

function test_anyone_can_read_password() public {
    vm.startPrank(owner);
    passwordStore.setPassword("supersecret");
    vm.stopPrank();

    bytes32 storedPassword = vm.load(
        address(passwordStore),
        bytes32(uint256(1))
    );

    assertEq(
        string(abi.encodePacked(storedPassword)),
        "supersecret"
    );
}

Nếu test này thành công, chứng tỏ hợp đồng vẫn có nguy cơ rò rỉ dữ liệu bất chấp lớp bảo vệ ở hàm getter.

Kết Luận: Đừng Đánh Giá Hợp Đồng Qua Số Lượng Hàm

Hợp đồng ít hàm không có nghĩa là đơn giản hoặc an toàn hơn. Câu hỏi quan trọng không phải là “Hàm đó có được bảo vệ không?” mà là:

"Hợp đồng có thực sự đáp ứng logic nghiệp vụ và giữ an toàn dữ liệu người dùng không?"

Đây là điểm cần lưu ý đặc biệt với các nhà phát triển hợp đồng thông minh, nhất là khi bảo mật blockchain ngày càng trở thành ưu tiên hàng đầu trước các rủi ro tấn công và mất mát tài sản số.

Bạn sẽ viết lại hợp đồng này thế nào để vừa đảm bảo kiểm soát truy cập, vừa bảo mật dữ liệu trên blockchain?

---