Serangan Reentrancy

Apa Itu Serangan Reentrancy di Kripto?

Serangan reentrancy adalah eksploitasi smart contract ketika sebuah kontrak eksternal memanggil kembali kontrak yang rentan sebelum pemanggilan fungsi pertama selesai.

Di sektor kripto, serangan ini biasanya menargetkan smart contract yang menyimpan dana, mencatat saldo, memproses penarikan, menghitung reward, mengelola bagian vault, atau berinteraksi dengan kontrak lain.

Masalah utamanya adalah kontrak yang rentan menyerahkan kendali kepada kontrak lain sebelum selesai memperbarui state internalnya sendiri.

Jika penyerang dapat masuk kembali ke kontrak saat proses tersebut belum selesai, penyerang mungkin dapat mengulangi tindakan yang seharusnya hanya boleh dilakukan satu kali.

Contoh umum adalah fungsi penarikan yang mengirim kripto kepada pengguna sebelum mengurangi saldo pengguna yang tercatat.

Jika penerimanya adalah kontrak berbahaya, kontrak tersebut dapat menggunakan logika fallback atau callback untuk memanggil fungsi penarikan lagi sebelum saldo diperbarui.

Hal ini dapat memungkinkan penyerang menarik lebih banyak dari jumlah yang berhak diterimanya.

Halaman OWASP Smart Contract Top 10 2026 tentang reentrancy mendefinisikan reentrancy sebagai situasi ketika sebuah kontrak melakukan pemanggilan eksternal dan kontrak yang dipanggil memanggil kembali kontrak awal sebelum state diperbarui sepenuhnya.

Reentrancy merupakan salah satu kerentanan smart contract paling terkenal karena secara langsung menyerang model kepercayaan akuntansi on-chain.

Serangan ini sangat berbahaya di keuangan terdesentralisasi karena smart contract sering mengelola pool likuiditas besar dan bergantung pada kontrak lain untuk swap, jaminan, reward, atau data harga.

Bagaimana Serangan Reentrancy Bekerja

Serangan reentrancy dimulai ketika smart contract yang rentan melakukan pemanggilan eksternal ke kontrak atau alamat lain.

Pemanggilan eksternal tersebut dapat mengirim mata uang kripto native, mentransfer token, memanggil hook, meminta callback, menjalankan strategi, atau berinteraksi dengan protokol lain.

Saat kontrak yang rentan melakukan pemanggilan itu, kontrak tersebut untuk sementara memberi kontrak penerima kesempatan menjalankan kodenya sendiri.

Jika kontrak penerima dikendalikan penyerang, penyerang dapat memanfaatkan kesempatan itu untuk memanggil kembali kontrak yang rentan.

Kontrak yang rentan mungkin masih memiliki nilai state lama karena belum memperbarui saldo, utang, bagian, indeks reward, atau penanda penguncian.

Penyerang dapat mengeksploitasi nilai lama tersebut untuk mengulangi penarikan, mengklaim reward dua kali, meminjam lebih dari batas yang diizinkan, atau memanipulasi perhitungan.

Serangan berlanjut sampai dana kontrak yang rentan habis, transaksi kehabisan gas, atau mekanisme perlindungan menghentikan pemanggilan berulang.

Dokumentasi Solidity tentang pemanggilan eksternal memperingatkan bahwa interaksi dengan kontrak lain menyerahkan kendali kepada kontrak tersebut dan kontrak yang dipanggil dapat memanggil kembali kontrak awal sebelum pemanggilan pertama selesai.

Peringatan ini menjadi dasar pertahanan terhadap reentrancy.

Setiap pemanggilan eksternal sebaiknya dianggap sebagai titik yang dapat membuat asumsi kontrak dilanggar.

Contoh Sederhana Reentrancy

Bayangkan sebuah kontrak pinjaman yang mencatat saldo deposit setiap pengguna.

Seorang pengguna melakukan deposit 10 ETH ke dalam kontrak.

Kontrak mencatat bahwa pengguna memiliki saldo 10 ETH.

Pengguna kemudian memanggil fungsi withdraw untuk menerima kembali 10 ETH tersebut.

Kontrak yang aman akan mengurangi saldo pengguna menjadi nol sebelum mengirim ETH.

Kontrak yang rentan mengirim ETH terlebih dahulu, lalu memperbarui saldo.

Jika pengguna tersebut sebenarnya adalah kontrak berbahaya, fungsi receive-nya dapat berjalan saat ETH dikirim.

Fungsi receive itu dapat langsung memanggil withdraw lagi saat kontrak yang rentan masih menganggap pengguna memiliki saldo 10 ETH.

Penarikan yang sama dapat terjadi berulang kali dalam satu transaksi.

Inilah alasan urutan logika smart contract sangat penting.

Dalam perangkat lunak tradisional, kesalahan kecil dalam urutan mungkin hanya menyebabkan kesalahan akuntansi biasa.

Dalam smart contract yang menyimpan aset kripto, kesalahan urutan yang sama dapat menjadi jalur langsung untuk mencuri aset.

Mengapa Serangan Reentrancy Berbahaya

Serangan reentrancy berbahaya karena smart contract sering mengendalikan aset yang sulit dipulihkan setelah terjadi eksploitasi.

Blockchain publik dirancang untuk menjalankan transaksi yang valid dan mempertahankan riwayatnya.

Jika transaksi berbahaya mengikuti aturan blockchain tetapi mengeksploitasi bug kontrak, kerusakan yang terjadi biasanya sulit dibatalkan.

Panduan keamanan smart contract Ethereum.org menjelaskan bahwa kode smart contract yang sudah diterapkan biasanya sulit diubah dan aset yang dicuri sulit dipulihkan karena sifat blockchain yang tidak dapat diubah.

Karena itu, pencegahan jauh lebih penting daripada perbaikan setelah kejadian.

Bug reentrancy dapat menguras pool likuiditas, vault, bridge, sistem staking, marketplace NFT, kontrak reward, dan protokol pinjaman.

Bug ini juga dapat merusak kepercayaan pengguna meskipun aset yang dicuri kemudian berhasil dipulihkan.

Di sektor kripto, risiko smart contract bukan hanya masalah developer.

Risiko ini dapat sekaligus menjadi masalah bagi pengguna, likuiditas, tata kelola, dan reputasi.

Reentrancy Klasik

Reentrancy klasik terjadi ketika penyerang masuk kembali ke fungsi yang sama dengan fungsi yang melakukan pemanggilan eksternal.

Contoh paling umum adalah fungsi withdraw yang rentan.

Fungsi tersebut memeriksa saldo pengguna, mengirim dana kepada pengguna, lalu baru memperbarui saldo.

Kontrak penyerang menerima dana dan memanggil fungsi withdraw yang sama lagi sebelum saldo dikurangi.

Hal ini menciptakan loop yang memungkinkan saldo tercatat yang sama digunakan berkali-kali.

Reentrancy klasik mudah dipahami, tetapi tetap berbahaya karena banyak developer masih menempatkan logika pemanggilan eksternal terlalu awal.

Serangan ini juga berbahaya karena akuntansi kontrak modern sering kali lebih kompleks daripada pemetaan deposit dan penarikan sederhana.

Fungsi yang rentan mungkin melibatkan bagian, posisi utang, pengali reward, aset vault, token likuiditas, atau pencatatan biaya.

Meskipun polanya berbeda dari contoh klasik, masalah inti yang sama mungkin tetap ada.

Reentrancy Lintas Fungsi

Reentrancy lintas fungsi terjadi ketika penyerang masuk kembali ke fungsi lain dalam kontrak yang sama.

Serangan ini lebih sulit diketahui daripada reentrancy klasik karena fungsi yang diserang mungkin tampak aman jika ditinjau secara terpisah.

Sebagai contoh, satu fungsi mungkin memulai penarikan dan melakukan pemanggilan eksternal.

Selama pemanggilan eksternal tersebut, penyerang dapat memanggil fungsi lain yang bergantung pada saldo, bagian, atau state izin yang sama.

Jika fungsi pertama belum selesai memperbarui state, fungsi kedua mungkin membaca informasi yang sudah kedaluwarsa.

Hal ini dapat memungkinkan penyerang mengklaim reward, mentransfer bagian, meminjam aset, atau mengubah posisi sebelum tindakan pertama selesai.

Reentrancy lintas fungsi menunjukkan mengapa developer harus mempertimbangkan invarian seluruh kontrak, bukan hanya melindungi satu fungsi withdraw yang jelas.

Invarian kontrak adalah aturan yang harus tetap benar sebelum dan sesudah setiap operasi yang valid.

Jika pemanggilan eksternal dapat melanggar invarian untuk sementara, fungsi lain dapat menjadi jalur serangan.

Reentrancy Lintas Kontrak

Reentrancy lintas kontrak terjadi ketika jalur callback melewati beberapa kontrak.

Hal ini dapat terjadi dalam sistem DeFi ketika vault, strategi, router, kontrak token, pembaca oracle, modul staking, dan distributor reward saling berinteraksi.

Sebuah vault dapat memanggil strategi.

Strategi dapat memanggil token atau protokol lain.

Kontrak yang dipanggil dapat memicu callback yang kembali menjangkau vault atau kontrak terkait yang menjadi dependensi vault.

State yang rentan mungkin berada di kontrak yang berbeda dari kontrak yang melakukan pemanggilan eksternal pertama.

Pertimbangan keamanan Solidity menyebutkan bahwa reentrancy tidak hanya disebabkan oleh transfer Ether dan situasi yang melibatkan banyak kontrak juga harus diperhitungkan.

Hal ini penting karena aplikasi kripto modern sangat composable.

Composability memungkinkan protokol terhubung dan dibangun di atas satu sama lain, tetapi juga menciptakan lebih banyak jalur bagi callback yang tidak terduga.

Reentrancy Read-Only

Reentrancy read-only terjadi ketika fungsi view atau fungsi baca menampilkan informasi yang menyesatkan selama transisi state belum selesai.

Sekilas, hal ini mungkin tampak tidak berbahaya karena fungsi view tidak mengubah state secara langsung.

Namun, kontrak lain dapat menggunakan fungsi view untuk menghitung harga, bagian, nilai jaminan, kurs, atau jumlah reward.

Jika callback terjadi saat sebuah kontrak berada dalam state peralihan, fungsi view mungkin mengembalikan nilai sementara yang seharusnya tidak dipercaya.

Penyerang dapat menggunakan nilai sementara itu di kontrak lain yang bergantung padanya.

Hal ini dapat memicu manipulasi seperti oracle atau kesalahan akuntansi tanpa menguras kontrak pertama secara langsung melalui fungsi penarikan biasa.

Reentrancy read-only mengingatkan bahwa keamanan bukan hanya soal apakah suatu fungsi menulis ke storage.

Keamanan juga berkaitan dengan kemampuan kontrak lain mengamati state yang belum lengkap dan mengambil keputusan keuangan berdasarkan state tersebut.

Reentrancy Berbasis Hook

Reentrancy berbasis hook terjadi ketika standar token atau antarmuka protokol sengaja memanggil logika penerima selama proses transfer atau operasi.

Beberapa standar token dan NFT menyertakan hook penerima agar kontrak dapat bereaksi saat menerima aset.

Sistem flash loan juga menggunakan callback agar peminjam dapat menggunakan likuiditas pinjaman dan melunasinya dalam transaksi yang sama.

Hook ini berguna, tetapi juga membuka peluang terjadinya callback.

Jika kontrak menganggap transfer token sebagai tindakan sederhana yang tidak menjalankan kode eksternal, asumsi tersebut mungkin keliru.

Transfer dapat memicu logika penerima, hook operator, atau perilaku kontrak lainnya, bergantung pada standar dan implementasi token.

Developer sebaiknya meninjau setiap interaksi token eksternal sebagai kemungkinan titik reentrancy.

Hal ini sangat penting bagi kontrak yang mendukung banyak token, banyak aset vault, atau banyak integrasi eksternal.

Target Umum Serangan Reentrancy

Fungsi penarikan merupakan target reentrancy yang paling umum karena sering mengirim dana keluar dari kontrak.

Fungsi deposit dan penarikan vault juga sering menjadi target karena memperbarui saldo bagian dan pencatatan aset.

Protokol pinjaman dapat menjadi target karena mencatat jaminan, utang, bunga, ambang likuidasi, dan saldo pinjaman.

Kontrak staking dapat menjadi target karena menghitung reward dari waktu ke waktu dan mungkin mentransfer token reward saat klaim.

Marketplace NFT dapat menjadi target karena pembelian dan pembayaran dapat memicu hook penerima token atau logika royalti eksternal.

Kontrak bridge dapat menjadi target karena mengelola pesan lintas blockchain, penguncian aset, dan logika pelepasan aset.

Kontrak eksekusi tata kelola dapat menjadi target karena memanggil kontrak eksternal saat menjalankan proposal.

Penerima dan penyedia flash loan dapat menjadi target karena desainnya bergantung pada callback.

Setiap smart contract yang mengirim nilai atau memanggil kode yang tidak tepercaya sebelum menyelesaikan pencatatan internalnya harus dianggap berpotensi menjadi target reentrancy.

Pola Checks-Effects-Interactions

Pola Checks-Effects-Interactions adalah salah satu pertahanan terpenting terhadap serangan reentrancy.

Checks berarti kontrak terlebih dahulu memastikan bahwa pengguna berhak melakukan tindakan tersebut.

Effects berarti kontrak memperbarui state internalnya sebelum melakukan pemanggilan eksternal.

Interactions berarti kontrak hanya melakukan pemanggilan eksternal setelah pemeriksaan dan pembaruan state selesai.

Untuk fungsi penarikan, kontrak sebaiknya memeriksa saldo pengguna, mengurangi saldo, lalu mengirim dana.

Dengan begitu, jika penerima mencoba masuk kembali, kontrak sudah mencerminkan saldo yang telah diperbarui.

Dokumentasi Solidity tentang Checks-Effects-Interactions menjelaskan bahwa pola ini merupakan cara umum untuk mencegah serangan reentrancy.

Pola ini sederhana, tetapi wajib diterapkan pada kontrak yang berinteraksi dengan kode eksternal yang tidak tepercaya.

Developer sebaiknya menjadikannya kebiasaan standar setiap kali suatu fungsi mengubah state dan memanggil kode di luar kontrak.

Reentrancy Guard

Reentrancy guard adalah pengunci yang mencegah fungsi yang dilindungi dimasuki kembali sebelum pemanggilan pertama selesai.

Dalam kontrak Solidity, mekanisme ini sering diterapkan dengan variabel status yang menandai bahwa fungsi sedang berjalan.

Jika pemanggilan reentrant mencoba memasuki jalur terlindungi yang sama, guard akan menolaknya.

Dokumentasi ReentrancyGuard OpenZeppelin Contracts 5.x menjelaskan bahwa ReentrancyGuard adalah modul yang menyediakan modifier nonReentrant untuk mencegah pemanggilan reentrant bertingkat.

Reentrancy guard berguna karena menambahkan lapisan perlindungan yang jelas pada fungsi berisiko tinggi.

Namun, guard bukan pengganti pencatatan yang benar.

Developer tetap sebaiknya menggunakan pola Checks-Effects-Interactions dan meninjau semua pemanggilan eksternal.

OpenZeppelin juga mencatat bahwa karena hanya ada satu guard nonReentrant, fungsi yang diberi penanda nonReentrant tidak dapat memanggil satu sama lain secara langsung.

Salah satu cara yang umum digunakan adalah menjadikan logika internal bersifat private, lalu menyediakan entry point eksternal terpisah yang dilindungi nonReentrant.

Transient Storage dan Pengunci Reentrancy

Transient storage adalah fitur EVM yang lebih baru dan dapat digunakan untuk nilai sementara yang hanya bertahan selama satu transaksi.

Fitur ini dapat berguna untuk pengunci reentrancy karena pengunci tidak selalu perlu disimpan secara permanen setelah pemanggilan selesai.

Dokumentasi OpenZeppelin ReentrancyGuardTransient menjelaskan varian ReentrancyGuard yang menggunakan transient storage untuk chain yang mendukung EIP-1153.

Dokumentasi transient storage Solidity menyebutkan bahwa penggunaan transient storage untuk pengunci reentrancy yang dihapus pada akhir call frame aman dilakukan.

Ini bukan berarti setiap kontrak harus otomatis menggunakan transient storage.

Developer harus memastikan bahwa chain yang dituju mendukung fitur yang diperlukan dan pengunci dihapus dengan benar.

Pengunci yang dikelola dengan buruk dapat mengganggu composability atau membuat kontrak sulit digunakan dalam transaksi kompleks.

Pilihan terbaik bergantung pada blockchain sasaran, versi compiler, versi library, pola upgrade, dan persyaratan audit.

Mengapa Transfer dan Send Bukan Perlindungan Menyeluruh

Panduan Solidity lama sering menganggap transfer yang membatasi gas sebagai mitigasi praktis untuk reentrancy.

Panduan modern lebih berhati-hati karena biaya gas dan perilaku EVM dapat berubah seiring waktu.

Dokumentasi Solidity tentang anggota address memperingatkan bahwa send dan transfer sudah tidak disarankan dan merekomendasikan cara lain untuk melindungi kontrak dari reentrancy.

Hal ini penting karena hanya mengandalkan gas stipend dapat menimbulkan rasa aman yang keliru.

Kontrak seharusnya aman karena logika state-nya benar, bukan karena mengasumsikan penerima tidak memiliki cukup gas untuk melakukan sesuatu yang berbahaya.

Pendekatan yang lebih aman adalah memperbarui state sebelum pemanggilan eksternal, menggunakan reentrancy guard jika sesuai, memeriksa nilai hasil pemanggilan, dan merancang alur penarikan dengan cermat.

Developer juga sebaiknya meninjau kode lama yang masih bergantung pada transfer atau send sebagai perlindungan utama terhadap reentrancy.

Praktik keamanan kripto berubah seiring perkembangan aturan protokol, biaya gas, dan teknik serangan yang umum digunakan.

Pull Payments sebagai Pertahanan

Pola pull payment memungkinkan penerima menarik dana sendiri alih-alih kontrak mengirim dana secara langsung selama operasi lain.

Pola ini mengurangi risiko karena kontrak dapat mencatat pembayaran yang menjadi hak penerima dan membiarkan penerima mengklaimnya dalam langkah terpisah.

Misalnya, marketplace dapat mencatat hasil penjualan untuk penjual alih-alih mengirim dana kepada penjual dalam transaksi pembelian oleh pembeli.

Penjual kemudian memanggil fungsi withdraw untuk mengklaim dana tersebut.

Pola ini dapat membatasi kerusakan yang ditimbulkan penerima berbahaya yang menolak pembayaran atau mencoba masuk kembali selama pembayaran.

Dokumentasi utilitas keamanan OpenZeppelin menjelaskan bahwa PullPayment merupakan pola yang dapat membantu menghindari serangan reentrancy.

Pull payment tidak selalu ideal untuk setiap desain karena dapat menambah langkah bagi pengguna.

Namun, pola ini dapat sangat berguna ketika banyak pengguna atau kontrak perlu menerima pembayaran dari sistem yang sama.

Kontrol Jeda Darurat

Kontrol jeda darurat memungkinkan akun berwenang atau sistem tata kelola menjeda fungsi sensitif selama terjadi insiden.

Kontrol ini dapat membantu membatasi kerusakan jika terdeteksi perilaku mencurigakan atau potensi eksploitasi reentrancy.

Fungsi jeda dapat menghentikan penarikan, deposit, klaim reward, pinjaman baru, atau tindakan berisiko lainnya selama tim melakukan penyelidikan.

OpenZeppelin mencantumkan Pausable sebagai mekanisme respons darurat umum yang dapat menjeda fungsi saat perbaikan sedang dilakukan.

Sistem jeda perlu dirancang dengan cermat karena menimbulkan kompromi terkait tata kelola dan sentralisasi.

Jika kewenangan untuk menjeda terlalu besar, pengguna mungkin khawatir tentang penyensoran atau penyalahgunaan.

Jika kewenangan tersebut terlalu terbatas atau lambat, kontrol ini mungkin tidak membantu saat eksploitasi sedang berlangsung.

Untuk protokol kripto bernilai tinggi, perencanaan respons darurat sebaiknya menjadi bagian dari desain keamanan sejak awal.

Cara Developer Mendeteksi Risiko Reentrancy

Developer dapat mendeteksi risiko reentrancy dengan meninjau setiap pemanggilan eksternal di dalam kontrak.

Pemanggilan eksternal mencakup transfer koin native, transfer token, low-level call, pemanggilan antarmuka, callback flash loan, hook penerima NFT, dan pemanggilan modul protokol.

Untuk setiap pemanggilan eksternal, developer sebaiknya memeriksa apakah state internal sudah diperbarui.

Developer juga sebaiknya memeriksa apakah fungsi lain dapat dipanggil selama pemanggilan eksternal dan membaca state yang sudah kedaluwarsa.

Developer sebaiknya meninjau apakah beberapa kontrak memiliki asumsi bersama yang dapat dilanggar oleh callback.

Developer sebaiknya menguji kontrak penerima berbahaya yang mencoba memanggil kembali setiap fungsi publik dan eksternal.

Developer sebaiknya menggunakan analisis statis, fuzz testing, unit testing, invariant testing, dan tinjauan manual secara bersamaan.

Dokumentasi Solidity SMTChecker mencakup properti reentrancy sebagai salah satu kategori perilaku yang dapat dianalisis pada pemanggilan eksternal ke kode yang tidak diketahui.

Tidak ada satu alat pun yang dapat menjamin bahwa suatu kontrak aman.

Deteksi reentrancy paling efektif jika alat otomatis dipadukan dengan tinjauan keamanan oleh tenaga berpengalaman.

Cara Pengguna Memahami Risiko Reentrancy

Kebanyakan pengguna tidak dapat mengaudit smart contract sepenuhnya sebelum menggunakannya.

Namun, pengguna tetap dapat mengurangi risiko dengan mencari tanda-tanda praktik keamanan yang kuat.

Protokol sebaiknya menyediakan dokumentasi yang jelas tentang audit, program bug bounty, kontrol darurat, izin upgrade, dan pengungkapan risiko.

Pengguna sebaiknya berhati-hati terhadap kontrak baru yang menyimpan nilai besar tetapi hanya sedikit ditinjau secara publik.

Pengguna juga sebaiknya berhati-hati jika protokol menawarkan imbal hasil yang luar biasa tinggi tanpa menjelaskan sumber return dan risiko smart contract.

Risiko reentrancy dapat tetap ada meskipun antarmuka pengguna terlihat rapi dan profesional.

Antarmuka yang baik bukan bukti bahwa logika kontrak yang mendasarinya aman.

Pengguna sebaiknya tidak melakukan deposit melebihi jumlah yang mampu mereka tanggung jika hilang ke kontrak yang belum diaudit atau masih eksperimental.

Pengguna juga perlu memahami bahwa audit dapat mengurangi risiko, tetapi tidak menghilangkannya sepenuhnya.

Reentrancy dan Composability DeFi

Composability DeFi berarti smart contract dapat saling terhubung seperti komponen keuangan.

Ini merupakan salah satu fitur kripto yang paling kuat karena memungkinkan wallet, vault, pasar pinjaman, swap, derivatif, sistem staking, dan alat tata kelola saling berinteraksi.

Namun, composability juga meningkatkan risiko reentrancy karena satu transaksi dapat melewati banyak kontrak.

Operasi yang tampak aman di satu kontrak dapat memicu perilaku kompleks di kontrak lain.

Callback dapat menjangkau kontrak ketiga yang mengubah nilai yang menjadi dependensi kontrak pertama.

Harga, nilai bagian, atau saldo dapat dibaca saat berada dalam state sementara yang tidak pernah dimaksudkan untuk diamati secara eksternal.

Karena itu, analisis reentrancy modern harus mencakup keseluruhan jalur interaksi.

Developer sebaiknya tidak meninjau setiap kontrak seolah-olah kontrak tersebut beroperasi sendiri.

Developer sebaiknya meninjau perilaku kontrak saat digabungkan dengan router, token, vault, flash loan, dan strategi eksternal.

Reentrancy dan Flash Loan

Flash loan dapat membuat serangan reentrancy lebih kuat karena memungkinkan penyerang mengakses likuiditas sementara dalam jumlah besar dalam satu transaksi.

Flash loan sendiri bukan serangan reentrancy.

Flash loan merupakan alat yang dapat digunakan untuk arbitrase yang sah, refinancing, likuidasi, dan operasi yang efisien dari sisi modal.

Namun, jika kontrak yang rentan dapat dimanipulasi dalam satu transaksi, flash loan mungkin memberi penyerang modal yang cukup agar eksploitasi tersebut menguntungkan.

Callback flash loan juga perlu dirancang dengan cermat karena sistem berbasis callback memang sengaja menyerahkan kendali kepada kontrak lain.

Developer sebaiknya menganggap setiap callback sebagai pemanggilan eksternal yang tidak tepercaya, kecuali ada alasan kuat untuk melakukan sebaliknya.

Jika memungkinkan, developer sebaiknya memperbarui state sebelum callback dan memverifikasi pelunasan akhir, saldo, serta invarian setelah callback selesai.

Integrasi flash loan sebaiknya diuji menggunakan kontrak peminjam berbahaya, bukan hanya contoh peminjam biasa.

Reentrancy dan Kontrak yang Dapat Di-upgrade

Kontrak yang dapat di-upgrade memerlukan perhatian khusus saat menggunakan perlindungan reentrancy.

Proxy yang dapat di-upgrade memisahkan storage yang digunakan pengguna dari logika implementasi.

Jika reentrancy guard menggunakan storage, developer harus memastikan tata letak storage benar dan kompatibel di berbagai upgrade.

Perubahan tata letak storage yang tidak tepat dapat merusak guard atau mengacaukan variabel state penting.

Developer sebaiknya menggunakan library yang kompatibel dengan upgrade saat membangun kontrak yang dapat di-upgrade.

Developer juga sebaiknya menguji upgrade terhadap state kontrak sebelumnya, bukan hanya menguji deployment baru.

Kontrak mungkin aman pada versi pertama, tetapi menjadi rentan setelah upgrade berikutnya mengubah urutan pemanggilan atau menambahkan integrasi eksternal baru.

Tinjauan upgrade sebaiknya mencakup analisis reentrancy untuk setiap pemanggilan eksternal yang baru.

Sistem tata kelola atau admin yang menjalankan upgrade juga sebaiknya memiliki penundaan, peninjauan, dan kontrol darurat ketika protokol menyimpan nilai yang signifikan.

Praktik Terbaik untuk Mencegah Serangan Reentrancy

Perbarui state internal sebelum melakukan pemanggilan eksternal.

Gunakan pola Checks-Effects-Interactions untuk penarikan, klaim, transfer, swap, dan perubahan akuntansi.

Terapkan reentrancy guard pada entry point eksternal berisiko tinggi.

Jangan berasumsi bahwa transfer token selalu sederhana karena beberapa standar dan implementasi token dapat memicu hook atau callback.

Jangan hanya mengandalkan batas gas transfer atau send sebagai pertahanan terhadap reentrancy.

Gunakan pola pull payment jika pembayaran langsung menimbulkan risiko yang tidak perlu.

Tinjau reentrancy lintas fungsi dan lintas kontrak, bukan hanya reentrancy klasik pada fungsi yang sama.

Uji menggunakan kontrak penerima berbahaya yang mencoba masuk kembali pada setiap pemanggilan eksternal.

Gunakan invariant testing untuk memastikan total saldo, bagian, utang, dan cadangan tetap benar dalam berbagai interaksi kompleks.

Sertakan jeda darurat dan rencana respons insiden untuk sistem bernilai tinggi.

Minta tinjauan keamanan independen sebelum men-deploy kontrak yang menyimpan dana pengguna.

Perbarui dependensi dan periksa catatan migrasi library sebelum mengganti versi utama.

Kesalahan Umum Developer

Salah satu kesalahan umum adalah memperbarui saldo setelah dana dikirim.

Kesalahan lainnya adalah hanya melindungi fungsi withdraw, sementara fungsi terkait tetap terbuka terhadap reentrancy lintas fungsi.

Kesalahan lainnya adalah berasumsi bahwa transfer token tidak dapat menjalankan kode eksternal.

Kesalahan lainnya adalah menggunakan reentrancy guard pada satu kontrak, tetapi mengabaikan pemanggilan ke kontrak terkait yang berbagi asumsi akuntansi.

Kesalahan lainnya adalah mengandalkan asumsi lama tentang transfer dan send, alih-alih merancang logika state dengan benar.

Kesalahan lainnya adalah menambahkan integrasi eksternal baru saat upgrade tanpa memeriksa ulang seluruh jalur pemanggilan.

Kesalahan lainnya adalah menganggap fungsi view tidak berbahaya meskipun kontrak lain bergantung pada nilainya selama transaksi kompleks.

Kesalahan lainnya adalah lupa bahwa kontrak berbahaya dapat sengaja berperilaku berbeda dari pengguna biasa.

Pengujian keamanan sebaiknya mengasumsikan adanya perilaku bermusuhan, bukan hanya penggunaan antarmuka secara normal.

FAQ

Apa arti serangan reentrancy?

Serangan reentrancy adalah ketika kontrak berbahaya memanggil kembali smart contract yang rentan sebelum pemanggilan fungsi pertama selesai dan sebelum state diperbarui dengan aman.

Mengapa reentrancy berbahaya di kripto?

Reentrancy berbahaya karena dapat memungkinkan penyerang menguras dana, mengklaim reward berkali-kali, memanipulasi pencatatan, atau merusak asumsi kontrak dalam satu transaksi.

Apakah reentrancy hanya terkait dengan transfer ETH?

Tidak. Dokumentasi Solidity memperingatkan bahwa reentrancy tidak hanya terkait dengan transfer Ether karena setiap pemanggilan kontrak eksternal dapat menimbulkan risiko callback.

Apa pertahanan paling dikenal terhadap reentrancy?

Pola Checks-Effects-Interactions merupakan salah satu pertahanan yang paling dikenal karena memperbarui state kontrak sebelum melakukan pemanggilan eksternal.

Apa itu ReentrancyGuard?

ReentrancyGuard adalah utilitas smart contract yang menyediakan modifier nonReentrant untuk mencegah pemanggilan bertingkat ke fungsi yang dilindungi.

Apakah ReentrancyGuard dapat mencegah setiap bug reentrancy?

Tidak. ReentrancyGuard membantu melindungi entry point tertentu, tetapi developer tetap perlu menerapkan pencatatan yang benar, urutan pemanggilan yang aman, dan tinjauan lintas kontrak.

Apa itu reentrancy lintas fungsi?

Reentrancy lintas fungsi terjadi ketika penyerang masuk kembali ke fungsi lain dalam kontrak yang sama saat fungsi pertama belum selesai.

Apa itu reentrancy read-only?

Reentrancy read-only terjadi ketika fungsi view mengembalikan state sementara yang menyesatkan selama suatu operasi belum selesai dan kontrak lain menggunakan nilai tersebut.

Apakah transfer token dapat menyebabkan reentrancy?

Ya. Beberapa standar dan implementasi token dapat memicu hook atau callback, sehingga transfer token sebaiknya ditinjau sebagai kemungkinan pemanggilan eksternal.

Apakah pengguna perlu menghindari semua smart contract karena risiko reentrancy?

Tidak. Pengguna tidak perlu menghindari semua smart contract, tetapi sebaiknya memilih protokol dengan audit yang kuat, dokumentasi yang jelas, pemantauan aktif, dan kontrol risiko yang bertanggung jawab.

Kesimpulan

Serangan reentrancy adalah eksploitasi smart contract yang memanfaatkan state yang belum selesai selama pemanggilan eksternal.

Penyerang masuk kembali ke kontrak yang rentan sebelum pemanggilan pertama selesai dan memanfaatkan pencatatan yang sudah kedaluwarsa untuk memperoleh nilai lebih besar dari yang diizinkan.

Meski contoh klasiknya adalah penarikan berulang, reentrancy modern juga dapat melibatkan pemanggilan lintas fungsi, alur lintas kontrak, state read-only, hook token, callback flash loan, dan composability DeFi.

Pelajaran utamanya adalah setiap pemanggilan eksternal harus dianggap sebagai kemungkinan penyerahan kendali kepada kode yang tidak tepercaya.

Developer dapat mengurangi risiko reentrancy dengan mengikuti pola Checks-Effects-Interactions, menggunakan reentrancy guard, menghindari pola pembayaran yang tidak aman, menguji callback berbahaya, dan meninjau seluruh jalur interaksi kontrak.

Pengguna dapat mengurangi paparan risiko dengan memilih protokol yang serius menangani keamanan smart contract dan menghindari sistem yang belum diaudit serta menyimpan nilai yang signifikan.

Reentrancy tetap menjadi konsep keamanan kripto yang penting karena kesalahan kecil dalam urutan logika dapat berubah menjadi eksploitasi keuangan yang serius.

Memahami reentrancy membantu developer membangun kontrak yang lebih aman dan membantu pengguna memahami pentingnya audit smart contract, pola keamanan, dan kontrol risiko.