Keamanan DeFi dan Langkah Pencegahan

Belakangan ini, seorang ahli keamanan membagikan kursus keamanan DeFi untuk komunitas. Ahli tersebut meninjau kejadian keamanan besar yang dihadapi industri Web3 selama setahun terakhir, membahas penyebab kejadian tersebut dan bagaimana cara menghindarinya, merangkum celah keamanan kontrak pintar yang umum serta langkah pencegahannya, dan memberikan beberapa saran keamanan untuk pengembang proyek dan pengguna.

Jenis-jenis kerentanan DeFi yang umum termasuk pinjaman kilat, manipulasi harga, masalah hak akses fungsi, pemanggilan eksternal sembarangan, masalah fungsi fallback, kerentanan logika bisnis, kebocoran kunci pribadi, dan serangan reentrancy. Artikel ini akan fokus pada tiga jenis tersebut: pinjaman kilat, manipulasi harga, dan serangan reentrancy.

Pinjaman Kilat

Pinjaman kilat adalah inovasi dalam Keuangan Desentralisasi, tetapi juga dimanfaatkan oleh peretas untuk melakukan serangan. Penyerang 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 yang besar, atau dimanfaatkan untuk mendapatkan imbalan yang tidak semestinya.

Banyak proyek Keuangan Desentralisasi rentan terhadap serangan pinjaman kilat karena masalah kode atau logika. Misalnya, beberapa proyek memberikan hadiah berdasarkan kepemilikan dalam waktu tetap, namun dapat dimanfaatkan oleh penyerang yang menggunakan pinjaman kilat untuk membeli sejumlah besar token dan mendapatkan sebagian besar hadiah. Ada juga proyek yang menghitung harga melalui Token, yang juga bisa terpengaruh oleh pinjaman kilat. Pihak proyek harus tetap waspada terhadap masalah ini.

Pengendalian Harga

Masalah manipulasi harga sangat terkait dengan pinjaman kilat, terutama ada dua situasi:

1. Menghitung harga menggunakan data pihak ketiga, tetapi cara penggunaannya tidak benar atau pemeriksaan hilang, mengakibatkan harga dimanipulasi secara jahat.

2. Menggunakan jumlah Token dari alamat tertentu sebagai variabel perhitungan, di mana saldo Token dari alamat-alamat ini dapat ditambah atau dikurangi sementara.

Serangan Reentrancy

Risiko utama dari memanggil kontrak eksternal adalah bahwa mereka dapat mengambil alih alur kontrol dan melakukan perubahan yang tidak diinginkan pada data. Contohnya:

solidity pemetaan (alamat => uint) saldoPenggunaPribadi;

fungsi menarikSaldo() publik { uint amountToWithdraw = userBalances[msg.sender]; (bool success, ) = msg.sender.call.value(amountToWithdraw)(""); require(success); userBalances[msg.sender] = 0; }

Karena saldo pengguna diatur menjadi 0 hanya di akhir fungsi, pemanggilan ulang masih akan berhasil, sehingga saldo dapat ditarik beberapa kali.

Berbagai bentuk serangan reentrancy dapat melibatkan fungsi yang berbeda dari kontrak tunggal atau fungsi dari beberapa kontrak. Untuk menyelesaikan masalah reentrancy, perlu diperhatikan:

1. Tidak hanya mencegah reentrancy dari satu fungsi
2. Mengkode sesuai pola Checks-Effects-Interactions
3. Gunakan modifier anti-reentrancy yang telah terverifikasi

Disarankan untuk menggunakan praktik keamanan yang matang, hindari membuat roda yang sama. Solusi baru yang dikembangkan sendiri kurang divalidasi secara memadai, sehingga probabilitas munculnya masalah cukup tinggi.

Saran Keamanan

Saran Keamanan 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 semua karyawan
6. Mencegah tindakan jahat internal, sambil meningkatkan efisiensi dan memperkuat manajemen risiko.
7. Hati-hati dalam memperkenalkan ketergantungan pihak ketiga, secara default hilir dan hulu tidak aman

Bagaimana pengguna menentukan keamanan kontrak pintar

1. Apakah kontrak tersebut bersifat sumber terbuka
2. Apakah Pemilik menggunakan multi-tanda tangan terdesentralisasi
3. Periksa situasi transaksi yang sudah ada dalam kontrak
4. Apakah kontrak dapat diupgrade, apakah ada penguncian waktu
5. Apakah menerima audit dari banyak lembaga, apakah hak akses Owner terlalu besar
6. Perhatikan keandalan oracle

Total, pihak proyek dan pengguna harus meningkatkan kesadaran keamanan, mengambil langkah-langkah yang diperlukan untuk mengurangi risiko keamanan Keuangan Desentralisasi.