Saya hanya ingin berbagi masalah keamanan smart contract yang sering diabaikan oleh banyak pengembang — yaitu serangan reentrancy. Jika Anda sedang membangun kontrak pintar menggunakan Solidity, ini adalah hal yang harus Anda pahami dengan baik.

Sederhananya, reentrancy terjadi ketika sebuah kontrak memanggil kontrak lain, dan kontrak tersebut dapat memanggil kembali kontrak awal saat proses masih berlangsung. Bayangkan Anda memiliki ContractA yang menyimpan 10 Ether dan ContractB mengirimkan 1 Ether ke sana. Ketika ContractB menarik uang, ContractA akan memeriksa apakah saldo lebih besar dari 0, dan jika ya, mengirim Ether kembali. Namun, jika ContractB memiliki fungsi fallback(fungsi cadangan), ia dapat memanggil kembali fungsi penarikan dari ContractA saat fungsi tersebut belum selesai dieksekusi. Hasilnya? saldo ContractB tetap tercatat sebagai 1 Ether, sehingga ia akan menerima 1 Ether lagi, dan proses ini bisa berulang sampai ContractA kehabisan dana.

Bagaimana cara kerja serangan ini? Penyerang membutuhkan dua hal: fungsi attack() untuk memulai, dan fungsi fallback untuk memanggil kembali fungsi withdraw. Fungsi fallback adalah fungsi khusus di luar yang tidak memiliki nama, tidak memiliki parameter, dan siapa saja bisa mengaktifkannya dengan memanggil fungsi yang tidak ada, tanpa mengirim data, atau mengirim Ether tanpa data.

Contoh konkretnya: kontrak EtherStore memiliki fungsi deposit() yang menyimpan saldo dan fungsi withdrawAll() yang menarik seluruh dana. Masalahnya, withdrawAll() memeriksa saldo, mengirim Ether, lalu baru memperbarui saldo menjadi 0. Ini menciptakan celah untuk serangan reentrancy.

Lalu, bagaimana melindunginya? Saya akan jelaskan tiga cara.

Pertama, gunakan modifier noReentrant. Ide dasarnya sangat sederhana: mengunci kontrak saat fungsi sedang dieksekusi. Jika ada yang mencoba memanggil kembali fungsi tersebut, mereka harus melewati pemeriksaan kunci terlebih dahulu, tetapi kunci akan dibuka setelah fungsi selesai. Modifier adalah semacam fungsi khusus yang memungkinkan Anda menambahkan kondisi ke fungsi lain tanpa menulis ulang seluruh logika.

Kedua, terapkan pola Check-Effect-Interaction. Alih-alih memeriksa kondisi, mengirim dana, lalu memperbarui saldo, Anda harus memeriksa terlebih dahulu, memperbarui saldo secara langsung(sebelum mengirim dana), lalu melakukan interaksi dengan pihak luar. Dengan cara ini, bahkan jika reentrancy terjadi, saldo sudah diperbarui menjadi 0, sehingga penyerang tidak bisa menarik lebih banyak lagi.

Ketiga, jika proyek Anda melibatkan banyak kontrak yang berinteraksi, gunakan GlobalReentrancyGuard. Alih-alih hanya mengunci satu fungsi, Anda mengunci seluruh sistem dengan sebuah variabel status yang disimpan di kontrak terpisah. Ketika salah satu fungsi di salah satu kontrak dipanggil, sistem akan memeriksa apakah sedang terkunci. Jika ya, transaksi akan ditolak. Ini sangat berguna jika Anda memiliki kontrak seperti ScheduledTransfer yang mengirim dana ke AttackTransfer — GlobalReentrancyGuard akan mencegah seluruh rangkaian serangan reentrancy terjadi.

Keunggulan dari ketiga metode ini adalah Anda bisa menggabungkannya sesuai situasi. Fungsi penting? Gunakan noReentrant. Banyak fungsi terkait? Terapkan Check-Effect-Interaction. Proyek yang kompleks? Gunakan GlobalReentrancyGuard. Memahami reentrancy dan cara melindunginya akan membantu Anda membangun kontrak pintar yang lebih aman.