BNB Chain adalah salah satu blockchain paling populer di dunia Web3. Biayanya yang masuk akal, transaksi cepat, dan ekosistem proyek yang kaya menarik banyak pengguna. Seperti halnya blockchain apa pun, pengembang di BNB Chain harus terlebih dahulu mempertimbangkan masalah keamanan selama proses pengembangan: karena hilangnya dana akan menyebabkan melemahnya kepercayaan pengguna terhadap protokol dan platform, dan kerentanan keamanan serta serangan peretas adalah salah satu risiko terbesar. dihadapi pengembang.
Dalam artikel ini, kami memberikan sepuluh tip keamanan praktis sehingga pengembang dapat mengurangi risiko dan mengembangkan kontrak pintar yang lebih aman di BNB Chain.
01
╱Definisi ╱
Serangan Replay, juga dikenal sebagai serangan replay dan serangan replay, adalah jenis serangan umum di lingkungan blockchain. Dalam keamanan siber, "serangan replay" adalah jenis serangan jaringan di mana transmisi data valid diulang atau ditunda secara jahat atau curang.
Dalam konteks Web3 dan kontrak pintar, hal ini secara umum berarti bahwa penyerang dapat mengulangi transaksi atau tindakan dalam kontrak pintar tanpa izin pengguna asli. Hal ini dapat menyebabkan berbagai bentuk penipuan seperti pembelanjaan ganda, dll.
Serangan ini dapat menimbulkan konsekuensi serius bagi pengguna dan pengembang karena memungkinkan penyerang menggunakan kembali tanda tangan yang sama untuk mendapatkan akses tidak sah ke semua dana atau aset lain di kontrak pintar.
Untuk mencegah serangan replay, pengembang harus merancang dan menerapkan kode kontrak pintar mereka dengan hati-hati dan mengikuti verifikasi tanda tangan serta standar keamanan terbaik industri.
02
╱ Analisis Kasus ╱
Cuplikan kode berikut mewakili proses implementasi transfer token pada rantai BNB. Kode ini rentan terhadap serangan replay, sehingga memungkinkan penyerang menggunakan kembali tanda tangan yang sama.
Fitur ini tidak memiliki perlindungan nonce atau replay, sehingga memungkinkan penyerang untuk "memutar ulang" transfer yang ditandatangani beberapa kali. Penyerang dapat mencegat transaksi yang ditandatangani dan mengirimkannya kembali ke kontrak yang sama atau kontrak lain, dan kontrak tersebut akan tetap menganggapnya valid, sehingga penyerang dapat memanfaatkan kerentanan ini untuk mencuri aset.
03
╱ Metode peningkatan ╱
Tambahkan nonce ke tanda tangan atau gunakan variabel pemetaan untuk mencatat tanda tangan. Solusi yang lebih spesifik akan bervariasi tergantung pada desain proyek.
01
╱Definisi ╱
Serangan reentrancy terjadi ketika kontrak jahat berulang kali memanggil kontrak yang rentan sebelum panggilan awal selesai. Dengan kata lain, penyerang dapat "menipu" kontrak yang rentan dengan mengira bahwa kontrak tersebut telah menyelesaikan satu transaksi dan bebas untuk melanjutkan ke transaksi berikutnya, namun kenyataannya kontrak tersebut masih mengeksekusi kode berbahaya penyerang.
Hal ini dapat mengakibatkan penyerang dapat memanipulasi status kontrak dengan cara yang tidak terduga dan berpotensi mendapatkan dana yang tidak sah.
02
╱ Analisis Kasus ╱
Pada cuplikan kode di bawah ini, pengguna dapat menarik dana dari akunnya dengan memanggil fungsi penarikan dan menentukan jumlah yang ingin ditarik. Namun, karena fungsi penarikan tidak melindungi terhadap panggilan rekursif ke fungsi tersebut, maka fungsi ini rentan terhadap serangan masuk kembali.
Penyerang dapat mengeksploitasi kerentanan dengan membuat kontrak jahat yang memanggil fungsi penarikan beberapa kali sebelum saldo benar-benar didebit dari rekeningnya. Fungsi msg.sender.call mengirimkan dana ke kontrak jahat, dan penyerang menggunakan fungsi terima() kontrak jahat untuk berulang kali menarik dana sebelum saldonya berkurang menjadi nol, sehingga menghabiskan semua dana kontrak korban.
03
╱ Metode perbaikan ╱
Lakukan pembaruan status sebelum panggilan eksternal apa pun.
Pola ini disebut pola "Check-Effects-Interact" dan merupakan pola desain yang digunakan untuk mencegah serangan masuk kembali dalam kontrak pintar. Pola ini memisahkan perubahan status dari panggilan eksternal ke kontrak lain dengan terlebih dahulu memeriksa prasyarat lalu memperbarui status sebelum melakukan panggilan eksternal. Dengan cara ini, jika panggilan eksternal memicu panggilan balik yang mencoba memanggil kembali ke kontrak, namun statusnya telah diperbarui, efek tak terduga lainnya dapat dicegah.
Dengan mengikuti pola ini, pengembang dapat memastikan bahwa kontrak mereka lebih aman dan tidak rentan terhadap serangan masuk kembali.
Perbaikan lain yang mungkin dilakukan adalah menggunakan pengubah untuk membatasi beberapa panggilan ke fungsi yang sama, seperti ReentrancyGuard OpenZeppelin.
01
╱Definisi ╱
Oracles dapat membantu kontrak pintar mengambil informasi dari luar blockchain. Biasanya harga aset bursa terdesentralisasi (DEX) ditentukan oleh harga yang diambil oleh oracle dari transaksi terakhir yang berhasil di DEX.
Namun, masalahnya adalah harga dapat dengan mudah dimanipulasi oleh siapa pun sehingga menyebabkan masalah pada kontrak pintar. Kita sering melihat kasus price oracle dimanipulasi melalui pinjaman kilat. Pasalnya, pinjaman kilat memungkinkan pengguna meminjam uang dalam jumlah besar tanpa agunan selama mereka melunasi pinjaman dalam blok yang sama. Hal ini memudahkan penyerang untuk mempengaruhi atau bahkan memanipulasi harga, mengambil keuntungan dari likuidasi palsu, pinjaman berlebihan, atau perdagangan tidak adil.
02
╱ Analisis Kasus ╱
Di bawah ini adalah cuplikan kode yang rentan terhadap serangan manipulasi Oracle.
Kontrak ini memungkinkan pengguna untuk menukar token A dengan token B menggunakan kontrak perutean, namun bergantung pada oracle eksternal (kontrak Uniswap Pair) untuk mendapatkan cadangan token A dan token B untuk menghitung harga. Penyerang dapat memanipulasi cadangan kontrak Uniswap Pair serta fungsi getAmountOut, yang pada akhirnya menyebabkan swap dieksekusi pada harga yang tidak masuk akal.
03
╱ Metode peningkatan ╱
Untuk mencegah serangan ini, pengembang harus menggunakan jaringan oracle terdesentralisasi yang dapat memperoleh harga rata-rata tertimbang volume (VWAP) atau harga rata-rata tertimbang waktu (TWAP) dari bursa terpusat dan terdesentralisasi on-chain. Dengan cara ini, data akan dikumpulkan dari berbagai sumber dan dalam rentang waktu yang luas, sehingga kode tidak terlalu rentan terhadap serangan dan manipulasi. Penting bagi pengembang untuk dapat menghapus vektor serangan yang memanipulasi Oracle dari kontrak pintar untuk mencegah potensi kerentanan.
01
╱Definisi ╱
Mengatur visibilitas fungsi dengan benar memastikan keamanan dan integritas kontrak pintar. Penggunaan pengaturan visibilitas fungsi yang salah dapat memungkinkan pengguna yang tidak diinginkan memanipulasi status kontrak, sehingga menyebabkan masalah serius seperti pencurian dana atau kendali atas fungsi kontrak.
Dengan mengatur visibilitas suatu fungsi ke pribadi atau internal, Anda memastikan bahwa pengembang memiliki akses terbatas ke fungsi tertentu dan hanya personel yang berwenang yang dapat memanggil fungsi tersebut. Fungsi privat hanya dapat dipanggil dari kontrak itu sendiri, sedangkan fungsi internal juga dapat dipanggil dari kontrak saat ini. Hal ini memungkinkan pengembang untuk membuat kontrak yang lebih kuat dan kompleks sambil mempertahankan kontrol atas akses ke fungsionalitas.
02
╱ Analisis Kasus ╱
Fungsi setAdmin() memungkinkan siapa saja untuk menetapkan alamat apa pun sebagai administrator kontrak. Bergantung pada izin yang diberikan dalam kontrak untuk mengelola alamat, hal ini dapat menyebabkan pengembang kehilangan kendali atas kontrak itu sendiri dan bahkan menyebabkan hilangnya dana.
Dengan mengatur visibilitas fungsi ke internal , beberapa fungsi kontrak mungkin secara internal mengizinkan pengguna tertentu untuk ditetapkan sebagai administrator.
03
╱ Metode peningkatan ╱
Pengubah akses adalah fitur keamanan penting yang menentukan siapa yang dapat mengakses fungsi atau variabel tertentu dalam kontrak. Pengubah ini dapat digunakan untuk membatasi visibilitas fungsi atau variabel tertentu ke peran atau alamat tertentu, dan mencegah pelaku jahat mendapatkan akses tidak sah atau manipulasi status kontrak.
Misalnya, suatu kontrak mungkin memiliki fungsi yang hanya dapat dipanggil oleh pemilik kontrak, atau variabel yang hanya dapat diakses oleh sekumpulan alamat tertentu.
Akses ke fungsi setAdmin dapat dibatasi ke alamat pemilik kontrak dengan mengubah pengubah visibilitas ke eksternal dan menyetel pengubah akses ke onlyOwner. Hal ini akan mencegah pihak eksternal yang jahat mengambil kendali atas fungsi istimewa tertentu.
Penggunaan visibilitas dan pengubah restriktif yang tepat dapat membuat manajemen kontrak lebih mudah dan mengurangi serangan umum seperti reentrancy (penyerang berulang kali memanggil fungsi untuk memanipulasi status kontrak) atau serangan front-running (penyerang memantau transaksi yang tertunda dan memanipulasi status kontrak sebelum transaksi legal transaksi dieksekusi).
Dengan menggunakan fitur-fitur ini secara tepat, pengembang dapat meningkatkan keamanan dan keandalan kontrak mereka, mengurangi risiko akses tidak sah, dan meningkatkan kualitas keseluruhan dan pemeliharaan kode mereka.
01
╱Definisi ╱
Saat memutuskan apakah akan meningkatkan suatu kontrak di masa depan, penting untuk mempertimbangkan dengan cermat desain kontrak pada awalnya. Peningkatan kontrak mengacu pada properti di mana logika kontrak pintar dapat dimodifikasi atau diperbarui setelah diterapkan pada blockchain. Meskipun kemampuan untuk ditingkatkan dapat memberikan banyak keuntungan (seperti memperbaiki bug, meningkatkan efisiensi, atau menambahkan fungsionalitas baru), hal ini juga menimbulkan beberapa risiko. Peningkatan kontrak dapat menimbulkan kerentanan baru, meningkatkan kompleksitas kontrak, atau menyebabkan konsekuensi yang tidak diinginkan.
Kemampuan untuk meningkatkan kontrak juga menimbulkan masalah kepercayaan karena administrator agen dapat meningkatkan kontrak tanpa konsensus komunitas. Pengembang perlu hati-hati mempertimbangkan keuntungan dan kerugian dari kemampuan untuk diupgrade dan menentukan apakah penerapan kontrak yang dapat diupgrade benar-benar diperlukan untuk proyek mereka. Dalam beberapa kasus, lebih aman merancang kontrak yang tidak dapat diubah sejak awal daripada mengandalkan kemampuan untuk memodifikasinya nanti.
02
╱ Metode peningkatan ╱
Terkait kemampuan peningkatan kontrak, ada beberapa praktik penting yang harus diikuti. Pertama dan terpenting, jangan mengubah perpustakaan proxy. Pustaka kontrak Proxy sangat kompleks, terutama dalam hal manajemen penyimpanan dan mekanisme peningkatan. Bahkan kesalahan kecil pun dapat sangat mempengaruhi pengoperasian Proxy dan kontrak logika. Faktanya, banyak kesalahan penting terkait proksi yang ditemukan selama audit disebabkan oleh modifikasi yang tidak tepat pada pustaka proksi.
Aspek penting lainnya dari kemampuan peningkatan kontrak adalah dimasukkannya "celah" penyimpanan dalam kontrak dasar. Kontrak logika harus menyertakan celah penyimpanan dalam kode kontrak untuk memperhitungkan variabel baru yang mungkin dimasukkan saat menerapkan implementasi logika baru. Setelah menambahkan variabel keadaan baru, memperbarui ukuran "celah" menjadi lebih penting. Praktik ini memastikan bahwa peningkatan di masa mendatang akan berjalan lancar dan tanpa masalah.
Terakhir, Anda harus menghindari penggunaan selfdestruct() atau melakukan delegasicall()/call() pada kontrak yang tidak tepercaya. Penyerang dapat mengeksploitasi fungsi-fungsi ini untuk menumbangkan implementasi logika atau menjalankan logika kustom. Untuk mencegah hal ini, penting untuk memvalidasi masukan pengguna! Jangan izinkan kontrak melakukan delegasicall()/call() pada kontrak yang tidak tepercaya. Selain itu, tidak disarankan untuk menggunakan delegasicall() dalam kontrak logika, karena mengelola tata letak penyimpanan di beberapa kontrak bisa jadi sulit. Dengan mengikuti praktik ini, pengembang dapat meminimalkan kerentanan dan risiko dalam peningkatan kontrak mereka.
01
╱Definisi ╱
Front-running selalu menjadi masalah yang membandel dan sulit dipecahkan, di mana pengguna bisa mendapatkan keuntungan dari penundaan antara pengiriman transaksi dan konfirmasi di blockchain. Penundaan ini disebabkan oleh mempool.
mempool adalah tempat penyimpanan sementara yang digunakan untuk menyimpan transaksi yang belum dikonfirmasi yang telah disiarkan ke jaringan. Semua node dalam jaringan memelihara mempool, memungkinkan siapa pun melihat transaksi yang tertunda dan berpotensi mencegat serta mengambil keuntungan dari transaksi tersebut. Mempool juga memberikan kesempatan kepada para penambang untuk mengatur ulang transaksi guna memaksimalkan keuntungan mereka, menciptakan apa yang dikenal sebagai nilai penambang (atau maksimum) yang dapat diekstraksi (MEV).
02
╱ Analisis Kasus ╱
Di bawah ini adalah contoh fitur penawaran lelang yang cenderung berjalan di awal.
Fitur ini memungkinkan pengguna untuk menawar dalam lelang, namun fitur ini mungkin terkena serangan awal. Misalkan pengguna jahat memantau blockchain dan melihat bahwa pengguna lain telah mengajukan tawaran yang tinggi. Pengguna jahat tersebut dapat dengan cepat mengajukan tawaran yang lebih tinggi dan diprioritaskan, yang pada akhirnya memenangkan lelang.
Pada versi berikutnya, pengguna mengirimkan harga tawaran yang tidak diketahui, dan tawaran ini disimpan dalam pemetaan. Jumlah penawaran dienkripsi hingga akhir periode penawaran.
03
╱ Metode perbaikan ╱
Di akhir periode penawaran, pengguna dapat mengungkapkan tawaran mereka dengan mengirimkan jumlah tawaran asli dan nilai rahasia. Kontrak memverifikasi bahwa jumlah tawaran dan hash rahasia cocok dengan tawaran rahasia yang disimpan, memastikan bahwa tawaran telah diserahkan sebelum akhir periode lelang. Jika tawaran tersebut lebih tinggi dari tawaran maksimum saat ini, maka tawaran tersebut menjadi tawaran maksimum yang baru. Fitur ini memitigasi serangan yang terjadi di awal dengan menyembunyikan jumlah tawaran hingga akhir periode lelang.
Front-running dan MEV telah menjadi perhatian utama dalam komunitas blockchain, dan berbagai solusi, seperti transaksi dan Fair Ordering Services (FSS), telah diusulkan untuk mengatasi masalah ini. Transaksi dapat membantu mencegah front-running dengan menyembunyikan detail transaksi dari pengguna lain hingga transaksi dieksekusi di blockchain. Di sisi lain, FSS dapat mengurangi dampak front-running dan MEV melalui pemesanan transaksi off-chain yang aman.
Memiliki rencana respons yang jelas dan komprehensif sangat penting untuk menangani insiden keamanan darurat. Rencana tersebut harus ditinjau secara berkala, diperbarui, dan diuji efektivitasnya. Ketika keadaan darurat keamanan terjadi, waktu adalah hal yang sangat penting. Oleh karena itu, rencana tersebut harus disesuaikan terlebih dahulu dan mencakup langkah-langkah operasional terperinci untuk identifikasi, pengendalian dan mitigasi.
Rencana tersebut harus dilaksanakan secara efektif agar semua pemangku kepentingan mendapat informasi. Pada saat yang sama, pencadangan data secara teratur juga penting untuk mencegah kehilangan data. Rencana tersebut perlu menguraikan proses pemulihan untuk memulihkan data dan sistem ke kondisi sebelumnya. Anggota tim harus menerima pelatihan sistematis mengenai rencana tersebut untuk memastikan semua orang memahami peran dan tanggung jawab mereka.
Rencana respons yang dipersiapkan dengan baik mungkin tidak dapat menyelesaikan masalah, namun dapat meminimalkan dampak insiden dan menjaga kepercayaan pengguna dan pemangku kepentingan.
Audit kode rutin sangat penting untuk menjaga keamanan aplikasi Anda. Bekerja dengan auditor profesional yang berspesialisasi dalam keamanan kontrak pintar merupakan langkah penting dalam proses pengembangan. Auditor akan memeriksa kode untuk mencari kerentanan dan memberikan rekomendasi untuk meningkatkan keamanan secara keseluruhan.
Memprioritaskan dan menyelesaikan masalah yang teridentifikasi serta menjaga komunikasi terbuka dengan auditor sangat penting untuk meningkatkan keamanan.
Selain itu, komunikasi dengan auditor juga penting. Auditor dapat menjelaskan secara rinci permasalahan dan kerentanan yang mereka temukan serta memberikan panduan dan bantuan praktis tentang cara mengatasi kerentanan tersebut. Dengan bekerja sama dengan lembaga/personel audit profesional, keamanan akan “dibawa ke tingkat berikutnya”.
Bagi pengembang rantai BNB, melakukan audit rutin merupakan bagian integral dari setiap strategi keamanan komprehensif. Mengidentifikasi dan menyelesaikan kerentanan dalam kode Anda secara proaktif dapat meminimalkan risiko pelanggaran keamanan.
Menggunakan program bounty adalah cara efektif untuk memberi insentif kepada komunitas peretas topi putih untuk melaporkan kerentanan keamanan dalam kode proyek. Dengan memberikan insentif seperti token atau imbalan lainnya, proyek apa pun dapat mendorong orang-orang berpengalaman untuk meninjau kode dan melaporkan potensi masalah yang mereka temukan.
Penting untuk memiliki program bug bounty yang jelas dan transparan. Rencana tersebut perlu mencakup: jenis kerentanan apa yang ditemukan yang memenuhi syarat untuk mendapatkan imbalan, bagaimana mengevaluasi nilai kerentanan ini, dll. Pada saat yang sama, melibatkan pihak ketiga yang memiliki reputasi baik dalam program bug bounty dapat membantu memastikan kelancaran program dan distribusi hadiah yang adil.
Pada saat yang sama, penting untuk memiliki “kelompok pemburu hadiah” yang beragam. Peretas topi putih yang berbeda memiliki bidang keahlian yang berbeda dan dapat fokus menemukan masalah yang mungkin terlewatkan oleh orang lain.
Terakhir, setelah kerentanan dilaporkan, tindakan harus diambil dengan cepat dan efektif untuk mengatasinya. Program bounty dapat menjadi alat yang efektif untuk mengidentifikasi kerentanan, namun hal ini hanya masuk akal jika tim pengembangan benar-benar memperbaiki masalahnya.
Mendidik pengguna Web3 tentang keamanan adalah langkah penting dalam membangun ekosistem yang aman. Memastikan keamanan pelanggan membantu memastikan keamanan platform. Pengguna harus dididik tentang praktik terbaik untuk melindungi akun dan informasi sensitif mereka.
Bagian terpentingnya adalah mempelajari cara menghindari penipuan phishing.
Penipu phishing menipu pengguna agar mengungkapkan kunci pribadi atau kata sandi mereka dengan berpura-pura menjadi situs web atau layanan yang sah. CertiK menyarankan agar pengguna selalu memeriksa ulang email, sumber, dll. URL situs web yang digunakan saat menerima informasi apa pun, dan jangan pernah memasukkan kunci pribadi atau kata sandi di situs web yang tidak tepercaya.
Dan bagian penting lainnya adalah memiliki kata sandi yang aman dan kuat. CertiK dengan ini merekomendasikan agar pengguna menggunakan kata sandi yang unik dan rumit untuk setiap akun dan menghindari penggunaan ulang kata sandi di berbagai layanan. Selain itu, kata sandi harus disimpan dengan aman menggunakan pengelola kata sandi atau mekanisme penyimpanan aman lainnya.
Terakhir, melindungi kunci pribadi sangatlah penting. Kunci pribadi setara dengan kata sandi pengguna dan harus dijamin tidak dapat diakses oleh orang lain kapan pun. Pengguna harus menghindari berbagi kunci pribadi mereka dengan siapa pun dan menyimpannya di tempat yang aman.
Meringkaskan
Pengembang yang membangun kontrak pintar dan dApps di BNB Chain harus mengambil pendekatan keamanan komprehensif untuk menjaga keamanan dana dan aset penggunanya. Yang lebih penting adalah bersikap proaktif dibandingkan reaktif ketika menghadapi pelanggaran keamanan; mempunyai rencana ketika atau bahkan sebelum pelanggaran terjadi, dan memberikan pendidikan keamanan yang sesuai kepada semua pengguna dan pemangku kepentingan terkait. Dengan menggabungkan semua langkah di atas, proyek dapat dibantu untuk mengurangi risiko pelanggaran keamanan dan serangan peretas secara signifikan.