Merkezi Olmayan Finans Yaygın Güvenlik Açıkları ve Önleme Önlemleri
Son zamanlarda, bir güvenlik uzmanı topluluk üyeleri için bir Merkezi Olmayan Finans güvenlik dersi paylaştı. Uzman, son bir yıl içinde Web3 sektörünün karşılaştığı önemli güvenlik olaylarını gözden geçirdi, bu güvenlik olaylarının nedenlerini ve nasıl önlenebileceğini tartıştı, yaygın akıllı sözleşmelerin güvenlik açıklarını ve önleyici önlemleri özetledi ve proje sahipleri ile sıradan kullanıcılar için bazı güvenlik önerileri sundu.
Yaygın DeFi açık türleri genellikle flash kredileri, fiyat manipülasyonu, fonksiyon yetki sorunları, rastgele dış çağrılar, fallback fonksiyonu sorunları, iş mantığı açıkları, özel anahtar sızıntıları ve yeniden giriş gibi sorunlardır. Aşağıda flash kredileri, fiyat manipülasyonu ve yeniden giriş saldırıları bu üç tür üzerinde durulacaktır.
Hızlı Kredi
Lightning loan kendisi bir Merkezi Olmayan Finans inovasyonudur, ancak hackerlar tarafından kullanıldığında, hiçbir maliyet olmadan büyük miktarda fon ödünç alabilirler, tüm arbitraj sürecini tamamladıktan sonra geri ödeyip sadece düşük bir Gas ücreti ödeyerek büyük kazançlar elde edebilirler.
Son iki yılda, hızlı krediler birçok sorunla karşılaştı. Bazı Merkezi Olmayan Finans projeleri yüksek getiriyormuş gibi görünse de, aslında proje ekiplerinin seviyeleri oldukça değişken. Bazı projelerin kodları satın alınmış olabilir, kodun kendisi açık olmadan bile, mantıksal olarak sorunlar ortaya çıkabilir. Örneğin, bir zamanlar belirli bir zamanda, token sahiplerinin sahip olduğu token sayısına göre ödül veren bir proje vardı; ancak saldırganlar hızlı kredi kullanarak büyük miktarda token satın almış ve ödül dağıtıldığında, ödüllerin çoğu saldırganlara gitmiştir. Ayrıca, Token kullanarak fiyat hesaplayan bazı projeler, hızlı kredilerle fiyatı etkileyebilir. Proje ekiplerinin bu sorunlara karşı dikkatli olması gerekir.
Fiyat Manipülasyonu
Fiyat manipülasyonu sorunu ve anlık kredi ilişkisi yakından bağlantılıdır, bu sorun esasen fiyat hesaplamasında bazı parametrelerin kullanıcı tarafından kontrol edilebilmesinden kaynaklanmaktadır, sıkça karşılaşılan sorun türleri ikiye ayrılmaktadır:
Fiyat hesaplama sırasında üçüncü taraf verileri kullanılır, ancak kullanım şekli yanlış veya kontrol eksikliği nedeniyle fiyat kötü niyetli bir şekilde manipüle edilir.
Hesaplama değişkeni olarak bazı adreslerin Token miktarları kullanılmıştır ve bu adreslerin Token bakiyeleri geçici olarak artırılabilir veya azaltılabilir.
Tekrar Giriş Saldırısı
Dış sözleşmeleri çağırmanın ana tehlikelerinden biri, kontrol akışını ele geçirebilmeleri ve verilerinize beklenmedik şekilde işlev çağrıları yapabilmeleridir.
Kullanıcının bakiyesi, fonksiyonun sonuna kadar 0 olarak ayarlandığı için, ikinci ( ve sonraki ) çağrıları hala başarılı olacaktır ve bakiye defalarca çekilecektir.
Farklı sözleşmeler için tekrar girişin birçok yolu vardır, farklı sözleşmelerin fonksiyonları veya sözleşmenin farklı fonksiyonları bir araya getirilerek tekrar giriş saldırısı gerçekleştirilebilir, bu nedenle tekrar giriş sorununu çözerken aşağıdaki noktalara dikkat etmemiz gerekir:
Sadece tek bir fonksiyonun yeniden çağrılmasını önlemekle kalmaz;
Checks-Effects-Interactions modeline göre kodlama yapın;
Zamanla test edilmiş reentrancy modifier'ı kullanın.
Aslında en korktuğumuz şey aynı tekerleği yeniden yapmak, neye ihtiyacımız varsa kendimiz yazmak. Bu alanda birçok en iyi güvenlik uygulaması var, bunları kullanmamız yeterli, aynı tekerleği yeniden yapmamıza kesinlikle gerek yok. Bir tekerlek yaptığınızda, bu yeterince doğrulanmamıştır, bu durumda sorun çıkma olasılığı, çok olgun ve uzun süre test edilmiş birinin sorun çıkma olasılığından çok daha fazladır.
Güvenlik Önerileri
Proje Tarafı Güvenlik İpuçları
Sözleşme geliştirme en iyi güvenlik uygulamalarına uygun olmalıdır.
Sözleşmeler yükseltilebilir ve duraklatılabilir: Birçok saldırı, tüm paraların tek seferde alınması yerine, birden fazla işlemle gerçekleştirilir. Eğer nispeten sağlam bir izleme mekanizması varsa, bu durum tespit edilebilir. Tespit edildikten sonra, sözleşme duraklatılabiliyorsa, kayıpları etkili bir şekilde azaltmak mümkündür.
Zaman kilidi kullanma: Eğer bir zaman kilidi varsa, varsayılan olarak 48 saat içinde tamamlanması gerektiğini düşünelim, bu durumda zaman kilidinde birçok insan, bu yaratıcı tarafından yeniden güncellenmiş bir mint yönteminin olduğunu fark edebilir ve herkes bunu kullanabilir. İzleyen kişiler, projenin hacklendiğini anlayabilir ve proje ekibine değişiklik yapmaları için bildirimde bulunabilir. Bildirimde bulunulsa bile kimse ilgilenmezse, en azından kendi payını geri alabilir ve kendi kazancını koruyabilir. Bu nedenle, bir projenin zaman kilidi yoksa, teorik olarak sorun yaşama olasılığını artırıyor.
Güvenlik yatırımlarını artırın, sağlam bir güvenlik sistemi kurun: güvenlik bir nokta değil, bir hat da değil, güvenlik sistematik bir yapıdadır. Proje sahibi olarak, sözleşmenin birçok şirket tarafından denetlenmiş olmasıyla sorun olmayacağını düşünmeyin. Risk modellemesi yapmaya çalışın ve ardından büyük çoğunluğu riski ortadan kaldırmaya yönelik adımlar atın; kalan risk de kabul edilebilir bir risk olmalı ve dayanılabilir bir aralıkta olmalıdır. Güvenlik ve verimlilik aynı anda sağlanamaz, belli bir fedakarlık yapmak gerekir. Ancak güvenliği tamamen göz ardı ederseniz ve güvenliğe yatırım yapmazsanız, saldırıya uğramak oldukça normaldir.
Tüm çalışanların güvenlik bilincini artırmak: Güvenlik bilincini artırmak için çok fazla teknolojiye ihtiyaç yoktur. Bu büyük ortamda, sadece biraz daha fazla neden sormak ve biraz daha fazla düşünmek, birçok sorunu önleyebilir.
İçerideki kötü niyetleri önlemek, verimliliği artırırken risk kontrolünü güçlendirmek.
Üçüncü tarafların güvenliği: Ekosistemin bir parçası olarak, proje ekiplerinin kendi yukarı ve aşağı akışları olacaktır. Güvenlik açısından "varsayılan olarak yukarı ve aşağı akışların güvensiz olduğu" prensibi vardır. Ne yukarı akış ne de aşağı akış için kontrol yapılmadan geçmemelidir. Üçüncü tarafları kontrol etmek oldukça zor, güvenlik risk açığı aslında oldukça büyüktür, bu yüzden üçüncü tarafların tanıtımına çok dikkat edilmelidir. Sözleşmeler açık kaynaklıdır, bunları tanıtabilir ve çağırabilirsiniz; eğer sözleşme açık kaynak değilse, kesinlikle atıfta bulunulmamalıdır.
Kullanıcı/LP akıllı sözleşmenin güvenli olup olmadığını nasıl belirler?
Ordinary kullanıcılar için, bir projenin güvenli olup olmadığını değerlendirirken esasen aşağıdaki altı noktaya bakıyoruz:
Sözleşme açık kaynak mı: Açık kaynak olmayan projeleri kesinlikle tercih etmiyorum, çünkü sözleşmenin ne yazdığını bilemeyiz.
Sahip, çoklu imza kullanıyor mu, çoklu imza merkeziyetsiz mi: Eğer çoklu imza kullanılmıyorsa, projenin iş mantığını ve içeriğini değerlendiremeyiz, bir güvenlik olayı meydana geldiğinde bunun bir hacker tarafından yapılıp yapılmadığını belirleyemeyiz. Çoklu imza kullanılsa bile, çoklu imzanın merkeziyetsiz olup olmadığını da değerlendirmek gerekir.
Sözleşmenin mevcut işlem durumu: Özellikle piyasada birçok oltalama dolandırıcılığı projesi bulunmakta, bu nedenle benzer bir sözleşme yapabilirler. Bu durumda, sözleşmenin dağıtım zamanını, etkileşim sayısını vb. kontrol etmemiz gerekiyor; bunlar sözleşmenin güvenli olup olmadığını belirlemenin ölçütleridir.
Sözleşme bir aracılık sözleşmesi mi, güncellenebilir mi, zaman kilidi var mı: Eğer sözleşme tamamen güncellenemez ise, bu çok katı olur, yine de projelerin sözleşmelerinin güncellenebilir olmasını öneririm. Ancak güncelleme yöntemine dikkat edilmelidir; güncelleme içerikleri ve önemli parametre değişiklikleri olduğunda, bir zaman kilidi olmalıdır, insanlara gerçek güncellemenin kullanıcılar için zararlı mı yoksa faydalı mı olduğunu değerlendirebilmeleri için bir zaman penceresi verilmelidir, bu da şeffaf bir yolun bir parçasıdır.
Sözleşme birden fazla kurum tarafından denetimden geçti mi ( denetim şirketlerine körü körüne güvenmeyin ), Owner yetkisi çok mu fazla: Öncelikle sadece bir denetim şirketine güvenmeyin, çünkü farklı denetim şirketleri, farklı denetim personelleri, sorunlara bakış açıları farklıdır. İkincisi, Owner'ın yetkisinin çok fazla olup olmadığını kontrol edin. Normal bir projenin Owner'ının yetkisi kontrol edilebilir olmalıdır, böylece çok fazla yüksek riskli işlem yapılmaz, işlemler de zaman kilidi yöntemiyle gerçekleştirilir, böylece kullanıcılar işlemin ne olduğunu bilir.
Oracle'lara Dikkat: Eğer proje piyasada bulunan lider oracle'ları kullanıyorsa, temelde büyük bir sorun olmayacaktır; ancak eğer kendi inşa ettikleri oracle'ları kullanıyorlarsa ya da bazı rastgele teminatlar vererek fiyat besleyebilecekleri oracle'ları kullanıyorlarsa, dikkatli olunması gerekir. Oracle'larda bazı sorunların olabileceği veya manipüle edilebileceği tespit edildiğinde, proje getirisi ne kadar yüksek olursa olsun katılmamak gerekir.
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
Merkezi Olmayan Finans güvenlik dersi: Yaygın açıkların analizi ve önleme önlemleri
Merkezi Olmayan Finans Yaygın Güvenlik Açıkları ve Önleme Önlemleri
Son zamanlarda, bir güvenlik uzmanı topluluk üyeleri için bir Merkezi Olmayan Finans güvenlik dersi paylaştı. Uzman, son bir yıl içinde Web3 sektörünün karşılaştığı önemli güvenlik olaylarını gözden geçirdi, bu güvenlik olaylarının nedenlerini ve nasıl önlenebileceğini tartıştı, yaygın akıllı sözleşmelerin güvenlik açıklarını ve önleyici önlemleri özetledi ve proje sahipleri ile sıradan kullanıcılar için bazı güvenlik önerileri sundu.
Yaygın DeFi açık türleri genellikle flash kredileri, fiyat manipülasyonu, fonksiyon yetki sorunları, rastgele dış çağrılar, fallback fonksiyonu sorunları, iş mantığı açıkları, özel anahtar sızıntıları ve yeniden giriş gibi sorunlardır. Aşağıda flash kredileri, fiyat manipülasyonu ve yeniden giriş saldırıları bu üç tür üzerinde durulacaktır.
Hızlı Kredi
Lightning loan kendisi bir Merkezi Olmayan Finans inovasyonudur, ancak hackerlar tarafından kullanıldığında, hiçbir maliyet olmadan büyük miktarda fon ödünç alabilirler, tüm arbitraj sürecini tamamladıktan sonra geri ödeyip sadece düşük bir Gas ücreti ödeyerek büyük kazançlar elde edebilirler.
Son iki yılda, hızlı krediler birçok sorunla karşılaştı. Bazı Merkezi Olmayan Finans projeleri yüksek getiriyormuş gibi görünse de, aslında proje ekiplerinin seviyeleri oldukça değişken. Bazı projelerin kodları satın alınmış olabilir, kodun kendisi açık olmadan bile, mantıksal olarak sorunlar ortaya çıkabilir. Örneğin, bir zamanlar belirli bir zamanda, token sahiplerinin sahip olduğu token sayısına göre ödül veren bir proje vardı; ancak saldırganlar hızlı kredi kullanarak büyük miktarda token satın almış ve ödül dağıtıldığında, ödüllerin çoğu saldırganlara gitmiştir. Ayrıca, Token kullanarak fiyat hesaplayan bazı projeler, hızlı kredilerle fiyatı etkileyebilir. Proje ekiplerinin bu sorunlara karşı dikkatli olması gerekir.
Fiyat Manipülasyonu
Fiyat manipülasyonu sorunu ve anlık kredi ilişkisi yakından bağlantılıdır, bu sorun esasen fiyat hesaplamasında bazı parametrelerin kullanıcı tarafından kontrol edilebilmesinden kaynaklanmaktadır, sıkça karşılaşılan sorun türleri ikiye ayrılmaktadır:
Fiyat hesaplama sırasında üçüncü taraf verileri kullanılır, ancak kullanım şekli yanlış veya kontrol eksikliği nedeniyle fiyat kötü niyetli bir şekilde manipüle edilir.
Hesaplama değişkeni olarak bazı adreslerin Token miktarları kullanılmıştır ve bu adreslerin Token bakiyeleri geçici olarak artırılabilir veya azaltılabilir.
Tekrar Giriş Saldırısı
Dış sözleşmeleri çağırmanın ana tehlikelerinden biri, kontrol akışını ele geçirebilmeleri ve verilerinize beklenmedik şekilde işlev çağrıları yapabilmeleridir.
Kullanıcının bakiyesi, fonksiyonun sonuna kadar 0 olarak ayarlandığı için, ikinci ( ve sonraki ) çağrıları hala başarılı olacaktır ve bakiye defalarca çekilecektir.
Farklı sözleşmeler için tekrar girişin birçok yolu vardır, farklı sözleşmelerin fonksiyonları veya sözleşmenin farklı fonksiyonları bir araya getirilerek tekrar giriş saldırısı gerçekleştirilebilir, bu nedenle tekrar giriş sorununu çözerken aşağıdaki noktalara dikkat etmemiz gerekir:
Sadece tek bir fonksiyonun yeniden çağrılmasını önlemekle kalmaz;
Checks-Effects-Interactions modeline göre kodlama yapın;
Zamanla test edilmiş reentrancy modifier'ı kullanın.
Aslında en korktuğumuz şey aynı tekerleği yeniden yapmak, neye ihtiyacımız varsa kendimiz yazmak. Bu alanda birçok en iyi güvenlik uygulaması var, bunları kullanmamız yeterli, aynı tekerleği yeniden yapmamıza kesinlikle gerek yok. Bir tekerlek yaptığınızda, bu yeterince doğrulanmamıştır, bu durumda sorun çıkma olasılığı, çok olgun ve uzun süre test edilmiş birinin sorun çıkma olasılığından çok daha fazladır.
Güvenlik Önerileri
Proje Tarafı Güvenlik İpuçları
Sözleşme geliştirme en iyi güvenlik uygulamalarına uygun olmalıdır.
Sözleşmeler yükseltilebilir ve duraklatılabilir: Birçok saldırı, tüm paraların tek seferde alınması yerine, birden fazla işlemle gerçekleştirilir. Eğer nispeten sağlam bir izleme mekanizması varsa, bu durum tespit edilebilir. Tespit edildikten sonra, sözleşme duraklatılabiliyorsa, kayıpları etkili bir şekilde azaltmak mümkündür.
Zaman kilidi kullanma: Eğer bir zaman kilidi varsa, varsayılan olarak 48 saat içinde tamamlanması gerektiğini düşünelim, bu durumda zaman kilidinde birçok insan, bu yaratıcı tarafından yeniden güncellenmiş bir mint yönteminin olduğunu fark edebilir ve herkes bunu kullanabilir. İzleyen kişiler, projenin hacklendiğini anlayabilir ve proje ekibine değişiklik yapmaları için bildirimde bulunabilir. Bildirimde bulunulsa bile kimse ilgilenmezse, en azından kendi payını geri alabilir ve kendi kazancını koruyabilir. Bu nedenle, bir projenin zaman kilidi yoksa, teorik olarak sorun yaşama olasılığını artırıyor.
Güvenlik yatırımlarını artırın, sağlam bir güvenlik sistemi kurun: güvenlik bir nokta değil, bir hat da değil, güvenlik sistematik bir yapıdadır. Proje sahibi olarak, sözleşmenin birçok şirket tarafından denetlenmiş olmasıyla sorun olmayacağını düşünmeyin. Risk modellemesi yapmaya çalışın ve ardından büyük çoğunluğu riski ortadan kaldırmaya yönelik adımlar atın; kalan risk de kabul edilebilir bir risk olmalı ve dayanılabilir bir aralıkta olmalıdır. Güvenlik ve verimlilik aynı anda sağlanamaz, belli bir fedakarlık yapmak gerekir. Ancak güvenliği tamamen göz ardı ederseniz ve güvenliğe yatırım yapmazsanız, saldırıya uğramak oldukça normaldir.
Tüm çalışanların güvenlik bilincini artırmak: Güvenlik bilincini artırmak için çok fazla teknolojiye ihtiyaç yoktur. Bu büyük ortamda, sadece biraz daha fazla neden sormak ve biraz daha fazla düşünmek, birçok sorunu önleyebilir.
İçerideki kötü niyetleri önlemek, verimliliği artırırken risk kontrolünü güçlendirmek.
Üçüncü tarafların güvenliği: Ekosistemin bir parçası olarak, proje ekiplerinin kendi yukarı ve aşağı akışları olacaktır. Güvenlik açısından "varsayılan olarak yukarı ve aşağı akışların güvensiz olduğu" prensibi vardır. Ne yukarı akış ne de aşağı akış için kontrol yapılmadan geçmemelidir. Üçüncü tarafları kontrol etmek oldukça zor, güvenlik risk açığı aslında oldukça büyüktür, bu yüzden üçüncü tarafların tanıtımına çok dikkat edilmelidir. Sözleşmeler açık kaynaklıdır, bunları tanıtabilir ve çağırabilirsiniz; eğer sözleşme açık kaynak değilse, kesinlikle atıfta bulunulmamalıdır.
Kullanıcı/LP akıllı sözleşmenin güvenli olup olmadığını nasıl belirler?
Ordinary kullanıcılar için, bir projenin güvenli olup olmadığını değerlendirirken esasen aşağıdaki altı noktaya bakıyoruz:
Sözleşme açık kaynak mı: Açık kaynak olmayan projeleri kesinlikle tercih etmiyorum, çünkü sözleşmenin ne yazdığını bilemeyiz.
Sahip, çoklu imza kullanıyor mu, çoklu imza merkeziyetsiz mi: Eğer çoklu imza kullanılmıyorsa, projenin iş mantığını ve içeriğini değerlendiremeyiz, bir güvenlik olayı meydana geldiğinde bunun bir hacker tarafından yapılıp yapılmadığını belirleyemeyiz. Çoklu imza kullanılsa bile, çoklu imzanın merkeziyetsiz olup olmadığını da değerlendirmek gerekir.
Sözleşmenin mevcut işlem durumu: Özellikle piyasada birçok oltalama dolandırıcılığı projesi bulunmakta, bu nedenle benzer bir sözleşme yapabilirler. Bu durumda, sözleşmenin dağıtım zamanını, etkileşim sayısını vb. kontrol etmemiz gerekiyor; bunlar sözleşmenin güvenli olup olmadığını belirlemenin ölçütleridir.
Sözleşme bir aracılık sözleşmesi mi, güncellenebilir mi, zaman kilidi var mı: Eğer sözleşme tamamen güncellenemez ise, bu çok katı olur, yine de projelerin sözleşmelerinin güncellenebilir olmasını öneririm. Ancak güncelleme yöntemine dikkat edilmelidir; güncelleme içerikleri ve önemli parametre değişiklikleri olduğunda, bir zaman kilidi olmalıdır, insanlara gerçek güncellemenin kullanıcılar için zararlı mı yoksa faydalı mı olduğunu değerlendirebilmeleri için bir zaman penceresi verilmelidir, bu da şeffaf bir yolun bir parçasıdır.
Sözleşme birden fazla kurum tarafından denetimden geçti mi ( denetim şirketlerine körü körüne güvenmeyin ), Owner yetkisi çok mu fazla: Öncelikle sadece bir denetim şirketine güvenmeyin, çünkü farklı denetim şirketleri, farklı denetim personelleri, sorunlara bakış açıları farklıdır. İkincisi, Owner'ın yetkisinin çok fazla olup olmadığını kontrol edin. Normal bir projenin Owner'ının yetkisi kontrol edilebilir olmalıdır, böylece çok fazla yüksek riskli işlem yapılmaz, işlemler de zaman kilidi yöntemiyle gerçekleştirilir, böylece kullanıcılar işlemin ne olduğunu bilir.
Oracle'lara Dikkat: Eğer proje piyasada bulunan lider oracle'ları kullanıyorsa, temelde büyük bir sorun olmayacaktır; ancak eğer kendi inşa ettikleri oracle'ları kullanıyorlarsa ya da bazı rastgele teminatlar vererek fiyat besleyebilecekleri oracle'ları kullanıyorlarsa, dikkatli olunması gerekir. Oracle'larda bazı sorunların olabileceği veya manipüle edilebileceği tespit edildiğinde, proje getirisi ne kadar yüksek olursa olsun katılmamak gerekir.