paint-brush
Akıllı Sözleşmelerdeki Öncü Güvenlik Açığı Nasıl Çözülür?ile@dansierrasam79
1,832 okumalar
1,832 okumalar

Akıllı Sözleşmelerdeki Öncü Güvenlik Açığı Nasıl Çözülür?

ile Daniel Chakraborty6m2023/03/04
Read on Terminal Reader
Read this story w/o Javascript

Çok uzun; Okumak

Önden çalıştırma hatası, daha yüksek gas ücreti ödeyen işlemlerin, ödemeyen işlemlere göre daha fazla tercih edilme eğiliminde olması durumunda ortaya çıkar. Güvenlik açığı hatalı programlama nedeniyle ortaya çıkmıyor ancak işlemlerin sıralanma ve bir bloğa eklenme şeklinden yararlanılıyor. Bir saldırgan, daha yüksek gas ücreti ödeyerek açık artırmalar, ticaret veya ilk para teklifleri gibi olayların sonucunu kendi lehine değiştirebilir.
featured image - Akıllı Sözleşmelerdeki Öncü Güvenlik Açığı Nasıl Çözülür?
Daniel Chakraborty HackerNoon profile picture
0-item
1-item

Süpermarketteki veya elektrik faturalarınızı ödediğiniz satış noktalarındaki kuyruklar tarih olsa bile, bazılarımız sıraya atlayan birinin nasıl bir his olduğunu bilir.


Yani kuyruğun ön tarafına. Özellikle de faturalarının, sırada bekleyen diğerlerine kıyasla çok daha değerli olması nedeniyle. Açıkçası, hizmetin hızlılığı söz konusu olduğunda bu bir kriter olmamalıdır.


Artık bu sıranın en önüne geçme işi Ethereum akıllı sözleşmelerinde de yaşanıyor. Adını borsadaki benzer bir olgudan alan, önden koşma hatası olarak da bilinen, daha yüksek gaz ücreti ödeyen akıllı sözleşme işlemleri, ödemeyenlere göre daha fazla tercih edilme eğilimindedir.

Önden Çalışan Güvenlik Açığının Giderilmesi

Bu güvenlik açığı, başlangıçta hatalı programlamadan kaynaklanmıyor, işlemlerin sıralanma ve 'bellek havuzundan' bir bloğa eklenme şeklinden yararlanıyor.


Hızlı para kazanmak isteyen sıradan kullanıcıların yanı sıra, madenciler bu tür bir işlemden kazanma eğilimindedir ve bu nedenle, bir bloğa eklenmeden önce bu tür işlemleri izleme olasılıkları en yüksek olanlar da onlardır. Aslında bunu yaptıklarında, haksız bir mali ödül için kendilerine ait bir işlem gönderirler ve bu, ilk gönderilen blok yerine bir bloğa eklenmesiyle sonuçlanır.


Burada akılda tutulması gereken şey, daha yüksek gas fiyatıyla gerçekleştirilen işlemlerin diğerlerine kıyasla daha önce işlenme eğiliminde olduğudur. Saldırgan, bu tercihi akılda tutarak, daha yüksek gas ücretleri ödeyerek müzayedeler, ticaret veya ilk para teklifleri gibi olayların sonucunu kendi lehine değiştirebilir.


Önden çalışan güvenlik açığının nasıl çalıştığını anlamak için bu yaygın örneğe bakalım:

Bu örnekte üç oyuncumuz var: Naman, Kaavya ve Aishwarya. Naman ilk önce Hashing sorununu diğer ikisinin çözmesi için akıllı bir sözleşme olarak kullanıyor. Bu karma bulmacayı kim çözerse ödül olarak 10 eter elde edilecek.


Artık Kaavya hash çözümünü ilk önce buluyor ve kendi akıllı kontratından gas ücreti olarak 10 Gwei ile gönderiyor:


Öte yandan Aishwarya cevabı biraz sonra buluyor ve 100 Gwei'lik benzin ücreti ile akıllı sözleşmesine doğru cevabı aktarıyor.


Daha yüksek gas ücretleri ödediği için Kaavya'nın 10 Ether ödülü yerine Aishwarya ödülü aşağıda gösterildiği gibi alıyor:


Basitçe söylemek gerekirse, işlemleri gas ücretinin değerine göre işlediği için bu, ön çalıştırma veya işlem siparişi hatasıdır.


Başka bir deyişle, Kaavya cevabını Aishwarya'dan önce sunsa bile aşağıda gösterildiği gibi çabalarının karşılığında hiçbir şey alamaz:

Aishwarya'nın bu 'sıraya atlaması' Kaavya ya da başkası için pek hoş karşılanmayacağından, akıllı sözleşme kurallarımız için birkaç önleyici tedbirin dikkate alınması gerekiyor.

Öncü Güvenlik Açığıyla Başa Çıkmanın 3 Yolu

Artık böyle bir kaybı önleyebilecek düzeltmeler var. Başka bir deyişle, bir işlemi 10 Ether alması gereken işlem olarak kilitleyebilmemiz gerekir.


Yöntem 1: İşlem Sayacı

İşlem sayacını kullanmak, başkalarının ödülü başka yollarla almasını engellemenin en basit yollarından biridir.


Aşağıda eklenen koddan da anlaşılacağı üzere hashing challange'ını ilk tamamlayan kişinin gerçekleştirdiği işlemi kilitleyen bir işlem sayacı eklenmiştir. Ödülü yalnızca ilk yapanın alması gerektiğinden, tüm katılımcılara çözümlerinin yanına 0 değerini eklemelerini bildiriyoruz.


İlk sunulan çözüm için txCounter'ın mevcut değeri sıfır olacağından kilitleniyor. Yani yukarıdaki örnekte olduğu gibi Kaavya, 10 Ether ödülünü almak için hem çözümüne hem de sıfır değerine girecek. .


Başkası bunu yaparsa işlem sayacı birden büyük bir değere artırıldığı için çözüm kabul edilmeyecektir. O zamana kadar Kaavya'ya gitmesi gereken 10 Ether ödülünün tamamı ona aktarılacak.


Yöntem 2: Gaz limitlerini ayarlama

Artık bu yöntemle tüm işlemler için bir gas limiti belirlemeye odaklanılıyor. Gerekirse hem alt hem de üst sınır.


Hatırlayacağınız gibi işlemler, söz konusu işlem için ne kadar gas ücreti ödendiğine göre sıralanıyor. Bu, bu sıralamayı tamamen ortadan kaldırmasa da, kesinlikle onu büyük ölçüde azaltır.


Aşağıdaki koda bakarsanız, gasThrottle değiştiricisi sayesinde 1 veya daha az gaz ödeyen tüm işlemler gerçekleşecek ancak daha fazla gaz ödeyerek sınırı atlamaya çalışanlar yapamayacaktır. Bu durumda, böyle bir işlemi gerçekleştirmenin standart maliyeti 1 Wei veya Gwei olabilir ve izin verilen tek şey budur.


Yani gazda bu kısıtlama sayesinde tüm işlemler bu kadar değişkenlik göstermiyorsa, belirli işlemlere tercih gösterme sorunu ortaya çıkmayacaktır. Böyle bir yaklaşımın avantajları olsa da ödenen gaz ücretinin gelecekte değişmesi kaçınılmazdır.


Bugün yüksek olan birkaç yıl içinde düşük olacak, dolayısıyla Naman'ın buna her zaman dikkat etmesi gerekiyor. Yoksa Aish bir süre bekleyerek değişen bu değerlerden faydalanabilir.


Yöntem 3: Denizaltı Gönderme Yaklaşımı

Önceki iki yaklaşım daha basit durumlar için işe yarasa da, önden çalışan güvenlik açığının temel nedenini asla ele almıyorlar: işlem bilgilerinin hem madencilere hem de diğer kötü niyetli kullanıcılara tam olarak ifşa edilmesi.


Bu iki tarafın her işlemin bilgisine erişimi olduğu sürece sistemle oynama şansının devam edeceği aşikardır. Açıkça, zamana duyarlı bu bilginin gizlenmesini sağlayacak bir yöntem gereklidir ve bu da bizi LibSubmarine akıllı sözleşme kütüphanesinin bir parçası olarak uygulanan denizaltı gönderme yaklaşımına getirir.


Bu yaklaşım kullanıldığında, işlem bilgileri madencilerin veya sıradan kullanıcıların gerçekten yararlanamayacağı şekilde gizlenir. Şifreleme, sahibinin takdirine bağlı olarak bir bloğa eklendiğinde açığa çıkabilen bu bilgilerin korunmasında büyük bir rol oynar.

Bununla birlikte, bu yaklaşım mükemmel olmasa bile sunduğu koruma düzeyi, diğer yöntemlere kıyasla çok daha iyidir, çünkü hem gerçek dünyada hem de önden koşmanın gerçek nedenini ele alma istekliliği vardır. Blockchain üzerinde.

Öncü Savunmasızlığı Önlemeye Yönelik Diğer Stratejiler

Elbette akıllı sözleşmeleri 'önden çalışan' güvenlik açığından koruyan stratejiler yalnızca önceki bölümde tartışılan stratejiler değildir.


Yan zincirlerde, yerleşim zincir üzerinde yapılırken sıralama zincir dışında gerçekleşir. Bu iki adımın farklı platformlarda gerçekleşmesi, yalnızca artan verim sağlamakla kalmayacak, aynı zamanda madencileri veya düzenli kullanıcıları öndeki güvenlik açığından yararlanmak için gerekli bilgileri elde etmekten caydıracaktır.




Doğası gereği teorik olsa bile başka bir strateji, bir taahhüt-açıklama şemasında gerçekleştirilen belirli bir tur için işlemlerin sırasının rastgele hale getirilmesini içerir. Bu, akıllı sözleşme mantığı kullanılarak uygulanır. Sıralama yukarıda bahsedilen akıllı sözleşmeye göre belirlendiğinden, ön sıralarda yer alanlar bu yaklaşımla ön sıralara çıkamayacaklar.


Son olarak, başka bir yaklaşım, kullanıcıların siparişi kimin alacağını belirleyen çok önemli t değeri için doğrulanabilir gecikme işlevlerini çözdüğü Enjeksiyon Protokolünün uygulanmasını içerir. Sonuç olarak, çoğu blockchain'in kullandığı rastgele sıralama sisteminden uzaklaşabilmek, ön saldırıların olasılığını da azaltıyor.