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ı. Geçtiğimiz bir yıl içinde Web3 endüstrisinin karşılaştığı önemli güvenlik olaylarını gözden geçirdi, bu olayların nedenlerini ve nasıl önlenebileceğini tartıştı, yaygın akıllı sözleşme güvenlik açıklarını ve önleyici tedbirleri özetledi, ayrıca projelerin yöneticilerine ve sıradan kullanıcılara bazı güvenlik önerileri sundu.

Yaygın DeFi açık türleri arasında flash loan, fiyat manipülasyonu, fonksiyon yetki sorunları, rastgele dış çağrılar, fallback fonksiyonu sorunları, iş mantığı açıkları, özel anahtar sızıntısı ve yeniden giriş gibi durumlar bulunmaktadır. Aşağıda özellikle flash loan, fiyat manipülasyonu ve yeniden giriş saldırısı gibi üç tür üzerinde durulacaktır.

Hızlı Kredi

Flash loan, kendisi bir Merkezi Olmayan Finans inovasyonudur, ancak hackerlar tarafından kullanıldığında, maliyet olmadan büyük miktarda fon borç alabilirler, arbitraj işlemi tamamlandıktan sonra geri ödeyip, yalnızca az bir Gas ücreti ödeyerek büyük kazanç elde edebilirler.

Son iki yılda, flash loan sorunları sıkça ortaya çıktı. Bazı projeler yüksek getiriler vaat etse de, aslında proje ekiplerinin kalitesi değişkenlik gösteriyor. Kodun kendisinde bir güvenlik açığı olmasa bile, mantıksal olarak hala sorunlar olabilir. Örneğin, bazı projeler belirli bir zamanda, token sahiplerinin sahip olduğu token sayısına göre ödül dağıtıyor, ancak saldırganlar flash loan kullanarak büyük miktarda token satın alıp, ödül dağıtımında çoğu ödülü elde ediyor. Ayrıca, token ile fiyat hesaplayan bazı projeler, flash loan kullanarak fiyatı etkileyebiliyor. Proje ekiplerinin bu sorunlara karşı dikkatli olması gerekiyor.

Fiyat Manipülasyonu

Fiyat manipülasyonu sorunu ile flaş krediler arasında yakın bir ilişki vardır, başlıca iki tür vardır:

1. Fiyat hesaplanırken üçü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.

2. Belirli adreslerin token miktarını hesaplama değişkeni olarak kullanın ve bu adreslerin token bakiyeleri geçici olarak artırılabilir veya azaltılabilir.

Reentrancy Saldırısı

Dış sözleşmeleri çağırmanın en büyük tehlikelerinden biri, kontrol akışını devralabilmeleri ve verilere çağrılan fonksiyonların beklenmeyen değişiklikler yapabilmesidir.

Farklı sözleşmeler için, yeniden girişin birçok yolu vardır, sözleşmenin farklı fonksiyonları veya birden fazla farklı sözleşmenin fonksiyonları bir araya getirilerek yeniden giriş saldırısı gerçekleştirilebilir, bu nedenle yeniden giriş sorununu çözerken dikkat edilmesi gerekenler şunlardır:

1. Sadece tekil bir fonksiyonun yeniden giriş sorununu önlemekle kalmaz.

2. Checks-Effects-Interactions modeline göre kodlama yapın.

3. Zamanla test edilmiş reentrancy modifier'ı kullanın

En korkulan şey, tekerleği tekrar tekrar icat etmek; neye ihtiyaç varsa onu kendin yazmak. Bu alanda birçok en iyi güvenlik uygulaması var, bunları kullanmamız yeterli, tekerleği tekrar icat etmeye hiç gerek yok. Bir tekerlek icat ettiğinizde, bu tam olarak doğrulanmamış olur; bu durumda sorun çıkma olasılığı, çok olgun ve uzun süre test edilmiş birinin sorun çıkarma olasılığından çok daha büyük.

Güvenlik Önerileri

Proje Ekibi Güvenlik İpuçları

1. Sözleşme geliştirme en iyi güvenlik uygulamalarına uygun olmalıdır.

2. Sözleşme yükseltilebilir ve durdurulabilir: Birçok saldırı, paraların tamamını bir seferde almak yerine, birden fazla işlemle gerçekleştirilir. Eğer görece sağlam bir izleme mekanizması varsa, bu durum tespit edilebilir. Tespit edildikten sonra sözleşme durdurulabiliyorsa, kayıplar etkili bir şekilde azaltılabilir.

3. Zaman kilidi kullanımı: Eğer bir zaman kilidi varsa, varsayalım ki 48 saat içinde tamamlanması gerekiyor, bu süre zarfında birçok kişi, yaratıcı tarafından herkesin kullanabileceği bir mint yönteminin yeniden güncellendiğini fark edebilir. Takip edenler, projenin hacklenmiş olabileceğini anlayarak proje sahiplerini değiştirmeleri için uyarabilir. Hatta uyarı yapılmış olsa bile kimse umursamıyorsa, en azından kendi paylarını çekebilirler ve kendi kazançlarının zarar görmemesini sağlayabilirler. Bu nedenle, bir projenin zaman kilidi yoksa, teorik olarak sorun yaşama olasılığını artırmaktadır.

4. Güvenlik yatırımlarını artırmak, kapsamlı bir güvenlik sistemi kurmak: Güvenlik bir nokta değildir, bir çizgi de değildir, güvenlik sistematik bir yapıdır. Proje sahibi olarak, sözleşmenin birçok şirket tarafından denetlenmiş olmasının yeterli olduğunu düşünmemelisiniz; fon kaybına yol açabilecek her türlü riski göz önünde bulundurmalısınız. Risk modellemesi yapmaya çalışın ve ardından çoğu riski aşamalı olarak bertaraf edin, kalan riskler de kabul edilebilir riskler olmalıdır, dayanılabilir sınırlar içinde olmalıdır. Güvenlik ve verimlilik bir arada sağlanamaz, belirli bir fedakarlık yapmak zorundasınız. Ancak güvenliği tamamen göz ardı ederseniz, güvenlik için yatırım yapmazsanız, saldırıya uğramak oldukça normaldir.

5. Tüm çalışanların güvenlik bilincini artırmak: Güvenlik bilincini artırmak için çok fazla teknik bilgiye ihtiyaç yoktur. Bu büyük ortamda, sadece biraz daha fazla neden sormak, biraz daha fazla düşünmek birçok sorunun önlenmesini sağlayabilir.

6. İçerideki kötü niyetli davranışları önlemek, verimliliği artırırken risk yönetimini güçlendirmek: Örneğin, sözleşmenin sahibi tek imza mı yoksa çoklu imza mı, zaman kilidi kullanılıp kullanılmadığı gibi unsurların dikkate alınması gerekiyor.

7. Üçüncü tarafların güvenliği: Ekosistemin bir parçası olarak, projelerin kendine ait yukarı ve aşağı akışları olacaktır. Güvenlikte "varsayılan olarak yukarı ve aşağı akışların hepsi güvensizdir" ilkesi bulunmaktadır. Hem yukarı akış hem de aşağı akış için doğrulama yapılmalıdır. Üçüncü taraflar üzerinde kontrol sağlamak oldukça zor, güvenlik risk açığı aslında özellikle büyüktür, bu yüzden üçüncü tarafların dahil edilmesine çok dikkat edilmelidir. Sözleşme açık kaynaklıdır, onu dahil etmek veya çağırmak mümkündür; eğer sözleşme açık kaynak değilse, kesinlikle referans alınmamalıdır.

Kullanıcı/LP akıllı sözleşmenin güvenli olup olmadığını nasıl belirler?

Sıradan kullanıcılar için, bir projenin güvenli olup olmadığını değerlendirirken aşağıdaki altı noktaya bakmak önemlidir:

1. Sözleşme açık kaynak mı: Açık kaynak olmayan projeleri kesinlikle dokunmamalıyız, çünkü sözleşmede ne yazdığını bilemeyiz.

2. 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 mı yapıldığını belirleyemeyiz. Çoklu imza kullanılsa bile, çoklu imzanın merkeziyetsiz olup olmadığını da değerlendirmek gerekir.

3. Sözleşmenin mevcut işlem durumu: Özellikle piyasada birçok oltalama dolandırıcılığı yapan proje var, bu nedenle benzer bir sözleşme yapabilirler. Bu durumda, sözleşmenin dağıtım zamanına, etkileşim sayısına vb. bakmamız gerekiyor, bunlar sözleşmenin güvenli olup olmadığını belirlemek için ölçütlerdir.

4. Sözleşme bir vekil sözleşmesi mi, yükseltilebilir mi, zaman kilidi var mı: Eğer sözleşme tamamen yükseltilemezse, bu çok katı olur, yine de projelerin sözleşmelerinin yükseltilebilir olmasını öneririm. Ancak yükseltme yöntemine dikkat edilmelidir; yükseltme içeriği veya önemli parametre değişiklikleri olduğunda, bir zaman kilidi olmalıdır. Kullanıcılara gerçek yükseltmenin zararlı mı yoksa yararlı mı olduğunu değerlendirmeleri için bir zaman dilimi verilmelidir; bu da şeffaflığın bir yolu olarak kabul edilir.

5. Sözleşme birden fazla kurum tarafından denetlendi 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 personeli, sorunlara bakış açıları farklıdır. İkincisi, Owner'ın yetkilerinin çok fazla olup olmadığını kontrol etmek gerekir. Normal bir projede Owner'ın yetkisi kontrol edilebilir olmalıdır, böylece çok fazla yüksek riskli işlem olmayacak, işlemler zaman kilidi ile yapılacak ve kullanıcılara ne yapıldığını bildirecektir.

6. Oracle'lara Dikkat: Proje piyasadaki önde gelen oracle'ları kullanıyorsa, temelde büyük bir sorun olmayacaktır, ancak kendi oluşturduğu oracle'ları kullanıyorsa veya bazı rastgele teminatlar vererek fiyat besleyebilen oracle'ları kullanıyorsa, dikkatli olunmalıdır. Eğer oracle'larda bazı sorunlar olabileceği veya manipüle edilebileceği tespit edilirse, projeden elde edilen kazanç ne kadar yüksek olursa olsun katılmamak gerekir.