Keamanan Umum dalam Keuangan Desentralisasi dan Langkah Pencegahannya
Dalam waktu dekat, seorang ahli keamanan membagikan kelas keamanan DeFi untuk anggota komunitas. Dia meninjau peristiwa keamanan besar yang terjadi di industri Web3 selama lebih dari setahun, membahas penyebab terjadinya peristiwa ini dan bagaimana cara menghindarinya, merangkum kerentanan keamanan umum dari kontrak pintar serta langkah pencegahannya, dan memberikan beberapa saran keamanan untuk pengembang proyek dan pengguna biasa.
Jenis-jenis kerentanan DeFi yang umum meliputi pinjaman kilat, manipulasi harga, masalah hak akses fungsi, pemanggilan eksternal sembarangan, masalah fungsi fallback, kerentanan logika bisnis, kebocoran kunci pribadi, dan reentrancy. Berikut ini akan dibahas secara mendalam tentang pinjaman kilat, manipulasi harga, dan serangan reentrancy.
Pinjaman Kilat
Pinjaman kilat sendiri adalah inovasi dalam Keuangan Desentralisasi, tetapi ketika dimanfaatkan oleh hacker, mereka dapat meminjam sejumlah besar dana tanpa biaya, mengembalikannya setelah menjalankan arbitrase, dan hanya perlu membayar sedikit biaya Gas untuk mendapatkan keuntungan besar.
Selama dua tahun terakhir, masalah pinjaman kilat sering muncul. Beberapa proyek tampaknya memiliki imbal hasil yang tinggi, tetapi sebenarnya tingkat kemampuan tim proyek bervariasi. Bahkan jika kode itu sendiri tidak memiliki celah, secara logika masih mungkin ada masalah. Misalnya, beberapa proyek akan memberikan hadiah berdasarkan jumlah token yang dimiliki pemegang pada waktu tertentu, tetapi dapat dimanfaatkan oleh penyerang yang menggunakan pinjaman kilat untuk membeli sejumlah besar token, dan pada saat pemberian hadiah, mereka mendapatkan sebagian besar hadiah. Ada juga beberapa proyek yang menghitung harga berdasarkan token, yang dapat dipengaruhi oleh pinjaman kilat. Tim proyek harus lebih waspada terhadap masalah ini.
Pengendalian Harga
Masalah manipulasi harga sangat erat kaitannya dengan pinjaman kilat, yang terutama terdiri dari dua jenis:
Menggunakan data pihak ketiga saat menghitung harga, tetapi cara penggunaan yang tidak benar atau kurangnya pemeriksaan mengakibatkan harga dapat dimanipulasi secara jahat.
Menggunakan jumlah token dari beberapa alamat sebagai variabel perhitungan, dan saldo token dari alamat-alamat ini dapat ditambah atau dikurangi secara sementara.
Serangan Reentrancy
Salah satu bahaya utama dari memanggil kontrak eksternal adalah bahwa mereka dapat mengambil alih aliran kontrol, dan melakukan perubahan pada data dengan fungsi pemanggilan yang tidak terduga.
Untuk berbagai kontrak, ada banyak cara untuk melakukan reentrancy, yang dapat dilakukan dengan menggabungkan fungsi-fungsi dari kontrak yang berbeda atau fungsi-fungsi dari beberapa kontrak yang berbeda untuk menyelesaikan serangan reentrancy. Oleh karena itu, saat menyelesaikan masalah reentrancy, perlu diperhatikan:
Tidak hanya mencegah masalah reentrancy dari satu fungsi.
Mengikuti pola Checks-Effects-Interactions dalam pengkodean
Gunakan modifier pencegah reentrancy yang telah teruji waktu
Yang paling ditakuti adalah membuat roda yang sama berulang kali, perlu menulis semuanya sendiri. Di dalam lingkaran ini ada banyak praktik keamanan terbaik, kita tinggal menggunakannya, tidak perlu membuat roda yang sama lagi. Ketika kamu membuat roda, itu belum terverifikasi sepenuhnya, pada saat itu kemungkinan terjadinya masalah jelas jauh lebih besar dibandingkan dengan menggunakan sesuatu yang sudah sangat matang dan teruji.
Saran Keamanan
Tips Keamanan Proyek
Pengembangan kontrak mengikuti praktik keamanan terbaik.
Kontrak dapat ditingkatkan dan dijeda: Banyak serangan tidak langsung memindahkan semua koin sekaligus, tetapi dieksekusi dalam beberapa transaksi. Jika ada mekanisme pemantauan yang relatif baik, hal itu dapat terdeteksi. Setelah terdeteksi, jika kontrak dapat dijeda, maka kerugian dapat secara efektif dikurangi.
Menggunakan kunci waktu: Jika ada kunci waktu, misalnya harus diselesaikan dalam 48 jam, saat itu banyak orang dapat menemukan bahwa pencipta telah memperbarui metode mint yang dapat digunakan oleh semua orang selama periode kunci waktu, orang yang memantau akan tahu proyek tersebut mungkin telah diretas, dan dapat memberi tahu pihak proyek untuk berubah, bahkan jika sudah diberi tahu, tidak ada yang peduli, setidaknya mereka dapat mengambil bagian uang mereka sendiri terlebih dahulu, untuk memastikan keuntungan mereka tidak terpengaruh. Jadi, jika suatu proyek tidak memiliki kunci waktu, secara teori, itu meningkatkan kemungkinan masalah terjadi.
Meningkatkan investasi keamanan, membangun sistem keamanan yang lengkap: Keamanan bukanlah suatu titik, juga bukan garis, keamanan adalah sistem yang terintegrasi. Jangan berpikir bahwa sebagai pihak proyek, jika kontrak telah diaudit oleh banyak perusahaan, semuanya akan baik-baik saja, harus mempertimbangkan berbagai risiko yang dapat menyebabkan kerugian dana. Usahakan untuk melakukan pemodelan risiko, lalu secara bertahap menghindari sebagian besar risiko, risiko yang tersisa juga harus dapat diterima, dalam batas yang dapat ditanggung. Keamanan dan efisiensi tidak mungkin dicapai secara bersamaan, harus ada pengorbanan tertentu. Namun, jika sama sekali tidak memperhatikan keamanan, tanpa investasi di bidang keamanan, diserang adalah hal yang sangat wajar.
Meningkatkan kesadaran keamanan semua karyawan: Meningkatkan kesadaran keamanan tidak memerlukan banyak teknologi. Dalam lingkungan yang besar ini, hanya dengan sedikit lebih banyak bertanya mengapa, sedikit lebih banyak berpikir, kita dapat menghindari banyak masalah.
Mencegah tindakan jahat internal, sambil meningkatkan efisiensi dan memperkuat pengendalian risiko: misalnya, apakah pemilik kontrak menggunakan tanda tangan tunggal atau tanda tangan ganda, apakah menggunakan kunci waktu, dan lain-lain, semuanya perlu dipertimbangkan.
Keamanan Pihak Ketiga: Sebagai bagian dari ekosistem, setiap proyek memiliki hulu dan hilirnya sendiri. Ada prinsip "secara default hulu dan hilir tidak aman" dalam hal keamanan. Baik untuk hulu maupun hilir, pemeriksaan harus dilakukan. Untuk pihak ketiga, kita sangat sulit untuk mengontrol, dan risiko keamanan sebenarnya sangat besar, jadi kita harus sangat memperhatikan pengenalan pihak ketiga. Kontrak bersifat open source, dapat diambil dan dipanggil; jika kontrak tidak open source, maka tidak boleh direferensikan.
Bagaimana pengguna/LP dapat menentukan apakah kontrak pintar aman?
Untuk pengguna biasa, menilai apakah proyek itu aman terutama melihat enam poin berikut:
Apakah kontrak bersifat sumber terbuka: Proyek yang kontraknya tidak bersifat sumber terbuka, kami tidak akan menyentuhnya, karena kami tidak dapat mengetahui apa yang tertulis dalam kontrak tersebut.
Apakah Pemilik menggunakan multi-tanda tangan, dan apakah multi-tanda tangan tersebut terdesentralisasi: Jika tidak menggunakan multi-tanda tangan, kami tidak dapat menilai logika bisnis dan konten proyek, dan jika terjadi insiden keamanan, kami tidak dapat menentukan apakah itu disebabkan oleh peretas. Bahkan jika menggunakan multi-tanda tangan, perlu juga menilai apakah multi-tanda tangan tersebut terdesentralisasi.
Situasi perdagangan kontrak yang sudah ada: terutama ada banyak proyek penipuan phishing di pasar, mungkin akan membuat kontrak yang cukup mirip, pada saat ini kita perlu melihat waktu penerapan kontrak, jumlah interaksi, dll, semua ini adalah standar pengukuran untuk menilai apakah kontrak tersebut aman.
Apakah kontrak merupakan kontrak agen, apakah dapat ditingkatkan, apakah ada kunci waktu: Jika kontrak sepenuhnya tidak dapat ditingkatkan, itu terlalu kaku, saya masih merekomendasikan kontrak proyek yang dapat ditingkatkan. Namun, peningkatan harus dilakukan dengan cara yang tepat, ketika ada konten peningkatan, perubahan parameter penting, harus ada kunci waktu, harus memberikan jendela waktu bagi semua orang untuk menilai apakah peningkatan yang nyata merugikan atau menguntungkan bagi pengguna, ini juga merupakan cara yang terbuka dan transparan.
Apakah kontrak telah diaudit oleh banyak 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 dapat dikendalikan, sehingga tidak akan ada terlalu banyak operasi berisiko tinggi, dan operasi juga akan menggunakan cara kunci waktu, agar pengguna tahu apa yang sedang dioperasikan.
Perhatikan Oracle: Jika proyek menggunakan oracle terkemuka di pasar, pada dasarnya tidak akan ada masalah besar, tetapi jika menggunakan oracle buatan sendiri, atau menggunakan oracle yang bisa memberi harga hanya dengan menggadaikan beberapa token secara sembarangan, maka harus diwaspadai. Ketika ditemukan bahwa oracle mungkin memiliki beberapa masalah, atau ada kemungkinan manipulasi, meskipun proyek tersebut menghasilkan keuntungan yang 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.
9 Suka
Hadiah
9
5
Bagikan
Komentar
0/400
BrokeBeans
· 07-22 12:06
Wah, Pinjaman Flash ini sangat menguntungkan, sayangnya saya tidak bisa...
Lihat AsliBalas0
LayerZeroHero
· 07-22 06:59
Lagi-lagi Pinjaman Flash menjadi target? Tidak mengejutkan.
Lihat AsliBalas0
P2ENotWorking
· 07-19 19:46
Jika ingin menghasilkan uang, Anda harus tahu cara mencegah celah.
Analisis Kerentanan Keamanan Umum DeFi: Pencegahan Pinjaman Flash, Manipulasi Harga, dan Serangan Re-entrancy
Keamanan Umum dalam Keuangan Desentralisasi dan Langkah Pencegahannya
Dalam waktu dekat, seorang ahli keamanan membagikan kelas keamanan DeFi untuk anggota komunitas. Dia meninjau peristiwa keamanan besar yang terjadi di industri Web3 selama lebih dari setahun, membahas penyebab terjadinya peristiwa ini dan bagaimana cara menghindarinya, merangkum kerentanan keamanan umum dari kontrak pintar serta langkah pencegahannya, dan memberikan beberapa saran keamanan untuk pengembang proyek dan pengguna biasa.
Jenis-jenis kerentanan DeFi yang umum meliputi pinjaman kilat, manipulasi harga, masalah hak akses fungsi, pemanggilan eksternal sembarangan, masalah fungsi fallback, kerentanan logika bisnis, kebocoran kunci pribadi, dan reentrancy. Berikut ini akan dibahas secara mendalam tentang pinjaman kilat, manipulasi harga, dan serangan reentrancy.
Pinjaman Kilat
Pinjaman kilat sendiri adalah inovasi dalam Keuangan Desentralisasi, tetapi ketika dimanfaatkan oleh hacker, mereka dapat meminjam sejumlah besar dana tanpa biaya, mengembalikannya setelah menjalankan arbitrase, dan hanya perlu membayar sedikit biaya Gas untuk mendapatkan keuntungan besar.
Selama dua tahun terakhir, masalah pinjaman kilat sering muncul. Beberapa proyek tampaknya memiliki imbal hasil yang tinggi, tetapi sebenarnya tingkat kemampuan tim proyek bervariasi. Bahkan jika kode itu sendiri tidak memiliki celah, secara logika masih mungkin ada masalah. Misalnya, beberapa proyek akan memberikan hadiah berdasarkan jumlah token yang dimiliki pemegang pada waktu tertentu, tetapi dapat dimanfaatkan oleh penyerang yang menggunakan pinjaman kilat untuk membeli sejumlah besar token, dan pada saat pemberian hadiah, mereka mendapatkan sebagian besar hadiah. Ada juga beberapa proyek yang menghitung harga berdasarkan token, yang dapat dipengaruhi oleh pinjaman kilat. Tim proyek harus lebih waspada terhadap masalah ini.
Pengendalian Harga
Masalah manipulasi harga sangat erat kaitannya dengan pinjaman kilat, yang terutama terdiri dari dua jenis:
Menggunakan data pihak ketiga saat menghitung harga, tetapi cara penggunaan yang tidak benar atau kurangnya pemeriksaan mengakibatkan harga dapat dimanipulasi secara jahat.
Menggunakan jumlah token dari beberapa alamat sebagai variabel perhitungan, dan saldo token dari alamat-alamat ini dapat ditambah atau dikurangi secara sementara.
Serangan Reentrancy
Salah satu bahaya utama dari memanggil kontrak eksternal adalah bahwa mereka dapat mengambil alih aliran kontrol, dan melakukan perubahan pada data dengan fungsi pemanggilan yang tidak terduga.
Untuk berbagai kontrak, ada banyak cara untuk melakukan reentrancy, yang dapat dilakukan dengan menggabungkan fungsi-fungsi dari kontrak yang berbeda atau fungsi-fungsi dari beberapa kontrak yang berbeda untuk menyelesaikan serangan reentrancy. Oleh karena itu, saat menyelesaikan masalah reentrancy, perlu diperhatikan:
Tidak hanya mencegah masalah reentrancy dari satu fungsi.
Mengikuti pola Checks-Effects-Interactions dalam pengkodean
Gunakan modifier pencegah reentrancy yang telah teruji waktu
Yang paling ditakuti adalah membuat roda yang sama berulang kali, perlu menulis semuanya sendiri. Di dalam lingkaran ini ada banyak praktik keamanan terbaik, kita tinggal menggunakannya, tidak perlu membuat roda yang sama lagi. Ketika kamu membuat roda, itu belum terverifikasi sepenuhnya, pada saat itu kemungkinan terjadinya masalah jelas jauh lebih besar dibandingkan dengan menggunakan sesuatu yang sudah sangat matang dan teruji.
Saran Keamanan
Tips Keamanan Proyek
Pengembangan kontrak mengikuti praktik keamanan terbaik.
Kontrak dapat ditingkatkan dan dijeda: Banyak serangan tidak langsung memindahkan semua koin sekaligus, tetapi dieksekusi dalam beberapa transaksi. Jika ada mekanisme pemantauan yang relatif baik, hal itu dapat terdeteksi. Setelah terdeteksi, jika kontrak dapat dijeda, maka kerugian dapat secara efektif dikurangi.
Menggunakan kunci waktu: Jika ada kunci waktu, misalnya harus diselesaikan dalam 48 jam, saat itu banyak orang dapat menemukan bahwa pencipta telah memperbarui metode mint yang dapat digunakan oleh semua orang selama periode kunci waktu, orang yang memantau akan tahu proyek tersebut mungkin telah diretas, dan dapat memberi tahu pihak proyek untuk berubah, bahkan jika sudah diberi tahu, tidak ada yang peduli, setidaknya mereka dapat mengambil bagian uang mereka sendiri terlebih dahulu, untuk memastikan keuntungan mereka tidak terpengaruh. Jadi, jika suatu proyek tidak memiliki kunci waktu, secara teori, itu meningkatkan kemungkinan masalah terjadi.
Meningkatkan investasi keamanan, membangun sistem keamanan yang lengkap: Keamanan bukanlah suatu titik, juga bukan garis, keamanan adalah sistem yang terintegrasi. Jangan berpikir bahwa sebagai pihak proyek, jika kontrak telah diaudit oleh banyak perusahaan, semuanya akan baik-baik saja, harus mempertimbangkan berbagai risiko yang dapat menyebabkan kerugian dana. Usahakan untuk melakukan pemodelan risiko, lalu secara bertahap menghindari sebagian besar risiko, risiko yang tersisa juga harus dapat diterima, dalam batas yang dapat ditanggung. Keamanan dan efisiensi tidak mungkin dicapai secara bersamaan, harus ada pengorbanan tertentu. Namun, jika sama sekali tidak memperhatikan keamanan, tanpa investasi di bidang keamanan, diserang adalah hal yang sangat wajar.
Meningkatkan kesadaran keamanan semua karyawan: Meningkatkan kesadaran keamanan tidak memerlukan banyak teknologi. Dalam lingkungan yang besar ini, hanya dengan sedikit lebih banyak bertanya mengapa, sedikit lebih banyak berpikir, kita dapat menghindari banyak masalah.
Mencegah tindakan jahat internal, sambil meningkatkan efisiensi dan memperkuat pengendalian risiko: misalnya, apakah pemilik kontrak menggunakan tanda tangan tunggal atau tanda tangan ganda, apakah menggunakan kunci waktu, dan lain-lain, semuanya perlu dipertimbangkan.
Keamanan Pihak Ketiga: Sebagai bagian dari ekosistem, setiap proyek memiliki hulu dan hilirnya sendiri. Ada prinsip "secara default hulu dan hilir tidak aman" dalam hal keamanan. Baik untuk hulu maupun hilir, pemeriksaan harus dilakukan. Untuk pihak ketiga, kita sangat sulit untuk mengontrol, dan risiko keamanan sebenarnya sangat besar, jadi kita harus sangat memperhatikan pengenalan pihak ketiga. Kontrak bersifat open source, dapat diambil dan dipanggil; jika kontrak tidak open source, maka tidak boleh direferensikan.
Bagaimana pengguna/LP dapat menentukan apakah kontrak pintar aman?
Untuk pengguna biasa, menilai apakah proyek itu aman terutama melihat enam poin berikut:
Apakah kontrak bersifat sumber terbuka: Proyek yang kontraknya tidak bersifat sumber terbuka, kami tidak akan menyentuhnya, karena kami tidak dapat mengetahui apa yang tertulis dalam kontrak tersebut.
Apakah Pemilik menggunakan multi-tanda tangan, dan apakah multi-tanda tangan tersebut terdesentralisasi: Jika tidak menggunakan multi-tanda tangan, kami tidak dapat menilai logika bisnis dan konten proyek, dan jika terjadi insiden keamanan, kami tidak dapat menentukan apakah itu disebabkan oleh peretas. Bahkan jika menggunakan multi-tanda tangan, perlu juga menilai apakah multi-tanda tangan tersebut terdesentralisasi.
Situasi perdagangan kontrak yang sudah ada: terutama ada banyak proyek penipuan phishing di pasar, mungkin akan membuat kontrak yang cukup mirip, pada saat ini kita perlu melihat waktu penerapan kontrak, jumlah interaksi, dll, semua ini adalah standar pengukuran untuk menilai apakah kontrak tersebut aman.
Apakah kontrak merupakan kontrak agen, apakah dapat ditingkatkan, apakah ada kunci waktu: Jika kontrak sepenuhnya tidak dapat ditingkatkan, itu terlalu kaku, saya masih merekomendasikan kontrak proyek yang dapat ditingkatkan. Namun, peningkatan harus dilakukan dengan cara yang tepat, ketika ada konten peningkatan, perubahan parameter penting, harus ada kunci waktu, harus memberikan jendela waktu bagi semua orang untuk menilai apakah peningkatan yang nyata merugikan atau menguntungkan bagi pengguna, ini juga merupakan cara yang terbuka dan transparan.
Apakah kontrak telah diaudit oleh banyak 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 dapat dikendalikan, sehingga tidak akan ada terlalu banyak operasi berisiko tinggi, dan operasi juga akan menggunakan cara kunci waktu, agar pengguna tahu apa yang sedang dioperasikan.
Perhatikan Oracle: Jika proyek menggunakan oracle terkemuka di pasar, pada dasarnya tidak akan ada masalah besar, tetapi jika menggunakan oracle buatan sendiri, atau menggunakan oracle yang bisa memberi harga hanya dengan menggadaikan beberapa token secara sembarangan, maka harus diwaspadai. Ketika ditemukan bahwa oracle mungkin memiliki beberapa masalah, atau ada kemungkinan manipulasi, meskipun proyek tersebut menghasilkan keuntungan yang tinggi, tetap tidak boleh berpartisipasi.