Ücret hesaplamalarında yuvarlama hatalarını bulmanın yöntemleri

Tamsayı Taşması ve Alt Taşması Tespiti



Tekrar girişli saldırılar, akıllı sözleşme geliştiricilerinin sıklıkla gözden kaçırdığı tehlikeli açıklardan biridir. Dış çağrı yapılmadan önce bakiye güncellemesinin gerçekleştirilmemesi durumunda, saldırgan akıllı kontrat aracılığıyla işleve tekrar girebilir. Kod incelemesi bu deseni otomatik olarak işaretleyebilir. Önce kontrol sonra etkileşim örüntüsü, bu riski büyük ölçüde azaltır. Reentrancy'ye karşı mutex mekanizmaları da etkili bir güvence sağlar. Güvenlik uzmanları, dış çağrıda kontrolü kimin elinde tuttuğunu dikkatle incelemelidir. Test ortamında kötü niyetli bir kontrat yazarak saldırıyı sınamak da öğretici olur. Dinamik analiz ile birlikte kullanıldığında tespit oranı belirgin şekilde yükselir. Özellikle fon çekimi içeren işlevler öncelikli kontrol edilmelidir. Proje ekibi ayrıca her güncellemeden sonra tekrar testlerini çalıştırmalıdır. Böylece, yeniden giriş koruma stratejisinin temel bir bileşenidir.


Tamsayı taşması, aritmetik işlemlerin değer sınırını aşması sonucu öngörülmeyen değerler doğması anlamına gelir. Yeni Solidity ve üzeri otomatik olarak sayısal denetim yapar, yine de eski sürümlerde bu koruma mevcut değildir. Underflow özellikle bakiye düşürme işlemlerinde sık sık ortaya çıkar. Statik analiz araçları bu nitelikteki hesaplamaları belirleyebilir. Denetçi, hesaplama işlemlerin sınır değerlerle nasıl davrandığını değerlendirmelidir. Unchecked blokların uygulanması bilhassa titizlikle denetlenmelidir. SafeMath modülleri önceki projelerde yine tercih edilen bir yöntemdir. Rastgele test araçları uç noktaları kendiliğinden araştırmaya yardımcı olur. Veri tipi çevrimleri de öngörülmemiş taşmalara sebep olabilir. Ufak bir yanlış, büyük ekonomik zararlara yol açabilir. Bu nedenle, tüm hesaplama net biçimde gözden geçirilmelidir. Özetle olarak, sayısal sınır denetimi her projenin gündeminden biri olmalıdır.


Yetkilendirme zafiyetleri, hangi kullanıcının hangi fonksiyonu çalıştırabileceğini belirleyen mantığın eksik kurgulanmasından kaynaklanır. Kod incelemesi, değiştirici kullanımını kontrol ederek boş bırakılmış yetkileri bulabilir. Herkese açık işlevler bilhassa özenle incelenmelidir. Sahip hesabının ayrıcalıkları net olarak sınırlandırılmalıdır. Yalnızca bir anahtarın elindeki yetkiler, merkezi tehditler oluşturabilir. Rol bazlı kontrol modelleri çok daha sağlam bir çözüm sunar. Başlatma işlevlerinin tek seferlik bir kez çağrılabilmesi gerekir. Proxy yapılarda storage karışıklıkları ek olarak kontrol gerekir. Test senaryolarında yetkisi olmayan kullanıcı senaryoları sınanmalıdır. Böylece, yetki eksiklikleri daha baştan dönemde düzeltilebilir.


Oracle manipülasyonu, akıllı sözleşmelerin zincir dışından okuduğu fiyat bilgilerinin kötü niyetle saptırılmasıdır. Sığ likiditeye bağlı piyasalarda küçük bir transfer kuru büyük miktarda kaydırabilir. Güncel fiyat okumaları bu tür saldırılara elverişlidir. Süreye göre ortalama fiyatlar bu tehlikeyi büyük yüzdede düşürür. Çoklu veri kaynağının kombinasyonu tek nokta başarısızlığını önleyebilir. Değer tazeliği denetim sağlanmalı, süresi geçmiş değerlerle karar gerçekleştirilmemelidir. Anlık borç saldırıları aynı işlemde dev kaynak yardımıyla fiyatı geçici olarak değiştirir. Tehlikeler kurgu bazlı incelemelerle belirlenmelidir. Bu bağlamda, veri kaynağı mimarisi güvenlik değerlendirmesinin merkezinde bulunmalıdır.


Kontratlar arası işlem silsileleri, bir uygulamanın diğer bir sözleşmeyi çağırması sonucunda oluşan karmaşık bağlantılardır. Bu ağlarda bir kısımdaki hata, tüm sistemi tehlikeye atabilir. Çağrı grafiği çıkarılarak hangi işlevlerin hangi sözleşmeleri çağırdığı açık olarak izlenebilir. Vekil çağrı yazımı bilhassa tehlikeli bir unsurdur. Harici sözleşmenin güven derecesi sorgulanmadan etkileşime girilmemelidir. Uygulama bağlılıkları belirlendiğinde zincirin savunmasız bölümleri kolayca fark edilir. Yetki devirleri zincir boyunca titizlikle denetlenmelidir. Analistler, çağrı anında değişen bakiyeyi ayrıntılı takip etmelidir. Bütün bu aşamalar birlikte ele alındığında, sağlam bir sistem ortaya çıkar.


Blokzincir tabanlı yazılımların güvenliğinde gaz tüketimi kaynaklı hizmet reddi açıkları çoğu zaman gözden kaçar. Toplu işlemler içinde sınırsız depolama okumaları yapıldığında işlem maliyeti beklenmedik biçimde artar. Dışarıdan müdahale eden taraf bu durumu sistematik şekilde tetikleyebilir. Denetçinin ilk adımı, her döngünün üst sınırını açıkça belirlemektir. Dizi büyüklüğüne bağlı işlemler özellikle incelenmelidir. Bir kullanıcının üye sayısını artırarak diğer kullanıcıların işlemlerini engellemesi mümkün olabilir. Statik analiz araçları bu kalıpları çoğu zaman işaretler. Fakat araç çıktısı tek başına yeterli sayılmamalıdır. Test ağında yük senaryoları çalıştırmak, gerçek maliyeti ölçülebilir hale getirir. Gaz limitine sınırda işlemler, sözleşmenin erişilebilirliğini doğrudan etkiler. Geliştiriciler bu riski erken aşamada değerlendirmelidir. Sonuç olarak, gaz tüketimi temelli bir inceleme, hizmet reddi açıklarını önemli ölçüde azaltır.


Tx.origin kullanımına dayalı yetkilendirme, blokzincir uygulaması geliştirmede en eski güvenlik sorunlarından biridir. Bu değer, işlemi imzalayan dış hesabı gösterir ve ara sözleşmeler aracılığıyla geçse bile aynı kalır. Zararlı bir sözleşme, kullanıcıyı tuzağa düşürerek bir işlem imzalatabilir. Bu işlem içinde hedef sözleşmeye yönelik yetkili bir çağrı saklanabilir. Güvenlik incelemesi sırasında bu kalıbın tespit edilmesi gerekir. Yetki doğrulaması için çağıran adres kullanmak genellikle daha güvenlidir. Geliştirici ekipleri bu farkı açık biçimde kavramalıdır. Önceki kod tabanlarında yapılan yanlış kullanımlar sık görülür. Tarama sırasında yetkilendirme mantığı tek tek doğrulanmalıdır. Birim testleri ara sözleşme senaryolarını da kapsamalıdır. Böylece bu değer tabanlı sorunlar erken fark.


Akıllı sözleşme ortamında rastgelelik üretimi, yapısı itibarıyla zorlu bir problemdir. Zincir deterministik olduğundan, işlem özellikleri gibi değerler öngörülebilir olabilir. Saldırgan bu değerleri kullanarak sonucu baştan hesaplayabilir. Çekiliş sözleşmelerinde bu durum ciddi kayıplara yol açar. Güvenlik mühendisi öncelikle rastgelelik kaynağını tanımlamalıdır. Zaman damgası gibi girdiler doğrudan kullanılıyorsa tehlike yüksektir. Harici orakül kullanımı çoğu zaman daha sağlamdır. Commit-reveal şemalar da alternatif olarak değerlendirilebilir. Simülasyon sırasında sonuçların tekrar oranı incelenmelidir. Kestirilebilirlik tespiti tasarım aşamasında yapıldığında maliyet düşer. Böylece rastgele sonuçların adilliği korunur.


Yükseltilebilir proxy desenleri, sözleşme mantığını verileri kaybetmeden güncelleme imkânı sunar. Fakat depolama düzeni uyumsuz olduğunda ciddi çakışmalar meydana gelebilir. Proxy sözleşmenin depolama alanı ile uygulama sözleşmenin alan düzeni tamamen farklıysa veriler karışır. Yeni sürümde değişken sırasının değiştirilmesi tipik olarak bu soruna yol açar. Güvenlik uzmanları depolama düzenini karşılaştırmalı olarak incelemelidir. Yükseltme öncesinde slot haritası oluşturulmalı. Gap değişkeni kullanımı gelecekteki değişikliklere kolaylık sağlar. Initializer fonksiyonlarının ikinci kez çağrılmasını kısıtlayan mekanizmalar da önemlidir. Dikkatli tasarım ile depolama çakışmaları büyük ölçüde önlenebilir.


Ön uç çalıştırma ve Maksimum çıkarılabilir değer saldırıları, merkezi olmayan finans ekosisteminde yaygın bir tehdit oluşturur. Sıralayıcılar işlemleri yeniden düzenleme gücüne sahip olduğundan, bekleyen işlemler sık sık manipüle edilebilir. Kötü niyetli aktör büyük bir alım işlemini tespit edip önüne geçer. Fiyat etkisi sağlayarak kullanıcıdan değer çıkarır. Kuşatma saldırıları bu yapının en sık görülen örneğidir. İnceleme sürecinde, fiyat sapma payı gibi parametreler dikkatle değerlendirilmelidir. Özel işlem havuzları gibi araçlar riski düşürebilir. Zaman kilidi tasarımları da etkili olabilir. Uygulama tasarımcıları MEV yüzeyini belgelemeli ve simülasyon yapmalıdır. Böylece kullanıcılar öngörülemeyen kayıplardan korunabilir.


Akıllı sözleşme açıklarının başlıca kavramları


Blokzincir üzerindeki kodlar merkeziyetsiz ağ üzerinde çalışan ve şartlar sağlandığında insan müdahalesi olmadan yürüyen programlardır. Açık yönetimi açısından bakıldığında bu kodların silinemez olması hem güçlü yan hem de risk anlamına gelir. Bu nedenle kod incelemesi sürecinin ilk adımı kodun yapısını tam olarak anlamaktır. Tekrar çağrı gibi bilinen zafiyetler, bakiye güncellemesi sırasının yanlış olmasından doğar. Yetkilendirme denetimleri eksik olduğunda ise yetkisiz kullanıcılar kritik fonksiyonları çağırabilir. Tespit çalışmalarında kod taraması ile uzman gözü birlikte kullanıldığında en sağlam sonuçlar elde edilir.


Akıllı sözleşme açıklarında tekrarlanan yapılan eksikler


Kod yazarları birçok kez benzer hataları farkında olmadan tekrarlar. Sayısal sınır aşımı hataları, eski Solidity sürümlerinde sık olsa da hâlâ fark edilmeyebilir. Blok bilgisi gibi sistem değerlerine aşırı karar vermek de blok üreticilerinin manipülasyonuna açık kapı bırakır. Girdi doğrulamasının yapılmaması ise öngörülmemiş durumların oluşmasına neden olur. Sınama kapsamının kısıtlı tutulması, gerçek ağ öncesinde açıkların yakalanmasını zorlaştırır. Bu grup hataların büyük kısmı ciddi bir audit süreciyle önlenebilir.


Uzman pratik yönergeler ile açıkları ayırt etme

Tecrübeli denetçiler genellikle kaynak dosyayı dışarıdan okumayı öğütler. Hangi dış çağrıdan sonra verinin ne şekilde değiştiğini sormak oldukça işe yarar yöntemdir. Erişim kontrolü yapılarının doğru kullanılıp kullanılmadığına göz atmak gerekir. Yerel ortamda saldırı senaryolarını canlandırmak hem güvenli hem de yol gösterici bir yaklaşımdır. Ortaya çıkan her kusurun önemi ve gerçekleşme ihtimali ayrı ayrı değerlendirilmelidir. Raporlama aşamasında net düzeltmeler sunmak sahiplerin işini belirgin biçimde kolaylaştırır.


Akıllı sözleşme denetiminde ücretlendirme ve finansman dağılımı


Harici bir audit hizmetinin maliyeti, sözleşmenin satır sayısına ve ekibin geçmişine göre önemli farklılıklar gösterebilir. Sade bir token sözleşmesi için uygun bir bütçe ayrılabilirken, Borç ve likidite protokoller için çok daha yüksek meblağlar söz konusu olabilir. Geliştirme aşamasında yapılan inceleme genellikle kapsamlı bir yaşanacak kayıp riskinden çok daha ucuz bir tercihtir. Tekrarlı denetimler, yükseltme yapıldığında ilave ödeme gerektirir. Kaynak planlanırken tek başına ilk denetim ücretini değil, sürekli izleme ve olay yanıtı giderlerini de hesaba katmak gerekir.


Denetim süreç planlaması ve zamansal faktörler


Denetim takvimi projenin geliştirme evresinde belirleyici bir rol oynar. Sözleşme tamamlanmadan önce yapılan ön incelemeler, temel sorunları erkenden ortaya çıkarır. Canlıya alma öncesinde yapılan kapsamlı denetim ise düzeltmesi zor hataların önüne geçmek için olmazsa olmazdır. Kripto piyasası hareketliliğinin yüksek olduğu dönemlerde saldırı girişimlerinin arttığı raporlanmaktadır. Düşük aktivite dönemlerinde uzmanların erişilebilirliği azalabileceğinden, plan dikkatlice oluşturulmalıdır.


Akıllı sözleşme açıkları konusunda en çok sorulan soru başlıkları

Blokzincir kodu açıklarını hiçbir zaman sıfırlamak ulaşılabilir mi sorusunun sonucu genellikle olumsuz olarak belirtilir. Kod taraması ile tehlikenin kayda değer şekilde azaltılabileceği, fakat sıfır risk vaadinin yanıltıcı olduğu belirtilebilir. Bug bounty uygulamaları de denetime ikinci katman olarak değerlendirilebilir. Yatırımcılar için en önemli tavsiye, bağımsız değerlendirmeleri kontrol etmek ve sadece tek bir raporla karar vermemek olarak öne çıkmaktadır.

Ücret hesaplamalarında yuvarlama hatalarını ile ilgili aciklayici bir icerik olmus, eline saglik.
Ücret hesaplamalarında yuvarlama hatalarını ile ilgili etkileyici bir dokuman olmus, eline saglik.
Cok sey ogrendim. Soylenmesi gereken her sey soylenmis.
Muthis bir emek var. Not aldim, referans olarak saklayacagim.
Bu seviyeyi korumani diliyorum.

Forumdan Konular