blog 1HaberlerGeliştiricilerEnterpriseBlockchain AçıklamasıEtkinlikler ve KonferanslarBasınBültenler

Haber bültenimize abone ol.

E

Senin gizliliğine saygı duyuyoruz

AnasayfaBlogBlockchain Geliştirme

Ethereum Akıllı Sözleşme Güvenlik Önerileri

Harici çağrıların nasıl ele alınacağından taahhüt şemalarına kadar, Ethereum üzerinde geliştirme yaparken takip etmeniz gereken 10’dan fazla akıllı sözleşme güvenlik modeli. By ConsenSysTemmuz 10, 2020Yayınlandı 10 Temmuz 2020

Ethereum Akıllı Sözleşme Güvenlik Önerileri


Akıllı Sözleşme Güvenlik Zihniyetinde ele aldığımız gibi, uyanık bir Ethereum geliştiricisi her zaman beş ilkeyi akılda tutar:

  • Başarısızlığa hazırlanın
  • Dikkatlice sunun
  • Sözleşmeleri basit tutun
  • Güncel kal
  • EVM’nin kendine has özelliklerinin farkında olun

Bu yazıda, EVM’nin özelliklerini inceleyeceğiz ve Ethereum’da herhangi bir akıllı sözleşme sistemi geliştirirken izlemeniz gereken kalıpların bir listesini inceleyeceğiz. Bu parça öncelikle orta düzey Ethereum geliştiricileri içindir. Hâlâ keşfin ilk aşamalarındaysanız, ConsenSys Academy’nin isteğe bağlı blockchain geliştirici programına göz atın. 

Tamam, içeri girelim.

Harici aramalar

Harici görüşmeler yaparken dikkatli olun

Güvenilmeyen akıllı sözleşmelere yapılan çağrılar, birkaç beklenmedik risk veya hata ortaya çıkarabilir. Harici aramalar, söz konusu sözleşmede veya bağlı olduğu başka herhangi bir sözleşmede kötü amaçlı kod çalıştırabilir. Bu nedenle, her harici aramayı potansiyel bir güvenlik riski olarak değerlendirin. Harici aramaların kaldırılması mümkün olmadığında veya istenmediğinde, tehlikeyi en aza indirmek için bu bölümün geri kalanındaki önerileri kullanın..

Güvenilmeyen sözleşmeleri işaretle

Dış sözleşmelerle etkileşim kurarken değişkenlerinizi, yöntemlerinizi ve sözleşme arabirimlerinizi, onlarla etkileşimin potansiyel olarak güvenli olmadığını açıkça gösterecek şekilde adlandırın. Bu, harici sözleşmeleri çağıran kendi işlevleriniz için geçerlidir.

// kötü Bank.withdraw (100); // Güvenilir mi yoksa güvenilmeyen bir işlev mi olduğu belli değil makeWithdrawal (uint miktarı) {// Bu işlevin potansiyel olarak güvensiz olduğu açık değil Bank.withdraw (amount); } // iyi UntrustedBank.withdraw (100); // güvenilmeyen harici çağrı TrustedBank.withdraw (100); // XYZ Corp işlevi tarafından sürdürülen harici ancak güvenilir banka sözleşmesi makeUntrustedWithdrawal (uint miktarı) {UntrustedBank.withdraw (amount); } Kod dili: PHP (php)

Harici görüşmelerden sonra durum değişikliklerinden kaçının

Ham çağrılar (someAddress.call () biçiminde) veya sözleşme çağrıları (ExternalContract.someMethod () biçiminde) kullanılıyor olsun, kötü amaçlı kodun yürütülebileceğini varsayın. ExternalContract kötü niyetli olmasa bile, kötü amaçlı kod, çağırdığı herhangi bir sözleşmeyle çalıştırılabilir..

Belirli bir tehlike, kötü amaçlı kodun kontrol akışını ele geçirerek yeniden giriş nedeniyle güvenlik açıklarına yol açabilmesidir. (Görmek Yeniden giriş bu sorunun daha kapsamlı bir tartışması için).

Güvenilmeyen bir harici sözleşmeye arama yapıyorsanız, aramadan sonra durum değişikliklerinden kaçının. Bu model aynı zamanda bazen kontroller-etkiler-etkileşim modeli.

Görmek SWC-107

Transfer () veya gönder () kullanmayın.

.transfer () ve.send () alıcıya tam olarak 2.300 gazı iletir. Bu sabit kodlu gaz maaşının amacı, yeniden giriş güvenlik açıkları, ancak bu yalnızca gaz maliyetlerinin sabit olduğu varsayımı altında mantıklıdır. EIP 1884, İstanbul hard forkunun bir parçası olan SLOAD operasyonunun gaz maliyetini artırdı. Bu, bir sözleşmenin geri dönüş işlevinin 2300 gaza mal olmasına neden oldu. .Transfer () ve.send () kullanmayı bırakıp bunun yerine use.call () kullanmanızı öneririz..

// kötü sözleşme Savunmasız {işlev geri çekme (uint256 miktarı) harici {// Bu, 2300 gazı iletir; bu, alıcı bir sözleşmeyse ve gaz maliyetleri değişirse bu yeterli olmayabilir. msg.sender.transfer (miktar); }} // iyi sözleşme Sabit {işlev geri çekme (uint256 miktarı) harici {// Bu, mevcut tüm gazı iletir. Dönüş değerini kontrol ettiğinizden emin olun! (bool başarısı,) = msg.sender.call.value (miktar) (""); gerektirir (başarı, "Transfer başarısız oldu."); }} Kod dili: JavaScript (javascript)

.Call () işlevinin yeniden giriş saldırılarını hafifletmek için hiçbir şey yapmadığını, bu nedenle diğer önlemlerin alınması gerektiğini unutmayın. Yeniden giriş saldırılarını önlemek için, kontroller-etkiler-etkileşim modeli.

Harici görüşmelerdeki hataları işleyin

Solidity, ham adreslerde çalışan düşük seviyeli çağrı yöntemleri sunar: address.call (), address.callcode (), address.delegatecall () ve address.send (). Bu düşük seviyeli yöntemler asla bir istisna oluşturmaz, ancak çağrı bir istisna ile karşılaşırsa yanlış döndürür. Öte yandan, sözleşme çağrıları (ör. ExternalContract.doSomething ()) otomatik olarak bir atma yayar (örneğin, ExternalContract.doSomething () doSomething () atarsa ​​da atar).

Düşük seviyeli arama yöntemlerini kullanmayı seçerseniz, dönüş değerini kontrol ederek aramanın başarısız olma olasılığını ele aldığınızdan emin olun..

// kötü birAdres.send (55); someAddress.call.value (55) (""); // kalan tüm gazı ileteceği ve sonucu bazıAddress.call.value (100) (bytes4 (sha3 ("Depozito()"))); // eğer para yatırma bir istisna atarsa, ham call () yalnızca yanlış döndürür ve işlem geri ALINMAZ // iyi (bool başarılı) = birAdres.call.value (55) (""); if (! success) {// hata kodunu işle} ExternalContract (someAddress) .deposit.value (100) (); Kod dili: JavaScript (javascript)

Görmek SWC-104

Harici aramalar için çekmeyi tercih edin

Harici aramalar yanlışlıkla veya kasıtlı olarak başarısız olabilir. Bu tür hataların neden olduğu hasarı en aza indirmek için, her harici aramayı, aramanın alıcısı tarafından başlatılabilen kendi işlemine ayırmak genellikle daha iyidir. Bu özellikle, kullanıcıların otomatik olarak para yatırmak yerine para çekmelerine izin vermenin daha iyi olduğu ödemeler için geçerlidir. (Bu aynı zamanda şansı da azaltır gaz limiti ile ilgili sorunlar.) Tek bir işlemde birden çok eter transferini birleştirmekten kaçının.

// hatalı sözleşme açık artırması {address HighBidder; uint highBid; işlev teklifi () ödenebilir {require (msg.value >= en yüksek Teklif); eğer (en yüksek Teklif! = adres (0)) {(bool başarısı,) = en yüksekBidder.call.value (en yüksek Teklif) (""); gerektirir (başarı); // bu çağrı sürekli olarak başarısız olursa, başka hiç kimse teklif veremez} HighBidder = msg.sender; highBid = msg.value; }} // iyi bir sözleşme açık artırması {address HighBidder; uint highBid; eşleme (adres => uint) geri ödemeler; function bid () ödenebilir harici {require (msg.value >= en yüksek Teklif); eğer (en yüksek Teklif! = adres (0)) {geri ödeme [en yüksekBidder] + = en yüksekBid; // bu kullanıcının talep edebileceği geri ödemeyi kaydedin} HighBidder = msg.sender; highBid = msg.value; } fonksiyon withdrawRefund () harici {uint iade = para iadeleri [msg.sender]; geri ödemeler [msg.sender] = 0; (bool başarısı,) = msg.sender.call.value (geri ödeme) (""); gerektirir (başarı); }} Kod dili: JavaScript (javascript)

Görmek SWC-128

Güvenilmeyen koda çağrı yetkisi vermeyin

Delegatecall işlevi, diğer sözleşmelerdeki işlevleri, arayan sözleşmesine aitmiş gibi çağırır. Böylece, aranan uç, arayan adresin durumunu değiştirebilir. Bu güvensiz olabilir. Aşağıdaki bir örnek, delegatecall kullanımının sözleşmenin bozulmasına ve bakiyesinin kaybına nasıl yol açabileceğini göstermektedir..

sözleşme Yıkıcı {function doWork () harici {selfdestruct (0); }} sözleşme İşçisi {function doWork (adres _internalWorker) public {// güvensiz _internalWorker.delegatecall (bytes4 (keccak256 ("işi yapmak()"))); }} Kod dili: JavaScript (javascript)

Worker.doWork (), argüman olarak konuşlandırılan Destructor sözleşmesinin adresiyle çağrılırsa, İşçi sözleşmesi kendi kendini yok eder. Yürütmeyi yalnızca güvenilir sözleşmelere devredin ve asla kullanıcı tarafından sağlanan adrese gitme.

Uyarı

Sözleşmelerin sıfır bakiye ile oluşturulduğunu varsaymayın. Saldırgan, sözleşmenin oluşturulmadan önce adresine ether gönderebilir. Sözleşmeler, başlangıç ​​durumunun sıfır bakiye içerdiğini varsaymamalıdır. Görmek sorun 61 daha fazla ayrıntı için.

Görmek SWC-112

Eterin zorla bir hesaba gönderilebileceğini unutmayın

Bir sözleşmenin dengesini sıkı bir şekilde kontrol eden bir değişmezi kodlamaya dikkat edin.

Bir saldırgan, herhangi bir hesaba zorla ether gönderebilir. Bu önlenemez (geri dönüş yapan bir geri dönüş işlevi ile bile ()).

Saldırgan bunu bir sözleşme oluşturarak, bunu 1 wei ile finanse ederek ve kendi kendini yok etme (victimAddress) çağırarak yapabilir. VictimAddress’de hiçbir kod çağrılmaz, bu nedenle engellenemez. Bu aynı zamanda madencinin adresine gönderilen herhangi bir rastgele adres olabilen blok ödülü için de geçerlidir..

Ayrıca, sözleşme adresleri önceden hesaplanabildiğinden, sözleşme dağıtılmadan önce ether bir adrese gönderilebilir..

Görmek SWC-132

Zincir üzerindeki verilerin herkese açık olduğunu unutmayın

Birçok uygulama, çalışmak için gönderilen verilerin belirli bir zamana kadar gizli olmasını gerektirir. Oyunlar (ör. Zincir üzerinde taş-kağıt-makas) ve açık artırma mekanizmaları (ör. Kapalı teklif Vickrey müzayedeleri) iki ana örnek kategorisidir. Gizliliğin sorun olduğu bir uygulama oluşturuyorsanız, kullanıcılardan bilgileri çok erken yayınlamalarını istemediğinizden emin olun. En iyi strateji kullanmaktır taahhüt şemaları ayrı aşamalarla: önce değerlerin karmasını kullanarak kesin ve daha sonraki bir aşamada değerleri açığa çıkarın.

Örnekler:

  • Taş kağıt makaslarda, her iki oyuncunun da önce amaçladıkları hareketin bir karmasını göndermelerini, ardından her iki oyuncunun da hamlelerini göndermelerini isteyin; Gönderilen hamle uyuşmuyorsa hash atın.
  • Bir müzayedede, oyuncuların ilk aşamada (teklif değerlerinden daha büyük bir depozito ile birlikte) teklif değerlerinin bir karmasını göndermelerini ve ardından ikinci aşamada açık artırma teklif değerlerini göndermelerini isteyin.
  • Rastgele sayı üretecine dayanan bir uygulama geliştirirken, sıra her zaman (1) oyuncular hamle göndermelidir, (2) rastgele sayı üretilmeli, (3) oyunculara ödeme yapılmalıdır. Birçok kişi aktif olarak rastgele sayı üreteçlerini araştırmaktadır; mevcut sınıfının en iyisi çözümler, Bitcoin blok başlıklarını içerir ( http://btcrelay.org), karma-işleme-gösterme şemaları (yani bir taraf bir sayı üretir, değere “işlemek” için karmasını yayınlar ve ardından değeri daha sonra açıklar) ve RANDAO. Ethereum deterministik bir protokol olduğundan, protokol içindeki herhangi bir değişkeni tahmin edilemeyen rastgele bir sayı olarak kullanamazsınız. Ayrıca madencilerin block.blockhash () değerinin bir dereceye kadar kontrolünde olduğunu unutmayın.*.

Bazı katılımcıların “çevrimdışı olabileceği” ve geri dönmeyebileceği olasılığına karşı dikkatli olun

Belirli bir tarafın belirli bir eylemi gerçekleştirmesine bağlı olarak para iadesi yapmayın veya başka bir yolla ödeme talep etmeyin. Örneğin, bir taş-kağıt-makas oyununda, yaygın bir hata, her iki oyuncu da hamlelerini sunana kadar ödeme yapmamaktır; ancak, kötü niyetli bir oyuncu, diğer oyuncunun hamlesini asla göndermeyerek “üzülmesine” neden olabilir – aslında, bir oyuncu diğer oyuncunun ortaya çıkan hamlesini görür ve kaybettiğini belirlerse, kendi hamlesini yapmak için hiçbir sebepleri yoktur. Bu sorun aynı zamanda devlet kanalı uzlaşması bağlamında da ortaya çıkabilir. Bu tür durumlar bir sorun olduğunda, (1) katılmayan katılımcıları, belki de bir zaman sınırı yoluyla atlatmanın bir yolunu sağlayın ve (2) katılımcıların, bulundukları tüm durumlarda bilgi sunmaları için ek bir ekonomik teşvik eklemeyi düşünün. öyle yapması gerekiyordu.

En negatif işaretli tam sayının olumsuzlamasına dikkat edin

Solidity, işaretli tamsayılarla çalışmak için çeşitli türler sağlar. Çoğu programlama dilinde olduğu gibi, Solidity’de N bitli işaretli bir tamsayı -2 ^ (N-1) ile 2 ^ (N-1) -1 arasındaki değerleri temsil edebilir. Bu, MIN_INT için pozitif bir eşdeğer olmadığı anlamına gelir. Olumsuzluk, bir sayının ikisinin tümlülüğünü bulmak olarak uygulanır, bu nedenle en olumsuz sayının olumsuzlanması aynı sayı ile sonuçlanacak. Bu, Solidity’deki tüm işaretli tam sayı türleri için geçerlidir (int8, int16,…, int256).

sözleşme Olumsuzlama {function negate8 (int8 _i) public pure return (int8) {return -_i; } işlev negate16 (int16 _i) public pure return (int16) {return -_i; } int8 public a = negate8 (-128); // -128 int16 genel b = negate16 (-128); // 128 int16 public c = negate16 (-32768); // -32768} Kod dili: PHP (php)

Bunu halletmenin bir yolu, olumsuzlamadan önce bir değişkenin değerini kontrol etmek ve MIN_INT’e eşitse fırlatmaktır. Diğer bir seçenek de, daha yüksek kapasiteli bir tür kullanarak en negatif sayıya asla ulaşılmayacağından emin olmaktır (örneğin, int16 yerine int32).

MIN_INT çarpıldığında veya -1 ile bölündüğünde int türleriyle ilgili benzer bir sorun ortaya çıkar.

Blockchain kodunuz güvenli mi? 

Umarız bu öneriler yardımcı olmuştur. Siz ve ekibiniz lansmana hazırlanıyorsanız veya hatta geliştirme yaşam döngüsünün başlangıcında ve akıllı sözleşmelerinizin sağlıklı bir şekilde kontrol edilmesini istiyorsanız, lütfen ConsenSys Diligence’daki güvenlik mühendisleri ekibimizle iletişime geçmekten çekinmeyin. Ethereum uygulamalarınızı% 100 güvenle başlatmanıza ve sürdürmenize yardımcı olmak için buradayız. 

Güvenlik Noktası Kontrolü Ayırtın

Blockchain güvenlik uzmanlarından oluşan ekibimizle 1 günlük bir inceleme yapın. Bugün Ayırtın SecuritySmart SözleşmeleriHaberi En son Ethereum haberleri, kurumsal çözümler, geliştirici kaynakları ve daha fazlası için haber bültenimize abone olun.Başarılı Bir Blockchain Ürünü Nasıl OluşturulurWeb semineri

Başarılı Bir Blockchain Ürünü Nasıl Oluşturulur

Ethereum Düğümü Nasıl Kurulur ve ÇalıştırılırWeb semineri

Ethereum Düğümü Nasıl Kurulur ve Çalıştırılır

Kendi Ethereum API'nizi Nasıl Oluşturabilirsiniz?Web semineri

Kendi Ethereum API’nizi Nasıl Oluşturabilirsiniz?

Sosyal Simge Nasıl OluşturulurWeb semineri

Sosyal Simge Nasıl Oluşturulur

Akıllı Sözleşme Geliştirmede Güvenlik Araçlarını KullanmaWeb semineri

Akıllı Sözleşme Geliştirmede Güvenlik Araçlarını Kullanma

Finansın Geleceği Dijital Varlıklar ve DeFiWeb semineri

Finansın Geleceği: Dijital Varlıklar ve DeFi

Mike Owergreen Administrator
Sorry! The Author has not filled his profile.
follow me