Keamanan Umum dalam Keuangan Desentralisasi dan Langkah-Langkah Pencegahan
Belakangan ini, seorang ahli keamanan membagikan pelajaran keamanan DeFi kepada anggota komunitas. Ahli tersebut meninjau insiden keamanan besar yang dialami industri Web3 selama lebih dari setahun terakhir, membahas penyebab terjadinya insiden keamanan ini serta cara menghindarinya, merangkum kerentanan keamanan umum pada kontrak pintar dan langkah-langkah pencegahannya, serta memberikan beberapa saran keamanan kepada pengembang proyek dan pengguna biasa.
Jenis-jenis kerentanan DeFi yang umum biasanya meliputi pinjaman kilat, manipulasi harga, masalah hak akses fungsi, panggilan eksternal sembarangan, masalah fungsi fallback, kerentanan logika bisnis, kebocoran kunci pribadi, dan reentrancy. Di bawah ini, kami akan fokus membahas tiga jenis ini: pinjaman kilat, manipulasi harga, dan serangan reentrancy.
Pinjaman Kilat
Pinjaman kilat sendiri adalah inovasi dalam Keuangan Desentralisasi, tetapi ketika dimanfaatkan oleh peretas, mereka dapat meminjam sejumlah besar dana tanpa biaya apa pun, menjalankan seluruh proses arbitrase dan mengembalikannya, hanya perlu membayar sedikit biaya Gas untuk mendapatkan keuntungan besar.
Dalam dua tahun terakhir, pinjaman kilat telah muncul banyak masalah. Beberapa proyek Keuangan Desentralisasi tampak menghasilkan tinggi, tetapi sebenarnya kualitas tim proyek sangat bervariasi. Beberapa proyek mungkin membeli kode, dan meskipun kode itu sendiri tidak memiliki kerentanan, secara logika masih mungkin ada masalah. Misalnya, pernah ada proyek yang memberikan hadiah berdasarkan jumlah token yang dimiliki oleh pemegang pada waktu tertentu, tetapi dieksploitasi oleh penyerang yang menggunakan pinjaman kilat untuk membeli sejumlah besar token, sehingga sebagian besar hadiah mengalir ke penyerang saat hadiah diberikan. Selain itu, ada beberapa proyek yang menghitung harga melalui Token, yang dapat dipengaruhi oleh pinjaman kilat. Sebagai tim proyek, harus meningkatkan kewaspadaan terhadap masalah ini.
Manipulasi Harga
Masalah manipulasi harga terkait erat dengan pinjaman kilat, masalah ini terutama disebabkan oleh beberapa parameter yang dapat dikendalikan oleh pengguna saat menghitung harga, jenis masalah yang sering muncul ada dua:
Menggunakan data pihak ketiga untuk menghitung harga, tetapi cara penggunaannya tidak benar atau pemeriksaan yang hilang menyebabkan harga dimanipulasi secara jahat.
Menggunakan jumlah Token dari beberapa alamat sebagai variabel perhitungan, dan saldo Token dari alamat-alamat ini dapat ditambahkan atau dikurangi secara sementara.
Serangan Re-entrancy
Salah satu bahaya utama dari memanggil kontrak eksternal adalah mereka dapat mengambil alih aliran kontrol dan melakukan perubahan yang tidak terduga pada data Anda.
Karena saldo pengguna baru disetel ke 0 pada akhir fungsi, panggilan kedua ( dan panggilan ) setelahnya masih akan berhasil, dan akan terus mengekstrak saldo berulang kali.
Untuk kontrak yang berbeda, ada banyak cara untuk melakukan reentrancy, yang dapat dilakukan dengan menggabungkan fungsi-fungsi dari kontrak yang berbeda atau fungsi dari beberapa kontrak yang berbeda untuk menyelesaikan serangan reentrancy. Oleh karena itu, saat kita menyelesaikan masalah reentrancy, kita perlu memperhatikan hal-hal berikut:
Tidak hanya mencegah masalah reentrancy dari satu fungsi;
Mengikuti pola Checks-Effects-Interactions dalam pengkodean;
Gunakan modifier pencegah reentrancy yang telah teruji oleh waktu.
Sebenarnya yang paling ditakuti adalah membuat roda yang sama berulang kali, perlu apa pun ditulis sendiri. Di dalam lingkaran ini ada banyak praktik keamanan terbaik, kita tinggal menggunakannya, tidak perlu membuat roda yang sama lagi. Ketika kamu membuat sebuah roda, itu belum melalui verifikasi yang cukup, pada saat itu probabilitas terjadinya masalah, jelas jauh lebih besar dibandingkan menggunakan sesuatu yang sudah matang dan teruji.
Saran Keamanan
Tips Keamanan Pihak Proyek
Pengembangan kontrak mengikuti praktik keamanan terbaik.
Kontrak dapat ditingkatkan dan dijeda: Banyak serangan tidak dilakukan sekaligus untuk mengalihkan semua koin, tetapi dilakukan dalam beberapa transaksi. Jika ada mekanisme pemantauan yang relatif baik, itu bisa terdeteksi, dan jika kontrak dapat dijeda setelah terdeteksi, maka kerugian dapat berkurang secara efektif.
Menggunakan kunci waktu: Jika ada kunci waktu, misalkan harus diselesaikan dalam 48 jam, pada saat itu banyak orang yang dapat menemukan bahwa pencipta telah memperbarui metode mint, dan siapa pun dapat menggunakannya, orang yang memantau akan tahu bahwa proyek tersebut kemungkinan telah diretas, dan dapat memberitahukan pihak proyek untuk mengubahnya, bahkan jika diasumsikan telah diberitahukan tetapi tidak ada yang mengurus, setidaknya dapat terlebih dahulu mengambil bagian uang mereka, untuk memastikan keuntungan mereka tidak terpengaruh. Jadi, jika sebuah proyek tidak memiliki kunci waktu, secara teori, itu meningkatkan kemungkinan terjadinya masalah.
Meningkatkan investasi keamanan, membangun sistem keamanan yang lengkap: keamanan bukanlah satu titik, juga bukan satu garis, keamanan adalah sistem yang terintegrasi. Jangan merasa bahwa sebagai pihak proyek, jika kontrak telah diaudit oleh banyak perusahaan, maka tidak ada masalah. Usahakan untuk melakukan pemodelan risiko, kemudian secara bertahap menghindari sebagian besar risiko, dan risiko yang tersisa juga merupakan risiko yang dapat diterima, dalam batas yang dapat ditanggung. Keamanan dan efisiensi tidak mungkin dicapai secara bersamaan, perlu ada pengorbanan tertentu. Namun, jika sama sekali tidak memperhatikan keamanan, tanpa investasi dalam keamanan, maka diserang adalah hal yang sangat normal.
Meningkatkan kesadaran keamanan semua karyawan: Meningkatkan kesadaran keamanan tidak memerlukan banyak teknologi. Dalam lingkungan besar ini, dengan sedikit lebih banyak bertanya mengapa dan sedikit lebih banyak berpikir, banyak masalah dapat dihindari.
Mencegah tindakan buruk internal, sambil meningkatkan efisiensi dan memperkuat manajemen risiko.
Keamanan Pihak Ketiga: Sebagai bagian dari ekosistem, setiap proyek memiliki hulu dan hilirnya sendiri. Dalam hal keamanan, ada prinsip "semua hulu dan hilir dianggap tidak aman". Baik untuk hulu maupun hilir, perlu dilakukan verifikasi. Untuk pihak ketiga, kita sangat sulit untuk mengontrol, sehingga risiko keamanan sebenarnya sangat besar, jadi perlu sangat berhati-hati dalam mengintroduksi pihak ketiga. Kontrak bersifat open source, bisa diintroduksi dan dipanggil; jika kontrak tidak open source, maka tidak boleh diacu.
Bagaimana pengguna/LP dapat menilai apakah kontrak pintar aman?
Untuk pengguna biasa, kami menilai apakah proyek tersebut aman dengan melihat enam poin berikut:
Apakah kontrak sumber terbuka: Semua proyek yang tidak membuka sumber kontraknya, tidak akan kami sentuh, karena kami tidak dapat mengetahui apa yang ditulis dalam kontrak tersebut.
Apakah Pemilik menggunakan multi-signature, apakah multi-signature tersebut terdesentralisasi: Jika tidak menggunakan multi-signature, kami tidak dapat menilai logika dan konten bisnis proyek, dan jika terjadi peristiwa keamanan, kami tidak dapat menentukan apakah itu disebabkan oleh peretas. Bahkan jika menggunakan multi-signature, perlu juga untuk menilai apakah multi-signature tersebut terdesentralisasi.
Situasi perdagangan kontrak yang sudah ada: terutama di pasar ada banyak proyek penipuan phishing, mungkin akan membuat kontrak yang cukup mirip, saat ini kita harus melihat waktu penerapan kontrak, jumlah interaksi, dll, ini semua adalah standar pengukuran untuk menilai apakah kontrak itu aman.
Apakah kontrak merupakan kontrak perwakilan, apakah dapat diperbarui, apakah ada kunci waktu: Jika kontrak sepenuhnya tidak dapat diperbarui, itu terlalu kaku, masih disarankan agar kontrak proyek dapat diperbarui. Namun, pembaruan harus dilakukan dengan hati-hati, ketika ada konten pembaruan, perubahan parameter penting, harus ada kunci waktu, harus memberikan waktu bagi semua orang untuk menilai apakah pembaruan yang sebenarnya merugikan atau menguntungkan bagi pengguna, ini juga merupakan salah satu cara yang terbuka dan transparan.
Apakah kontrak telah diaudit oleh beberapa lembaga ( Jangan percaya buta pada perusahaan audit ), Apakah hak akses Owner terlalu besar: Pertama, jangan hanya percaya pada satu perusahaan audit, karena perusahaan audit yang berbeda, auditor yang berbeda, memiliki sudut pandang yang berbeda dalam melihat masalah. Kedua, periksa apakah hak akses Owner terlalu besar. Hak akses Owner dari proyek yang normal harus terkontrol, sehingga tidak akan ada terlalu banyak operasi berisiko tinggi, dan operasi juga akan dilakukan dengan cara kunci waktu, memberi tahu pengguna tentang apa yang sedang dilakukan.
Perhatikan oracle: Jika proyek menggunakan oracle terkemuka yang ada di pasar, pada dasarnya tidak akan ada masalah besar, tetapi jika menggunakan oracle yang dibangun sendiri, atau menggunakan beberapa token yang dijaminkan sembarangan untuk memberi harga, maka harus berhati-hati. Ketika menemukan bahwa oracle mungkin memiliki beberapa masalah, atau ada kemungkinan dimanipulasi, meskipun proyek memiliki keuntungan tinggi, tetap tidak boleh berpartisipasi.
Halaman ini mungkin berisi konten pihak ketiga, yang disediakan untuk tujuan informasi saja (bukan pernyataan/jaminan) dan tidak boleh dianggap sebagai dukungan terhadap pandangannya oleh Gate, atau sebagai nasihat keuangan atau profesional. Lihat Penafian untuk detailnya.
Keamanan DeFi: Analisis Kerentanan Umum dan Langkah-langkah Pencegahan
Keamanan Umum dalam Keuangan Desentralisasi dan Langkah-Langkah Pencegahan
Belakangan ini, seorang ahli keamanan membagikan pelajaran keamanan DeFi kepada anggota komunitas. Ahli tersebut meninjau insiden keamanan besar yang dialami industri Web3 selama lebih dari setahun terakhir, membahas penyebab terjadinya insiden keamanan ini serta cara menghindarinya, merangkum kerentanan keamanan umum pada kontrak pintar dan langkah-langkah pencegahannya, serta memberikan beberapa saran keamanan kepada pengembang proyek dan pengguna biasa.
Jenis-jenis kerentanan DeFi yang umum biasanya meliputi pinjaman kilat, manipulasi harga, masalah hak akses fungsi, panggilan eksternal sembarangan, masalah fungsi fallback, kerentanan logika bisnis, kebocoran kunci pribadi, dan reentrancy. Di bawah ini, kami akan fokus membahas tiga jenis ini: pinjaman kilat, manipulasi harga, dan serangan reentrancy.
Pinjaman Kilat
Pinjaman kilat sendiri adalah inovasi dalam Keuangan Desentralisasi, tetapi ketika dimanfaatkan oleh peretas, mereka dapat meminjam sejumlah besar dana tanpa biaya apa pun, menjalankan seluruh proses arbitrase dan mengembalikannya, hanya perlu membayar sedikit biaya Gas untuk mendapatkan keuntungan besar.
Dalam dua tahun terakhir, pinjaman kilat telah muncul banyak masalah. Beberapa proyek Keuangan Desentralisasi tampak menghasilkan tinggi, tetapi sebenarnya kualitas tim proyek sangat bervariasi. Beberapa proyek mungkin membeli kode, dan meskipun kode itu sendiri tidak memiliki kerentanan, secara logika masih mungkin ada masalah. Misalnya, pernah ada proyek yang memberikan hadiah berdasarkan jumlah token yang dimiliki oleh pemegang pada waktu tertentu, tetapi dieksploitasi oleh penyerang yang menggunakan pinjaman kilat untuk membeli sejumlah besar token, sehingga sebagian besar hadiah mengalir ke penyerang saat hadiah diberikan. Selain itu, ada beberapa proyek yang menghitung harga melalui Token, yang dapat dipengaruhi oleh pinjaman kilat. Sebagai tim proyek, harus meningkatkan kewaspadaan terhadap masalah ini.
Manipulasi Harga
Masalah manipulasi harga terkait erat dengan pinjaman kilat, masalah ini terutama disebabkan oleh beberapa parameter yang dapat dikendalikan oleh pengguna saat menghitung harga, jenis masalah yang sering muncul ada dua:
Menggunakan data pihak ketiga untuk menghitung harga, tetapi cara penggunaannya tidak benar atau pemeriksaan yang hilang menyebabkan harga dimanipulasi secara jahat.
Menggunakan jumlah Token dari beberapa alamat sebagai variabel perhitungan, dan saldo Token dari alamat-alamat ini dapat ditambahkan atau dikurangi secara sementara.
Serangan Re-entrancy
Salah satu bahaya utama dari memanggil kontrak eksternal adalah mereka dapat mengambil alih aliran kontrol dan melakukan perubahan yang tidak terduga pada data Anda.
Karena saldo pengguna baru disetel ke 0 pada akhir fungsi, panggilan kedua ( dan panggilan ) setelahnya masih akan berhasil, dan akan terus mengekstrak saldo berulang kali.
Untuk kontrak yang berbeda, ada banyak cara untuk melakukan reentrancy, yang dapat dilakukan dengan menggabungkan fungsi-fungsi dari kontrak yang berbeda atau fungsi dari beberapa kontrak yang berbeda untuk menyelesaikan serangan reentrancy. Oleh karena itu, saat kita menyelesaikan masalah reentrancy, kita perlu memperhatikan hal-hal berikut:
Tidak hanya mencegah masalah reentrancy dari satu fungsi;
Mengikuti pola Checks-Effects-Interactions dalam pengkodean;
Gunakan modifier pencegah reentrancy yang telah teruji oleh waktu.
Sebenarnya yang paling ditakuti adalah membuat roda yang sama berulang kali, perlu apa pun ditulis sendiri. Di dalam lingkaran ini ada banyak praktik keamanan terbaik, kita tinggal menggunakannya, tidak perlu membuat roda yang sama lagi. Ketika kamu membuat sebuah roda, itu belum melalui verifikasi yang cukup, pada saat itu probabilitas terjadinya masalah, jelas jauh lebih besar dibandingkan menggunakan sesuatu yang sudah matang dan teruji.
Saran Keamanan
Tips Keamanan Pihak Proyek
Pengembangan kontrak mengikuti praktik keamanan terbaik.
Kontrak dapat ditingkatkan dan dijeda: Banyak serangan tidak dilakukan sekaligus untuk mengalihkan semua koin, tetapi dilakukan dalam beberapa transaksi. Jika ada mekanisme pemantauan yang relatif baik, itu bisa terdeteksi, dan jika kontrak dapat dijeda setelah terdeteksi, maka kerugian dapat berkurang secara efektif.
Menggunakan kunci waktu: Jika ada kunci waktu, misalkan harus diselesaikan dalam 48 jam, pada saat itu banyak orang yang dapat menemukan bahwa pencipta telah memperbarui metode mint, dan siapa pun dapat menggunakannya, orang yang memantau akan tahu bahwa proyek tersebut kemungkinan telah diretas, dan dapat memberitahukan pihak proyek untuk mengubahnya, bahkan jika diasumsikan telah diberitahukan tetapi tidak ada yang mengurus, setidaknya dapat terlebih dahulu mengambil bagian uang mereka, untuk memastikan keuntungan mereka tidak terpengaruh. Jadi, jika sebuah proyek tidak memiliki kunci waktu, secara teori, itu meningkatkan kemungkinan terjadinya masalah.
Meningkatkan investasi keamanan, membangun sistem keamanan yang lengkap: keamanan bukanlah satu titik, juga bukan satu garis, keamanan adalah sistem yang terintegrasi. Jangan merasa bahwa sebagai pihak proyek, jika kontrak telah diaudit oleh banyak perusahaan, maka tidak ada masalah. Usahakan untuk melakukan pemodelan risiko, kemudian secara bertahap menghindari sebagian besar risiko, dan risiko yang tersisa juga merupakan risiko yang dapat diterima, dalam batas yang dapat ditanggung. Keamanan dan efisiensi tidak mungkin dicapai secara bersamaan, perlu ada pengorbanan tertentu. Namun, jika sama sekali tidak memperhatikan keamanan, tanpa investasi dalam keamanan, maka diserang adalah hal yang sangat normal.
Meningkatkan kesadaran keamanan semua karyawan: Meningkatkan kesadaran keamanan tidak memerlukan banyak teknologi. Dalam lingkungan besar ini, dengan sedikit lebih banyak bertanya mengapa dan sedikit lebih banyak berpikir, banyak masalah dapat dihindari.
Mencegah tindakan buruk internal, sambil meningkatkan efisiensi dan memperkuat manajemen risiko.
Keamanan Pihak Ketiga: Sebagai bagian dari ekosistem, setiap proyek memiliki hulu dan hilirnya sendiri. Dalam hal keamanan, ada prinsip "semua hulu dan hilir dianggap tidak aman". Baik untuk hulu maupun hilir, perlu dilakukan verifikasi. Untuk pihak ketiga, kita sangat sulit untuk mengontrol, sehingga risiko keamanan sebenarnya sangat besar, jadi perlu sangat berhati-hati dalam mengintroduksi pihak ketiga. Kontrak bersifat open source, bisa diintroduksi dan dipanggil; jika kontrak tidak open source, maka tidak boleh diacu.
Bagaimana pengguna/LP dapat menilai apakah kontrak pintar aman?
Untuk pengguna biasa, kami menilai apakah proyek tersebut aman dengan melihat enam poin berikut:
Apakah kontrak sumber terbuka: Semua proyek yang tidak membuka sumber kontraknya, tidak akan kami sentuh, karena kami tidak dapat mengetahui apa yang ditulis dalam kontrak tersebut.
Apakah Pemilik menggunakan multi-signature, apakah multi-signature tersebut terdesentralisasi: Jika tidak menggunakan multi-signature, kami tidak dapat menilai logika dan konten bisnis proyek, dan jika terjadi peristiwa keamanan, kami tidak dapat menentukan apakah itu disebabkan oleh peretas. Bahkan jika menggunakan multi-signature, perlu juga untuk menilai apakah multi-signature tersebut terdesentralisasi.
Situasi perdagangan kontrak yang sudah ada: terutama di pasar ada banyak proyek penipuan phishing, mungkin akan membuat kontrak yang cukup mirip, saat ini kita harus melihat waktu penerapan kontrak, jumlah interaksi, dll, ini semua adalah standar pengukuran untuk menilai apakah kontrak itu aman.
Apakah kontrak merupakan kontrak perwakilan, apakah dapat diperbarui, apakah ada kunci waktu: Jika kontrak sepenuhnya tidak dapat diperbarui, itu terlalu kaku, masih disarankan agar kontrak proyek dapat diperbarui. Namun, pembaruan harus dilakukan dengan hati-hati, ketika ada konten pembaruan, perubahan parameter penting, harus ada kunci waktu, harus memberikan waktu bagi semua orang untuk menilai apakah pembaruan yang sebenarnya merugikan atau menguntungkan bagi pengguna, ini juga merupakan salah satu cara yang terbuka dan transparan.
Apakah kontrak telah diaudit oleh beberapa lembaga ( Jangan percaya buta pada perusahaan audit ), Apakah hak akses Owner terlalu besar: Pertama, jangan hanya percaya pada satu perusahaan audit, karena perusahaan audit yang berbeda, auditor yang berbeda, memiliki sudut pandang yang berbeda dalam melihat masalah. Kedua, periksa apakah hak akses Owner terlalu besar. Hak akses Owner dari proyek yang normal harus terkontrol, sehingga tidak akan ada terlalu banyak operasi berisiko tinggi, dan operasi juga akan dilakukan dengan cara kunci waktu, memberi tahu pengguna tentang apa yang sedang dilakukan.
Perhatikan oracle: Jika proyek menggunakan oracle terkemuka yang ada di pasar, pada dasarnya tidak akan ada masalah besar, tetapi jika menggunakan oracle yang dibangun sendiri, atau menggunakan beberapa token yang dijaminkan sembarangan untuk memberi harga, maka harus berhati-hati. Ketika menemukan bahwa oracle mungkin memiliki beberapa masalah, atau ada kemungkinan dimanipulasi, meskipun proyek memiliki keuntungan tinggi, tetap tidak boleh berpartisipasi.