Smart Contract Denetimi: Reentrancy ve Overflow Önleme

Article author

Akıllı sözleşme denetimi, özellikle DeFi ve zincir üzeri yönetişimin trilyonlarca kilitli değer çektiği bu dönemde, sağlam Web3 altyapısının temel taşı olmaya devam ediyor. Soken olarak 280’den fazla denetim gerçekleştirdik ve kritik açığı tekrar giriş (reentrancy) ve aritmetik taşmalar gibi, giderilmediği takdirde milyonlarca dolarlık açıklar doğuran sorunları tutarlı şekilde tespit ediyoruz. Bu makale, temel tehdit vektörleri olan tekrar giriş, aritmetik taşma ve izin kusurlarını ayrıntılı biçimde inceliyor ve dağıtımdan önce sözleşmeleri güçlendirmek için kanıtlanmış geliştirme ve denetim en iyi uygulamalarını sunuyor.

Ayrıca, savunmasızlıkları açığa çıkaran Solidity kod kalıplarını inceleyip, gerçek denetimlerden öğrenilen çözümler öneriyoruz. Son olarak erişim kontrol modellerini karşılaştırarak, güvenli akıllı sözleşme izinlerinin sağlanmasında sundukları avantajları ve dezavantajları vurguluyoruz. Amaç, geliştiricilere, DeFi kurucularına ve güvenlik ekiplerine, kod ve mimari düzeyde riski azaltan, kurşun geçirmez akıllı sözleşmeler tasarlamalarında yardımcı olmaktır.

Akıllı sözleşme tekrar girişi (reentrancy) nedir ve nasıl önlenir?

Akıllı sözleşmede tekrar giriş, dış çağrının bir saldırgana, ilk yürütme tamamlanmadan sözleşmenin fonksiyonuna tekrar tekrar giriş yapma imkanı vermesiyle ortaya çıkan bir zaafiyettir. Bu durum yetkisiz durum değişikliklerine yol açar. 2016’daki ünlü DAO saldırısı ve yakın zamanda DeFi açıklarında görüldüğü gibi, ciddi varlık kaybına sebep olur. Temel savunma, durum değişiklikleri ile dış çağrıların dikkatle sıralanması, mutex (karşılıklı dışlama) kullanımı ve Solidity’nin yerleşik ReentrancyGuard yapısından faydalanmadır.

Soken olarak sözleşmeyi denetlerken, tekrar giriş açığının 2026’da kritik denetim bayraklarının yaklaşık %18’ini oluşturmasıyla en yaygın ve yüksek etkili açık olduğunu gördük. En iyi uygulama, durum güncellemelerinin dış çağrılardan önce yapılması ya da OpenZeppelin kütüphanelerindeki nonReentrant modifikatörünün kullanılmasıdır.

Naif tekrar giriş kod örneği:

mapping(address => uint256) public balances;

function withdraw(uint256 amount) external {
    require(balances[msg.sender] >= amount, "Insufficient funds");
    (bool success, ) = msg.sender.call{value: amount}("");
    require(success, "Transfer failed");
    balances[msg.sender] -= amount;  // Dış çağrı sonrası durum güncellemesi - savunmasız
}

Çağrıdan önce durum güncellemesi ile güvenli model:

function withdraw(uint256 amount) external {
    require(balances[msg.sender] >= amount, "Insufficient funds");
    balances[msg.sender] -= amount;  // Önce durum güncellenir
    (bool success, ) = msg.sender.call{value: amount}("");
    require(success, "Transfer failed");
}

Soken metodolojisi uzman görüşü:

Tüm dışa açık, durum değiştiren fonksiyonlar için varsayılan olarak OpenZeppelin’in ReentrancyGuard kullanımını ve denetimlerde kapsamlı manuel incelemeleri tavsiye ediyoruz. Bu çift katmanlı strateji, denetlenen sözleşmelerde tekrar giriş riskini 2024’ten beri %90’dan fazla düşürmüştür.

Aritmetik taşma ve alt sınırı akıllı sözleşme güvenliğini nasıl etkiler?

Aritmetik taşma veya alt sınır, tamsayı hesaplarında sayının izin verilen maksimumun üzerine çıkması ya da minimumun altına düşmesi sonucu beklenmedik sarmalara neden olur. Bu tür hatalar bakiyeleri, sayacı veya izin bayraklarını bozabilir, fazla token basımı veya limit atlaması gibi sömürü senaryoları yaratabilir. Solidity 0.8+ sürümlerinde yerleşik denetlemeler olmasına rağmen, kontrolleri devre dışı bırakan veya unchecked bloklar kullanan kalıplar halen zafiyet yaratmaya devam ediyor.

Chainalysis’in 2025 verilerine göre, DeFi saldırılarının yaklaşık %12’si kontrolsüz aritmetik hatalarını hedef aldı. Soken denetimleri, performans gerekçesiyle derleyici kontrollerinin pasif edildiği ve miras sözleşmelerde özellikle hafif ama sömürülebilir alt sınırlar ortaya çıktığını tespit etti.

Savunmasız model (Solidity <0.8 veya unchecked):

uint256 public totalSupply;

function mint(uint256 amount) external {
    totalSupply += amount; // Kontrol edilmezse taşma olabilir
}

Solidity 0.8+ ile kontrol edilen güvenli model:

function mint(uint256 amount) external {
    totalSupply += amount; // Otomatik kontrol, taşma olursa revert eder
}

Performans kritik durumlarda açıkça unchecked blok kullanımı:

function addUnchecked(uint256 a, uint256 b) internal pure returns (uint256) {
    unchecked {
        return a + b;
    }
}

unchecked blokları sadece dış doğrulamalarla ve minimum saldırı yüzeyi garanti edilerek kullanılmalıdır. Denetimlerimizde, yerleşik taşma denetimlerinin kapatılması kritik risk olarak raporlanır.

Akıllı sözleşmede erişim kontrol modelleri nelerdir ve hangisi en güvenlidir?

Akıllı sözleşmede erişim kontrolü, hassas fonksiyonları çalıştırabilecek veya sözleşme durumunu değiştirebilecek tarafları belirler. Yaygın modeller Ownable, Rol Tabanlı Erişim Kontrolü (RBAC) ve Multisig’dir. Her model kullanım kolaylığı ve güvenlik arasında farklı dengeler sunar. Ownable en basit ancak tek anahtar arızası riski taşır. RBAC daha detaylı izinler sağlar ama karmaşıklığı artırır. Multisig ise birden çok onay gerektirdiği için güvenliği artırırken kullanıcı deneyiminde sürtünmeye yol açabilir.

2024-2026 arasında yapılan DeFi ve NFT projeleri incelememizde, karmaşık yönetişim ihtiyaçları nedeniyle RBAC benimsenmesinin %34 arttığını gördük. Buna karşılık, denetlenen projelerin %40’ı hâlâ yalnızca Ownable kullanmakta ve bunun tek noktalı başarısızlık riskini artırdığı görülmektedir.

Erişim kontrol modelleri karşılaştırması:

Model İzin Ayrıntısı Güvenlik Seviyesi Karmaşıklık Endüstri Kullanım Alanı
Ownable Tek sahibi Orta (tek anahtar riski) Düşük Küçük projeler, ilk MVP’ler
RBAC Çoklu roller Yüksek (çoklu rol delegasyonu) Orta DeFi protokolleri, DAO’lar, çok servisli uygulamalar
Multisig Çoklu imzalayıcılar Çok yüksek (çok taraflı mutabakat) Yüksek Hazine yönetimi, yüksek değerli kasalar

OpenZeppelin’in RBAC’sini kullanan Solidity örneği:

import "@openzeppelin/contracts/access/AccessControl.sol";

contract MyContract is AccessControl {
    bytes32 public constant ADMIN_ROLE = keccak256("ADMIN_ROLE");

    constructor() {
        _setupRole(DEFAULT_ADMIN_ROLE, msg.sender);
        _setupRole(ADMIN_ROLE, msg.sender);
    }

    function secureFunction() external onlyRole(ADMIN_ROLE) {
        // Hassas işlem burada
    }
}

Soken uzman görüşü:

Etkili akıllı sözleşme izinleri, tüm kritik fonksiyonlarda RBAC veya multisig uygulayıp tek sahipli admin anahtarlarından kaçınmalıdır. Denetimler sırasında, yönetim anahtarlarının sosyal mühendisliğe ve özel anahtar sızıntısına karşı donanımsal cüzdanlarda veya multisig’de olmasına dikkat ederiz.

Güvenli akıllı sözleşme geliştirme uygulamaları nasıl hayata geçirilir?

Güvenli akıllı sözleşme geliştirme, tasarımdan kodlama, test ve dağıtıma kadar güvenliği bütünleştirmeyi gerektirir. İyi denetlenmiş kütüphaneler (OpenZeppelin) kullanmak, dış çağrıları minimize etmek, constructor’da karmaşık mantıktan kaçınmak, fuzzing ve sembolik yürütme araçlarıyla kapsamlı test yapmak başlıca uygulamalardır. Değiştirilemez (immutable) sözleşmeler, şeffaf yönetişimle yükseltme kalıplarıyla dikkatli uygulanmalıdır.

Soken metodolojisi, bilinen kalıpların yanı sıra tarayıcıların göremediği yeni zafiyet imzalarını bulmak için manuel çok aşamalı denetimleri otomatik statik ve dinamik analiz araçlarıyla birleştirir.

Güvenli geliştirme kontrol listesi:

Adım Açıklama Araçlar / Kütüphaneler
Güvenli kütüphane kullanımı OpenZeppelin gibi sınanmış sözleşmelerin tekrarlı kullanımı OpenZeppelin Contracts
Dış çağrıları sınırlandırma Saldırı yüzeyini azaltmak için dış etkileşimi kısıtlama Manuel inceleme + tekrar giriş testleri
Kapsamlı test Fuzzing, sembolik yürütme, birim ve entegrasyon testleri Echidna, MythX, Slither
İzin modellerini uygulama RBAC veya multisig ile hassas işlemler için erişimi kısıtlama OpenZeppelin AccessControl
Yükseltilebilirliği dikkatle uygula Sağlam yönetişim kontrolleriyle proxy kalıpları kullan OpenZeppelin Upgrades, Transparent Proxy
Kod dokümantasyon ve inceleme Açık yorum ve eşler arası kod incelemeleri İç denetimler + dış güvenlik incelemeleri

Solidity en iyi uygulama örneği: dış çağrılardan önce durum sıfırlama

mapping(address => uint256) public balances;

function safeWithdraw(uint256 amount) external {
    require(balances[msg.sender] >= amount, "Insufficient balance");
    balances[msg.sender] = 0; // Tekrar giriş riskini azaltmak için bakiye sıfırlanır
    (bool sent, ) = msg.sender.call{value: amount}("");
    require(sent, "Failed to send Ether");
}

Son denetimlerde tespit edilen yaygın tekrar giriş ve izin açıkları nelerdir?

Soken’in son denetimleri, özellikle eski yield farming ve staking sözleşmelerinde uygun işlem sıralaması ve/veya ReentrancyGuard eksikliği nedeniyle tekrar giriş açıkları olduğunu ortaya koydu. İzin hataları arasında multisig olmayan sabit admin anahtarları, admin vazgeçiş fonksiyonlarının bulunmaması ve herkes tarafından sınırsız dış çağrılar yer almakta, bu da kontrollerin ele geçirilmesine yol açmaktadır.

2025’te yapılan kritik bir denetimde, bir DeFi protokolünün kilitlenme olmaması nedeniyle kamufle edilmiş bir dış sözleşmeye ödül çekme fonksiyonunu defalarca çağırma izni verdiği ve yaklaşık 45 milyon dolar değerinde varlık riskine maruz kaldığı belirlendi. Ayrıca, RBAC konfigürasyonlarındaki hataların, setter fonksiyonlarındaki rol kısıtlaması eksikliğiyle birleşince, yetki yükseltme riskini artırdığı gözlemlendi.

Yaygın açıkların özeti:

Açık Türü Açıklama Temel Neden Etki
Tekrar giriş Durum güncellemeden önce dış çağrı yapılması Yanlış çağrı sıralaması veya mutex eksikliği Beklenmedik fonların boşaltılması
Aritmetik taşma Kontrol edilmeyen uint toplama veya çıkarma Solidity 0.8+ denetimlerinin kapatılması Token basımı veya transferlerde hata
Yanlış erişim kontrolü Fonksiyonların herkese açık olması veya admin anahtar riski RBAC veya multisig olmaması Yetkisiz fon para veya parametre değişiklikleri
Sabit anahtarlar Gömülü özel/admin anahtarlar Güvenli olmayan anahtar yönetimi Admin ele geçirilmesi veya anahtar sızıntısı

Akıllı sözleşme denetim araçları ve teknikleri karşılaştırması

Modern denetimler otomatik statik analiz, sembolik yürütme ve manuel kod incelemeyi birleştirir; bu sayede hem genel hem de bağlama özgü hatalar tespit edilir. Statik analiz araçları (Slither, Mythril) hızlıca genel desenler bulurken mantık hatalarını kaçırabilir. Sembolik yürütme (Echidna, Manticore) girdi varyasyonlarını stres testine tabi tutar. Manuel denetimler ise mimari güvenliği ve kod mantığını derinlemesine teyit eder.

Araç Türü Örnek Güçlü Yanları Sınırlamaları
Statik Analiz Slither Hızlı, tekrar giriş ve tam sayı hatalarını bulur Yanlış pozitif, karmaşık mantığı kaçırabilir
Sembolik Yürütme Echidna Girdi senaryoları üretir, uç durum hatalarını yakalar Hesaplama maliyeti, karmaşıklık
Manuel Denetim İnsan Derin mantık analizi, kapsamlı değerlendirme Zaman alıcı, uzman bağımlı

Soken, bu hibrit yaklaşımı benimseyerek otomasyonla bariz hataları elemeye ve uzman denetçilerle protokol bağlamına özgü yeni saldırı vektörlerini incelemeye odaklanır.

Uzman tavsiyesi: CI/CD hattınıza sürekli otomatik test araçları entegre edin ve sözleşmenizin karmaşıklığı ve risk profiline uygun düzenli profesyonel denetimleri ihmal etmeyin.


Akıllı sözleşme güvenliği hızla evriliyor, ancak tekrar giriş, aritmetik taşma ve hatalı erişim kontrolü gibi zafiyetler 2026’da bile devam ediyor. Güvenlik tasarımı ve titiz denetim yapılmayan sözleşmeler, birçok yüksek profilli olayda görüldüğü üzere yıkıcı kayıplara yol açar.

Bu makaledeki analiz, güvenli kodlama (örneğin dış çağrılardan önce durum değişikliği), yerleşik dil güvenliği (Solidity 0.8+ denetimli aritmetik) ve sağlam izin modellerinin (RBAC veya multisig) önemini ortaya koymaktadır. Ayrıca, otomatik statik kontrolleri ve deneyimli insan analizlerini harmanlayan çok katmanlı denetim yöntemleri, ortaya çıkan saldırılara karşı en iyi savunmayı sağlar. Akıllı sözleşmelerin güvenli geliştirilmesine bütüncül yaklaşım, finansal ve itibari zararları önemli ölçüde azaltır.

Projeler sözleşmelerini yayınlamaya hazırlanırken veya eski sistemlerini yükseltirken, sağlam izin modellerinin tekrar giriş korumalarıyla birlikte doğrulanması kritik önemdedir. Bir sonraki adım olarak, kapsamlı izin ve tekrar giriş denetimleri yapılması gerekir. Soken’in akıllı sözleşme denetim ve penetrasyon test hizmetleri bu uzman doğrulamayı sağlar ve protokolünüzün varlık akışlarını korumaya yönelik tamamlayıcı DeFi güvenlik incelemeleri destek sunar. Ayrıca, gelişmekte olan düzenleyici uyum bağlamları için Crypto Map ve resmi denetimlerden önce zayıf noktaları tespit eden ücretsiz ön Security X-Ray servisimizi mutlaka kullanın.


Ana mesaj: Kritik akıllı sözleşme açıklarına karşı en etkili koruma, Solidity’nin denetimli aritmetiğini ve ReentrancyGuard desenini benimsemek, detaylı ve çok imzalı erişim kontrol modelleri uygulamak ve bunları otomatik araçlarla uzman insan denetimlerini harmanlayan kapsamlı hibrit denetimlerle desteklemektir.

Article author

Sıkça Sorulan Sorular

Smart contract reentrancy nedir ve neden tehlikelidir?

Smart contract reentrancy, bir kontratın durum değişikliklerini tamamlamadan önce başka bir harici kontratı çağırmasıdır. Bu durum, saldırganların kontratı tekrar tekrar kullanarak fon çekmesine veya mantığı değiştirmesine yol açabilir ve ciddi finansal kayıplara neden olabilir.

Aritmetik overflow smart contractları nasıl etkiler?

Aritmetik overflow, hesaplamaların veri tipinin tutabileceği maksimum değeri aşması sonucu beklenmedik wrap-around sonuçlar doğurur. Bu durum kontrat mantığını bozabilir, saldırganların bakiyeleri manipüle etmesine veya kontrolleri atlatmasına olanak tanır.

Smart contractlarda erişim kontrolü için en iyi uygulamalar nelerdir?

İyi tanımlanmış izin rollerinin kullanılması, rol tabanlı erişim kontrolü (RBAC) veya çoklu imza şemalarının uygulanması ve yetkisiz işlemleri önlemek için izinlerin düzenli denetlenmesi en iyi uygulamalardır.

Smart contract denetimi güvenliği nasıl artırır?

Denetim, reentrancy, overflow ve izin açıkları gibi güvenlik zaaflarını dağıtımdan önce tespit eder. Manuel inceleme ve otomatik araçlarla kodun sağlamlığını garantileyerek, sömürü riskini azaltır.

Güvenli smart contract geliştirme için hangi araçlar önerilir?

Slither, MythX gibi statik analiz araçları ve formel doğrulama araçları önerilir. Bunların kapsamlı manuel denetimlerle kombine edilmesi, geliştiricilerin güvenlik sorunlarını erken aşamada tespit edip düzeltmesini sağlar.

Sohbet