ChatGPT ile Kendi Kendini Denetleyen Akıllı Sözleşmeler

Akıllı sözleşmeleri denetlerken, kodun güvenli olduğundan emin olmak için çok çeşitli konuların ele alınması gerekir. Bu sorular erişim kontrolü, varlık yönetimi, veri yönetimi, varsayımlar, bağımlılıklar ve güvenlik kontrol listeleri gibi çeşitli hususları kapsamaktadır. Aşağıda, akıllı sözleşme denetim sürecinde size rehberlik edecek ChatGPT sorguları için ayrıntılı bir kontrol listesi ve talimatlar sunuyoruz.

Bir akıllı sözleşmeyi güvenlik açıkları ve gizli dolandırıcılık teknikleri açısından kendiniz araştırmak istiyorsanız, ilk adım doğru hazırlanmış bir ChatGPT istemidir.

ChatGPT için yararlı bir sorgu aşağıdaki komut olacaktır:

Aşağıdaki akıllı sözleşmedeki tüm sorunların ve güvenlik açıklarının kapsamlı bir listesini sağlayın. Sorunları ve olası güvenlik açıklarını ayrıntılı olarak açıklayın. Her güvenlik açığı için bir istismar senaryosu sağlayın. Her biri 'açıklama', 'eylem', 'önem derecesi', 'aktörler', 'senaryo', 'tür' ve 'satır' sütunlarına sahip nesnelerin bir listesini içeren markdown biçiminde geçerli bir tablo olarak çıktı alın. 'tip', 'kullanılabilirlik', 'güvenlik açığı', 'optimizasyon' veya 'öneri' olabilir. 'aktörler' ilgili aktörlerin bir listesidir. 'önem derecesi' 'düşük', 'orta' veya 'yüksek' olabilir. 'row' sorunun satır numarasıdır. Tablodaki tüm alanların doldurulduğundan emin olun.

Daha sonra akıllı sözleşmeyi daha derinlemesine keşfetmek için aşağıdaki soruları kullanın.

Kullanım Senaryoları:

1. Sistemdeki aktörler kimlerdir?


2. Sistem hangi eylemlere sahiptir?


3. Sistemin sınırlamaları nelerdir?


4. Sistemi kırmanın bazı potansiyel yolları nelerdir?


5. Saldırılara karşı koymak için hangi savunmalar kullanılır?


6. Kısıtlamalara dayanarak, her bir işlevin durum değişikliklerini açıklayın.


7. Kullanılan Solidity ve DeFi şablonları hakkında bilgi verin.


8. Sistem hakkındaki bilgilere dayanarak olumlu ve olumsuz aksiyomlar yazın.


9. Kodu daha güvenilir hale getirmek için optimize etmenin ve değiştirmenin yollarını listeleyin (kod parçacıklarıyla).


10. Kodda kullanılan gizli aldatmaca yöntemlerini listeleyin (kod parçacıklarıyla).

İpucu: Verilerin görsel temsili genellikle sistemin işleyişinin daha net anlaşılmasını sağlar. ChatGPT ile çalışırken, ASCII karakter diyagramları biçimindeki durum değişiklikleri gibi çıktı verilerinin görselleştirmelerini talep etmeniz önerilir. Tüm görselleştirmeler anlamlı olmasa da, bazıları akıllı bir sözleşmenin işleyişi hakkında çok değerli bilgiler sağlayabilir.

Aslında, ChatGPT bir insan denetçinin yerini alamazken, protokol durum geçişlerinin, kısıtlamaların, değişmezlerin ve uyumluluğun daha net bir şekilde anlaşılmasını sağlayarak denetim sürecini önemli ölçüde tamamlar. Bu araç özellikle protokol durum geçişlerini ve kısıtlamalarını anlamak için etkilidir.

İpucu: Bir denetime başlamadan önce, sohbet robotuna denetlenen protokolle ilgili belgeler sağlamak, yanıtların doğruluğunu ve alaka düzeyini büyük ölçüde artırabilir. "Bu, denetlediğim 'protokol_adı' için en iyi bağlamı sağlayan belgedir" demeniz ve belgeyi eklemeniz yeterlidir.

ChatGPT'nin denetçiler için güçlü bir yardımcı olduğu ve akıllı sözleşmeleri denetlemek için yapılandırılmış ve derinlemesine bir yaklaşım sağladığı söylenebilir. Bununla birlikte, ChatGTP'nin (ve benzer hizmetlerin) olasılıklarla çalışan makine analizinin karmaşık yorumlarından ibaret olduğu, bu nedenle genellikle hatalar ve yanlışlıklar ürettiği unutulmamalıdır. Buna göre, ChatGPT sonucuna tam olarak güvenilemez - yalnızca doğru ellerde iyi bir araç ve akıllı sözleşme araştırmalarında bir "başlangıç noktasıdır".

Bu nedenle, kendinizi olası risklerden korumak için akıllı sözleşmeler olası güvenlik açıkları ve dolandırıcılık planları açısından daha dikkatli incelenmelidir.

Derinlemesine bir akıllı sözleşme denetimi nasıl yapılır? ChatGPT'ye gelen en iyi 100 talep

Yukarıda ChatGPT'ye gelen ve bir akıllı sözleşmeyi analiz etmeye başlayabileceğiniz genel bir sorguyu (istem) ele aldık. Ancak, elbette, ayrıntılı analiz giriş istemiyle sınırlı değildir.

Dolandırıcılar sürekli olarak taktiklerini geliştiriyorlar, bu nedenle birçok açıdan bilgili ve dikkatli olmanız gerekiyor - bunlar token yatırımınızı korumak için temel stratejilerdir.

Akıllı bir sözleşme denetimine profesyonel bir yaklaşım sağlayacak en iyi 100 sorgu listesine bir göz atalım:

1. Kod başarıyla derleniyor mu?
2. Kodda hangi Solidity sürümü kullanılıyor? Bu, mevcut kararlı sürüm mü?
3. Fonksiyonların ve değişkenlerin amacını açıklayan açık yorumlar mevcut mu?
4. Sözleşme bir "Ownable" şeması kullanıyor mu? Eğer evet ise, hangi fonksiyonlar için?
5. Durum değişkenleri doğru bir şekilde görünürlük belirteçleri kullanılarak tahsis edilmiş mi?
6. Doğru loglama için olaylar kullanılıyor mu?
7. Kullanıcı dostu hata mesajları sağlanıyor mu?
8. Düşük seviyeli çağrıların dönüş değeri kontrol ediliyor mu?
9. Sahibin yetkilendirebileceği senaryolar var mı ve bu, rug-pull'a yol açabilir mi?
10. Ayrıcalıklı hesaplar üzerinde kim kontrol sahibi ve kontrol mekanizmaları nedir?
11. Sözleşmede hangi yönetim mekanizmaları mevcut ve yönetim tamamen açık mı yoksa sınırlı mı?
12. Sistemde başka sözleşmeler kullanılıyor mu ve hangi rolleri üstleniyorlar (örneğin, proxy sözleşmesi)?
13. Bir zaman kilitleme mekanizması var mı ve atlatılabilir mi?
14. Yeterli dokümantasyon mevcut mu?
15. Kodda DoS veya reentrancy saldırılarına karşı potansiyel güvenlik açıkları var mı?
16. Tüm fonksiyonlar, açıkça public/external olarak belirtilmesi gerekenler haricinde internal mı?
17. Matematik işlemlerinde aritmetik taşmalar/yetersizlikler yok mu?
18. Güvenli OpenZeppelin kütüphanesi kullanılıyor mu?
19. Ether veya tokenlar yanlışlıkla null adrese (0x0) gönderilemez mi?
20. İşlemler ve durum değişikliklerinden önce şartlar require ile kontrol ediliyor mu?
21. Durum, eylemlerin yürütülmesinden önce ve sırasında ayarlanıyor mu?
22. Reentry (yeniden giriş) saldırılarına karşı koruma kullanılıyor mu (A, B'yi çağırır, B, A'yı çağırır)?
23. ERC20 arayüzü düzgün şekilde uygulanmış mı?
24. Bir modifier birden fazla yerde sadece gerçekten gerekli olduğunda mı kullanılıyor?
25. Tüm türler açıkça tanımlanmış mı (örneğin, uint yerine uint256 kullanılıyor mu)?
26. Tüm yöntemler ve döngüler maksimum izin verilen gaz limitine uygun mu?
27. Yapıcıda gereksiz başlatmalar yok (varsayılan değerlerin ayarlandığını unutmayın)?
28. Eksiksiz test kapsamı var mı: her akıllı sözleşme yöntemi ve tüm olası giriş veri türleri test edildi mi?
29. Rastgele girdiler kullanılarak fuzz testi yapıldı mı?
30. Sözleşmenin olası tüm durumları test edildi mi?
31. Varsayılan ether ve token miktarları wei birimlerinde belirtilmiş mi?
32. Kalabalık satış bitiş bloğu/zamanı, başlangıç bloğu/zamanından sonra mı (başlangıç / ticaretin etkinleştirilmesi)?
33. Kalabalık satış tokenlerinin dönüşüm oranı doğru ayarlanmış mı?
34. Kalabalık satış için yumuşak/sert limit belirlenmiş mi?
35. Kalabalık satışa izin verilen minimum/maksimum katkı ayarlanmış ve test edilmiş mi?
36. Kalabalık satış beyaz liste işlevselliği test edildi mi?
37. Kalabalık satış iade mantığı doğrulandı mı?
38. Kalabalık satış katılımcıları orantılı sayıda token alıyor mu veya katkılarını talep edebilirler mi?
39. Kalabalık satışın her aşamasının süresi (örneğin, ön satış, genel satış) düzgün şekilde yapılandırılmış mı?
40. Kalabalık satışın duraklatılması, başka bir aşamaya geçilmesi, token dağıtımının etkinleştirilmesi gibi işlevlerin yalnızca sahibi tarafından kontrol edilmesi gerektiği belirtilmiş mi?
41. Kalabalık satışın vesting (hakediş) mantığı kontrol edildi mi?
42. Kalabalık satış, sahibin etkinleştirdiğinde özellik çağrılarını sınırlayan ve bir geri ödeme özelliğini içeren bir güvenli mod içeriyor mu?
43. Kalabalık satış makul olduğu sürece bir yedekleme özelliği içeriyor mu?
44. İthal edilen kütüphaneler önceden kontrol edildi mi ve gelecekteki sürümlerde değiştirilip kötü amaçlar için kullanılabilecek istenmeyen kısımlar içermiyor mu?
45. Token transfer yöntemleri (transfer) require ile sarılmış mı?
46. Require ve assert doğru şekilde kullanılıyor mu? Assert yöntemi, değişikliklerden sonra durumu kontrol etmek için genellikle hiç olmaması gereken şeyler için kullanılır.
47. Yeniden giriş saldırılarına karşı bir savunma var mı?
48. Girdideki keyfi dizelerin uzunluğu sınırlanmış mı?
49. Mümkün olduğunda dizileri kullanmaktan kaçınılıp bunun yerine eşlemeler mi kullanılıyor?
50. Rastgele değerleri yönetmek için blok hashleri kullanılmıyor mu (madenciler bunu etkileyebilir)?
51. Hiçbir yerde tx.origin kullanılmıyor mu?
52. Dizinin elemanları silindiğinde boşluk bırakmamak için aşağı doğru kaydırılıyor mu?
53. Throw yerine revert kullanılıyor mu?
54. Koşullar karşılanmazsa fonksiyonlar hemen sona erdiriliyor mu?
55. Derleyici uyarıları çözülmüş mü?
56. Hesaplamalarda SafeMath kütüphanesi kullanılıyor mu?
57. Herhangi bir bellek yuvası (depolama yuvası) birden fazla okunuyor mu?
58. DoS'a neden olabilecek sınırsız döngüler/diziler kullanılıyor mu?
59. Blok zaman damgası sadece uzun aralıklar için mi kullanılıyor?
60. Geçen zamanı hesaplamak için blok numarası kullanılmıyor mu?
61. Delegatecall çağrısı özellikle harici (güvenilir bile olsa) sözleşmeler için kaçınılıyor mu?
62. Dizinin uzunluğu üzerinde yinelenirken güncellenmiyor mu?
63. İmzalar nonce ve block.chainid ile tekrar kullanım saldırılarından korunmuş mu?
64. Tüm imzaların EIP-712 kullanarak yapıldığından emin olun?
65. abi.encodePacked() çıktısı, iki veya daha fazla dinamik tür kullanılıyorsa hashlenmemelidir. Genel olarak, abi.encode() kullanmak tercih edilir.
66. Montaj kodu eklemeleri dikkatlice kontrol edilmelidir.
67. Yetersiz gaz tüketiminden (gas griefing) kaçınılmalıdır.
68. Tüm özel veriler gerçekten özel mi?
69. Bellekteki bir yapı/dizi güncellenmesi, depolamada (stage) değiştirmeyecek mi?
70. Stage değişkenleri gölgelenmiş mi?
71. Bir değişkenin değeri uçuşta hesaplamak, onu depolamaktan daha ucuz mu?
72. Tüm durum değişkenleri doğru sözleşmeden (ana vs. klon) mi okunuyor?
73. Kıyaslama operatörleri (>, <, >=, <=) doğru şekilde kullanılıyor mu, özellikle off-by-one hatalarını önlemek için?
74. Mantıksal operatörler (==, !=, &&, ||, !) doğru şekilde kullanılıyor mu, özellikle off-by-one hatalarını önlemek için?
75. Çarpma her zaman bölme işleminden önce mi yapılıyor (çarpma taşabilir olmadığı sürece)?
76. Sihirli numaralar, anlamlı bir isimle bir sabit ile mi değiştirilmiş?
77. Bir ETH alıcısının geri çevrilebilecek bir yedekleme fonksiyonu (fallback) varsa, bu bir DoS'a yol açabilir mi?
78. SafeERC20 standardı kullanılıyor mu ve dönüş değerleri güvenli bir şekilde kontrol ediliyor mu?
79. Msg.sender'in her zaman ilgili bir kullanıcı olduğu varsayılıyor mu?
80. Yetkilendirme için tx.origin kullanılmıyor mu?
81. Address.transfer() veya address.send() yerine .call.value() kullanılmıyor mu?
82. Düşük seviyeli çağrılar kullanıldığında, çağrıdan önce bir sözleşmenin var olduğundan emin olun.
83. Chainid veya sözleşme kodu/boyutu/hash erişimi için montaj kodu, Solidity sözdizimi yerine kullanılıyor mu?
84. Bir değişkeni null değere (0, false, "", vb.) ayarlarken delete anahtar kelimesi kullanılıyor mu?
85. Mantıksal operatörlere/kıyaslamalara (&&/||/>=/==/vb.) iletilen ifadelerin yan etkileri olmamalıdır.
86. Birden fazla adresle çalışırken, bu adreslerin aynı olması durumunda ne olacağını kendinize sorun.
87. Kod ne kadar iyi belgelenmiş? Standart olmayan kod kullanıldığında yorumlar ve örnekler sağlanmış mı?
88. Harici Çağrı kullanılıyorsa, bir harici sözleşme çağrısının gerçekten gerekli olduğundan emin olun.
89. Harici Çağrı'nın sonucu kontrol ediliyor mu ve hatalar ele alınıyor mu?
90. Harici Çağrı tüm sağlanan gazı kullanırsa ne olur?
91. Harici Çağrı belirli bir fonksiyonu çağırıyorsa, fonksiyonun gerçekten mevcut olduğundan emin olun (hayalet fonksiyonlar).
92. Hiçbir harici çağrının değiştiricilerde (modifiers) kullanılmadığından emin olun.
93. Depolamayı değiştiren her fonksiyon için olaylar (events) yayınlanıyor mu?
94. Ana sözleşmede kullanılan harici sözleşmelerin ne yaptığını ve ne döndürdüğünü kontrol edin.
95. Çok fazla veya çok az ondalık kullanan tokenlara dikkat edin. Desteklenen maksimum ve minimum değerlerin belgelenmiş olduğundan emin olun.
96. Rollerle ilişkilendirilen yetki belgelenmiş mi?
97. Erişim hakları ihlal edildiğinde riskler nelerdir ve bu, sistemin çeşitli bileşenlerini nasıl etkileyebilir?
98. Sahip, sözleşme içindeki tokenları ve ETH'yi manipüle edebilir mi?
99. Oracle adresi nasıl ayarlanır ve arkasındaki süreç nedir? Yedek oracle'lar mevcut mu?
100. Benzer fonksiyonlar diğer projelerde nasıl uygulanmış, en iyi uygulamalar dikkate alınmış mı?

Bu kontrol listesi, Solidity akıllı sözleşmelerinin kapsamlı bir güvenlik denetimini gerçekleştirmenize yardımcı olacaktır. Koddaki ve ilgili sistemlerdeki olası güvenlik açıklarını ve riskleri belirlemek ve azaltmak için çok çeşitli kritik yönleri kapsar.

 

Umarız bu örnekler akıllı sözleşme denetim metodolojisini daha iyi anlamanıza yardımcı olmuştur.

 

Blok zincirindeki tüm bilgiler açık olduğundan (elbette sözleşmenin kaynak kodunun doğrulanması şartıyla), bu bilgiyle donanmış olarak akıllı sözleşmeleri bağımsız olarak inceleyebilir ve çeşitli dolandırıcılık planlarını belirleyebilirsiniz.

Ancak, biz zaten sizin için her şeyi yaptık! Premium abonelik için kaydolun ve akıllı sözleşmelerin özellikleri ve yeni analizler hakkında özel filtrelere erişin. Karlı tokenlara başarılı bir şekilde yatırım yapma şansınızı artırın.

Saygılar, Lotus Market ekibi.

All posts