Back to Blog

Solana Ekosistemini Güvence Altına Alın (7) — Tür Karışıklığı

29 Nisan 2022
4 min read

0. İnceleme

1. Genel Bakış

Önceki blog yazısında, genel bir Çoklu İmza'nın uygulanmasını tanıttık. Bu yazıda, başka bir güvenlik sorununu ele alacağız — Tür Karışıklığı.

2. Seri Çözme/Serileştirme

Solana'da program durumları hesaplarda saklanır. Tür karışıklığı sorunu, hesapların seri çözme/serileştirme işlemi sırasında ortaya çıkar. Programın mantığı genellikle veri yapılarına dayanır. Ancak program, seri çözme/serileştirme işlemi sırasında hesapların türünü düzgün biçimde kontrol etmeyebilir. Bu durum saldırganlar tarafından istismar edilerek beklenmedik kayıplara yol açabilir.

3. Kod İncelemesi (Tür Karışıklığı)

Aşağıda, tür karışıklığı sorununu basit bir programla örneklendiriyoruz. Test kodunu burada bulabilirsiniz.

Test programında iki veri yapısı uyguladık; biri User, diğeri Metadata. Her ikisi de bir hesabın açık anahtarını (farklı hesaplar) kaydeder.

Programın üç farklı talimatı vardır. InitializeUser talimatı, User hesabını oluşturmak ve yetkili bir hesap (yani authority) ayarlamak için tasarlanmıştır. Benzer şekilde, InitializeMeta talimatı MetaData hesabını oluşturmak ve normal bir hesap (yani account) ayarlamak için çağrılır. Test talimatı, saldırganın programın doğrulama mantığını atlayarak kontrol ettiği MetaData ile saldırı gerçekleştirebileceğini göstermektedir.

Test() talimatını adım adım inceleyelim. Program, iletilen User hesabının sahibinin programın kendisi olduğunu doğrular (satır 86 - satır 89). Seri çözme işleminden sonra (satır 92), program iletilen authority hesabının açık anahtarını User hesabında saklanan açık anahtarla karşılaştırır. Eşit değillerse program geri döner (satır 93 - satır 96). Son kontrol, yetki hesabının işlemi imzalamış olmasını sağlamaktır. Ancak bir saldırgan kontrol ettiği Metadata hesabını iletirse tüm kontroller yine de atlanabilir. Bunun nedeni, programın hesapların türünü kontrol etmemesidir. Bir bayt dizisi alır ve bunu doğrudan programda tanımlanan farklı türlerdeki yapılara seri çözer.

Test programını daha ileri testler için dağıtıyoruz; bu bağlantıdan erişilebilir.

3.1 İşlem Gönderme

Programı dağıttıktan sonra, programın sağladığı üç talimatı sırasıyla çağırmak için komut dosyasını yazıyoruz.

Önce InitializeUser ve InitializeMeta'yı çağırıyoruz. Metadata hesabında saklanan account hesabı olarak kendi açık anahtarımızı ayarladığımıza dikkat edin.

test() fonksiyonunda, Metadata hesabını User hesabı olarak ve kendi hesabımızı authority_info olarak iletiyoruz (satır 347 - satır 348). Program Metadata'yı User yapısıyla seri çözdü ve tüm kontroller atlanabildi.

İşlemi gönderiyoruz ve buradan bulunabilir. Program başarı döndürdü; bu da kontrol edilmemiş hesap türüyle doğrulamayı başarıyla geçtiğimiz anlamına geliyor.

4. Özet

Bu makalede, Solana'daki tür karışıklığı sorununu tanıttık. Bu sorunu önlemenin birçok yolu vardır. Örneğin, yapıdaki hesabın türünü kaydetmek için bir nitelik ekleyebiliriz ve program, iletilen hesaptan okuma/yazma işlemi yapmadan önce her zaman tür niteliğini kontrol etmelidir. Takipte kalın, gelecek yazılarda daha fazlasını paylaşacağız.

Bu serideki diğer makaleleri okuyun:


BlockSec Hakkında

BlockSec, 2021 yılında küresel çapta tanınan bir grup güvenlik uzmanı tarafından kurulmuş öncü bir blok zinciri güvenlik şirketidir. Şirket, kitlesel benimsenmesini kolaylaştırmak amacıyla gelişmekte olan Web3 dünyasının güvenliğini ve kullanılabilirliğini artırmaya kararlıdır. Bu doğrultuda BlockSec; akıllı sözleşme ve EVM zinciri güvenlik denetimi hizmetleri, güvenlik geliştirme ve tehditleri proaktif olarak engellemeye yönelik Phalcon platformu, fon takibi ve soruşturma için MetaSleuth platformu ve web3 geliştiricilerinin kripto dünyasında verimli gezinmesi için MetaSuites eklentisini sunmaktadır.

Bugüne kadar şirket, MetaMask, Uniswap Foundation, Compound, Forta ve PancakeSwap gibi 300'den fazla saygın müşteriye hizmet vermiş; Matrix Partners, Vitalbridge Capital ve Fenbushi Capital gibi önde gelen yatırımcılardan iki finansman turunda on milyonlarca ABD doları almıştır.

Resmi web sitesi: https://blocksec.com/

Resmi Twitter hesabı: https://twitter.com/BlockSecTeam

Sign up for the latest updates
BlockSec'in Ödeme Güvenliği Çözümü, Yapay Zekâ Çağında Kurumların Güvende Kalmasına Nasıl Yardımcı Oluyor?
Security Services

BlockSec'in Ödeme Güvenliği Çözümü, Yapay Zekâ Çağında Kurumların Güvende Kalmasına Nasıl Yardımcı Oluyor?

BlockSec'in güvenlik değerlendirmeleri, testler ve sürekli izleme yoluyla ödeme kuruluşlarının fonları korumasına, verileri güvence altına almasına ve dayanıklılıklarını artırmasına nasıl yardımcı olduğunu keşfedin.

Yaklaşık 5,57 milyon USD Kayıp: X100 Freezer ve NEM İstismarları | BlockSec Haftalık Bülteni
Security Insights

Yaklaşık 5,57 milyon USD Kayıp: X100 Freezer ve NEM İstismarları | BlockSec Haftalık Bülteni

Bu haftalık rapor, 19.10.2026–25.10.2026 tarihleri arasında Ethereum ve BNB Chain'de yaşanan iki güvenlik olayını ele alıyor. X100 Freezer'ın flaş krediyle finanse edilen yönetişim kontrolünün ele geçirilmesini ve BNB Chain'deki bir NEM tokeninin likidite havuzunu etkileyen vergi hesaplaşması kusurunu inceliyor. Raporun kapsamındaki tahmini kayıplar toplam yaklaşık 5,57 milyon USD: temsili X100 işleminden ~4,75 milyon USD, NEM havuzu olayından ise ~820 bin USD. Bu toplama, ayrıca bildirilen sonraki X100 fon çıkışları dahil değil.

Yaklaşık 3,87 milyon USD kayıp: Autheo Network ve UNCX saldırıları | BlockSec Haftalık Bülteni
Security Insights

Yaklaşık 3,87 milyon USD kayıp: Autheo Network ve UNCX saldırıları | BlockSec Haftalık Bülteni

Bu haftalık rapor, 12.10.2026–18.10.2026 tarihleri arasındaki 3 güvenlik olayını ve toplamda yaklaşık 3,87 milyon USD tutarındaki tahmini kaybı ele alıyor. Autheo Network, yaklaşık 1,76 milyon USD tutarında kayba yol açan bir özel anahtar ele geçirilmesi olayı yaşadı; Qubic Wallet, zayıf seed oluşturma nedeniyle yaklaşık 1,30 milyon USD kaybetti. UNCX Network’ün Smart Token Vesting V2 sözleşmelerinde ise Ethereum, BNB Chain, Base ve Robinhood Chain üzerinde yaklaşık 807 bin USD tutarında bir muhasebe hatası meydana geldi. Öne çıkarılan UNCX analizi, hatalı toplam pay hesaplamasının farklı token/pay oranlarıyla oluşturulan hak ediş dilimlerini nasıl birbirine karıştırdığını ve ortak havuzlardan hak edilenden fazla çekim yapılmasına nasıl olanak tanıdığını açıklıyor.