Keamanan Umum dalam Keuangan Desentralisasi dan Tindakan Pencegahan

Baru-baru ini, seorang ahli keamanan membagikan pelajaran tentang keamanan DeFi kepada anggota komunitas. Ahli tersebut meninjau kejadian keamanan besar yang dialami industri Web3 selama lebih dari setahun terakhir, membahas penyebab terjadinya kejadian tersebut dan bagaimana cara menghindarinya, merangkum celah keamanan umum pada kontrak pintar serta langkah pencegahannya, dan memberikan beberapa saran keamanan untuk pengembang proyek dan pengguna biasa.

Jenis kerentanan DeFi yang umum antara lain pinjaman kilat, manipulasi harga, masalah izin fungsi, panggilan eksternal sembarang, masalah fungsi fallback, kerentanan logika bisnis, kebocoran kunci pribadi, dan serangan reentrancy. Artikel ini akan fokus pada tiga jenis yaitu pinjaman kilat, manipulasi harga, dan serangan reentrancy.

Pinjaman Kilat

Pinjaman kilat adalah inovasi dalam Keuangan Desentralisasi, tetapi sering disalahgunakan oleh peretas. Penyerang biasanya meminjam sejumlah besar dana melalui pinjaman kilat untuk memanipulasi harga atau menyerang logika bisnis. Pengembang perlu mempertimbangkan apakah fungsi kontrak akan mengalami anomali akibat dana besar atau apakah mungkin disalahgunakan untuk mendapatkan imbalan yang tidak sah.

Banyak proyek Keuangan Desentralisasi tampak memiliki keuntungan yang cukup tinggi, tetapi sebenarnya kualitas tim proyek bervariasi. Meskipun kode itu sendiri tidak memiliki kerentanan, secara logika masih mungkin ada masalah. Misalnya, beberapa proyek akan memberikan hadiah berdasarkan jumlah token yang dimiliki pada waktu tertentu, tetapi dimanfaatkan oleh penyerang dengan meminjam dalam jumlah besar untuk membeli token, sehingga saat hadiah diberikan, mereka mendapatkan sebagian besar hadiah.

Manipulasi Harga

Masalah manipulasi harga terkait erat dengan pinjaman kilat, terutama karena beberapa parameter dalam perhitungan harga dapat dikontrol oleh pengguna. Ada dua jenis masalah yang umum:

1. Menggunakan data pihak ketiga saat menghitung harga, tetapi cara penggunaannya tidak benar atau pemeriksaan hilang, menyebabkan harga dimanipulasi secara jahat.
2. Menggunakan jumlah token di beberapa alamat sebagai variabel perhitungan, di mana saldo token di alamat tersebut dapat ditambah atau dikurangi sementara.

Serangan Reentrancy

Salah satu risiko utama dalam memanggil kontrak eksternal adalah bahwa mereka dapat mengambil alih alur kontrol dan melakukan perubahan yang tidak terduga pada data. Contoh klasik dari serangan reentrancy adalah ketika operasi transfer dilakukan sebelum pembaruan saldo pengguna, yang memungkinkan penyerang untuk menarik saldo secara berulang kali.

Untuk menyelesaikan masalah reentrancy, perlu diperhatikan hal-hal berikut:

1. Tidak hanya perlu mencegah masalah reentrancy dari fungsi tunggal;
2. Ikuti pola Checks-Effects-Interactions dalam pengkodean;
3. Gunakan dekorator anti-reentrancy yang telah teruji oleh waktu.

Perlu dicatat bahwa di bidang ini sudah ada banyak praktik keamanan terbaik, sehingga tidak perlu menciptakan kembali roda. Menggunakan solusi yang telah teruji dan matang lebih aman daripada mengembangkan solusi baru sendiri.

Saran Keamanan untuk Pihak Proyek

1. Mengikuti praktik keamanan terbaik dalam pengembangan kontrak.
2. Mewujudkan fungsi kontrak yang dapat ditingkatkan dan dijeda.
3. Menggunakan mekanisme kunci waktu.
4. Meningkatkan investasi keamanan, membangun sistem keamanan yang lengkap.
5. Meningkatkan kesadaran keamanan di semua karyawan.
6. Mencegah kejahatan internal, sambil meningkatkan efisiensi dan memperkuat manajemen risiko.
7. Hati-hati dalam memperkenalkan ketergantungan pihak ketiga, lakukan verifikasi keamanan terhadap hulu dan hilir.

Bagaimana pengguna dapat menilai apakah kontrak pintar aman

1. Pastikan kontrak tersebut bersifat open source.
2. Periksa apakah Owner menggunakan mekanisme multi-tanda tangan yang terdesentralisasi.
3. Lihat situasi perdagangan yang sudah ada pada kontrak.
4. Memahami apakah kontrak tersebut adalah kontrak agen, apakah dapat diperbarui, dan apakah ada kunci waktu.
5. Pastikan kontrak telah diaudit oleh beberapa lembaga, dan hak akses Owner tidak terlalu besar.
6. Perhatikan penggunaan oracle, terutama waspada terhadap oracle yang dibangun sendiri atau yang tidak dapat diandalkan.

Dengan memperhatikan aspek-aspek ini, pengguna dapat lebih baik mengevaluasi keamanan kontrak pintar dan mengurangi risiko berpartisipasi dalam proyek Keuangan Desentralisasi.