Reentrancy Saldırısı: Neden Akıllı Sözleşmeler Sürekli Olarak Boşaltılıyor ( ve Bunu Nasıl Durdurabilirsiniz )

Hızlı Versiyon: Yeniden giriş, bir hacker'ın siz para transferi yaparken geri araması gibidir—işlem bile bitmeden cüzdanınızı boşaltır.

İşte acı gerçek: $100M reentrancy istismarları nedeniyle kaybedildi. En ünlüsü? DAO hack'i (2016) bu tam zafiyeti istismar ederek $50M ETH çaldı.

Saldırının Nasıl Çalıştığı (Gerçek Kod Mantığı Kullanarak)

Hayal et ki ContractA 10 ETH tutuyor ve ContractB içinde 1 ETH bakiyesi var.

ContractB withdrawAll() çağırdığında, olması gerekenler şunlardır:

1. Bakiyeyi kontrol et > 0 ✓
2. ETH'yi geri gönder ✓
3. Bakiyeyi 0 olarak güncelle ✓

Ama işte burada kırılıyor: Saldırgan işlem sırasını kullanıyor.

İstismar Akışı:

• Saldırgan attack() çağrısını yapar → bu da ContractA üzerinde withdrawAll() çağrısını yapar
• ContractA, 1 ETH gönderir ve saldırganın fallback() fonksiyonunu tetikler.
• Bakiyeler 0'a güncellenmeden önce, fallback() hemen withdrawAll()'i tekrar çağırır.
• ContractA kontrol eder: “Bakiye > 0 mı?” EVET ( çünkü henüz güncellenmedi!)
• Başka bir 1 ETH gönderir → fallback() tekrar tetiklenir
• Bu, ContractA tamamen boşalana kadar döner.

Anahtar içgörü: Bakiyenin güncellenmesi, ETH transferinden SONRA gerçekleşir. Bu, zayıflık penceresidir.

Üç Savunma Stratejisi

1. NonReentrant Modifier (Tek Fonksiyon Koruma)

Fonksiyon yürütülürken kilitleyin. Yeniden girişe izin yok: katılık modifier nonReentrant { require(!locked, “No reentrancy”); kilitli = true; _; kilitli = false; }

Basit, ama yalnızca bir işlevi aynı anda korur.

2. Kontroller-Etkiler-Etkileşimler Deseni (Çok Fonksiyonlu Koruma)

Bu bir devrim yaratan:

• Kontroller: Koşulları doğrulayın (bakiye > 0)
• Etkiler: Durumu güncelle (bakiye = 0) ← Bunu ETH göndermeden ÖNCE taşı
• Etkileşimler: ETH Gönder

Yanlış sipariş:

require(balance > 0); → ETH gönder → bakiye = 0; // Çok geç!

Doğru sıra:

require(balance > 0); → bakiye = 0; // İLKİ Güncelle → ETH gönder // Sonra etkileşimde bulun

Artık fallback() yeniden girse bile, bakiye zaten 0. Saldırı başarısız.

3. GlobalReentrancyGuard (Cross-Contract Protection)

Birden fazla etkileşimde bulunan sözleşmelere sahip karmaşık sistemler için, tüm sözleşmeler arasındaki kilit durumunu izleyen merkezi bir koruma sözleşmesi kullanın. ContractA, ContractB'yi çağırdığında, koruma bunu kaydeder—eğer ContractB, geri dönmeden önce sisteme geri çağrı yapmaya çalışırsa, koruma bunu engeller.

Bunun Önemi

Reentrancy sadece bir Solidity problemi değil—bu bir tasarım problemi. Her ETH gönderdiğinizde veya dış fonksiyonları çağırdığınızda, güvenilmeyen koda kontrol veriyorsunuz. Saldırganın geri dönüş fonksiyonu SİZİN sözleşmenizin bağlamında çalışır.

Veri: Chainalysis, 2023-2024 döneminde yüksek değere sahip istismarların yaklaşık %60'ının yeniden giriş veya benzeri kalıplar içerdiğini buldu. Yearn, Curve ve Balancer gibi en iyi projelerin hepsi yeniden giriş korkuları yaşadı.

Sonuç: Varsayılan olarak Checks-Effects-Interactions kullanın. Gerektiğinde nonReentrant ekleyin. Çoklu sözleşme sistemleri için GlobalReentrancyGuard'ı uygulayın. Kaybedilen $100M+'dan fazlası, bu temel kalıplarla kurtarılabilirdi.

Daha fazla Web3 güvenlik derinlemesine inceleme için @TheBlockChainer'ı takip edin.