Müşterilerimin hangi verileri gerçekten dışarı çıkmış olabilir
Bir saldırıdan sonra en acil soru « nasıl temizlerim » değil, « ne dışarı çıktı » sorusudur. Yanıt giriş noktasına bağlıdır ve sunucunuzda hâlihazırda bulunan verilerden yeniden kurulur.
İki veri ailesi, iki farklı hırsızlık yolu
Neyin çıkmış olabileceğini araştırırken yapılan ilk hata, her şeyi aynı torbaya koymaktır. Aynı şekilde çalınmayan ve aynı izlerle kanıtlanmayan iki şeyi ayırmak gerekir.
Bir yanda zaten saklanan veriler: siparişler, müşteri hesapları, teslimat ve fatura adresleri, satın alma geçmişi, yapılandırma dosyalarının içeriği. Bunlar sunucuya veya veritabanına erişimle çalınır ve genellikle kullanılabilir izler bırakır: olağan dışı sorgular, bir klasörde beliren dışa aktarma dosyaları, giden trafikte artışlar.
Diğer yanda aktarım hâlindeki veriler: müşterinin şu anda yazdıkları, başta banka kartı bilgileri. Ödemeniz bir sağlayıcıya düzgün biçimde devredilmişse bunlar veritabanınıza hiç uğramaz; buna rağmen çalınabilirler, çünkü hırsızlık gönderim öncesinde müşterinin tarayıcısında gerçekleşir. Betik yoluyla giriş çalmanın mantığı budur: ne veritabanınıza ne de yedeklerinize dokunması gerekir.
Bu ayrım kuramsal değildir: nereye bakacağınızı ve sonunda neyi söyleyebileceğinizi belirler.
Veri çıkışından şüphelenmenizi gerektirenler
- E-posta gönderim sağlayıcınız veya başka bir üçüncü taraf hizmet, siz istemeden bir erişim anahtarını devre dışı bırakıyor.
- Müşteriler, yakın tarihli bir siparişte kart bilgilerini iki kez girmek zorunda kaldıklarını bildiriyor.
- Bankanız veya ödeme sağlayıcınız, mağazanızda kullanılan kartlarda olağan dışı bir dolandırıcılık yoğunluğu bildiriyor.
- Sitenin bir klasöründe, sizin oluşturmadığınız arşiv veya dışa aktarma dosyaları beliriyor.
- Mağazanın sakin olduğu saatlerde sunucudan çıkan trafik belirgin biçimde artıyor.
- Bir müşteri, hesabında kendisine ait olmayan siparişler gördüğünü anlatıyor.
Giriş noktasından erişilebilir alana doğru gitmek
Sonuç veren yöntem, rastgele hırsızlık kanıtı aramak yerine giriş noktasından yola çıkıp neyin erişilebilir olduğunu çıkarmaktır. Son aylarda yayımlanan olaylar, kapsamın kullanılan kapıya göre büyük ölçüde değiştiğini gösteriyor.
Kapı, sunucu tarafında çalışan tuzaklanmış bir eklenti olduğunda kapsam çok geniştir. Haziran 2026'da bir WordPress eklenti yayıncısında belgelenen dağıtım zinciri ihlalinde zararlı yük; wp-config.php dosyasının tamamını, yönetici hesaplarını, e-posta gönderim eklentilerinin sakladığı kimlik bilgilerini ve son üç aya ait WooCommerce siparişlerini çıkarıyordu. Bu son nokta önemlidir: saldırgan veritabanının tamamını değil, bir zaman penceresini aldı. Hangi pencere olduğunu bilmek, müşterilerinize vereceğiniz yanıtı değiştirir.
Kapı edilgen bir açığa çıkma olduğunda kapsam daha dar, ama çoğu zaman çok daha eskidir. PrestaShop için upsshipping modülü hakkında Mayıs 2026'da yayımlanan bildiri, herkese açık okunabilen bir günlük klasörünü anlatıyor: içindeki XML dosyaları UPS API kimlik bilgilerini, gönderici hesap numaralarını, ayrıca müşteri adlarını, posta adreslerini ve telefon numaralarını içeriyordu. Gözlemlenen bir örnekte bu klasörde 2,3 milyondan fazla dosya, yaklaşık 8,7 GB, Şubat 2023 ile Nisan 2026 arasını kapsıyordu. Burada bir sızma yok: veriler yalnızca okunabilir durumdaydı ve üç yıldır öyleydi.
Kapı, teknik bir rapor döndüren kötü korunmuş bir uç nokta olduğunda dışarı çıkan şey kataloğunuz değil anahtarlarınızdır. Gravity SMTP eklentisinde Mart 2026'da düzeltilen açık, bağlı e-posta hizmetlerinin API anahtarlarını ve OAuth belirteçlerini, veritabanı bilgilerini, WordPress ve PHP sürümlerini, eklenti envanterini ve etkin temayı içeren yaklaşık 365 KB veri döndürüyordu. Bu partide müşteri verisi yok, ama başka birkaç kapıyı açmaya yetecek kadar bilgi var.
Son olarak kapı, sayfalarınıza yerleştirilmiş bir betik olduğunda yalnızca enfeksiyon döneminde yazılan veriler etkilenir ve bunların hiçbiri sunucunuzda durmaz. Sansec'in Şubat 2026'da anlattığı çift ödeme formuyla kart hırsızlığı böyledir; PrestaShop'un Ocak 2025'te bildirdiği SQL enjeksiyonu dalgasında değiştirilmiş bir yapılandırma değerinden yüklenen JavaScript'in yaptığı da budur.
Kapsamı nasıl sınırlandırırım
-
Açığa çıkma penceresini tarihlendirmek
Bırakılan dosyaların değişiklik tarihini, savunmasız veya tuzaklanmış sürümün kurulum tarihini ve erişim günlüklerindeki ilk olağan dışı izleri karşılaştırırım. Kesin bir tarih çıkmaz; devamı için bir aralık yeterlidir.
-
Bu giriş noktasından neyin erişilebilir olduğunu listelemek
Sitenin kendi haklarıyla sunucu tarafında çalışan bir kod, sitenin okuyabildiği her şeyi okuyabilir: veritabanı, yapılandırma dosyaları, dışa aktarmalar. Edilgen bir açığa çıkma yalnızca bir klasörün içeriğini verir. Sayfalara yerleştirilmiş bir betik yalnızca ziyaretçilerin yazdıklarını verir.
-
Dışarı çıkış izlerini aramak
Yükleme klasörlerinde oluşturulmuş arşivler veya dışa aktarmalar, aynı sayfaya olağan dışı yanıt boyutlarıyla yapılan yinelenen istekler, sitenin iletişim kurması için hiçbir nedeni olmayan hedeflere giden bağlantılar.
-
Üçüncü tarafların günlüklerini kontrol etmek
Ödeme sağlayıcınızın, e-posta hizmetinizin veya taşıyıcınızın panosu anahtarlarınızın kullanım geçmişini tutar. Tanımadığınız bir kaynaktan gelen kullanım bir varsayım değil, bir kanıttır.
-
Temizlemeden önce her şeyi dondurmak
Günlüklerin kopyası, şüpheli dosyaların kopyası, yönetici hesapları listesinin görüntüsü. Bu adımdan önce yapılan bir temizlik, tam da soruyu yanıtlayacak olan şeyi yok eder.
Müşteri parolalarının özel durumu
Bu soru her seferinde gelir ve yanıtın kesin olması gerekir. Güncel bir PrestaShop veya WordPress kurulumunda müşteri parolaları düz metin olarak saklanmaz: veritabanı tek yönlü hesaplanmış bir özet tutar. Dolayısıyla müşteri tablosunun bir kopyası parolaları doğrudan vermez.
Bu riski azaltır, ortadan kaldırmaz. Bir özet, deneme sınırı olmadan ve siz görmeden çevrimdışı olarak saldırıya uğrayabilir; zayıf parolalar ilk düşenlerdir. Daha da önemlisi, asıl risk mağazanız değil, parola yeniden kullanımıdır. Aynı parolayı e-posta kutusunda kullanan bir müşteri, sorunu başka bir yere taşımış olur.
Ayrıca parolanın yazıldığı anda, düz metin hâlinde ve veritabanına hiç uğramadan yakalandığı senaryolar da vardır: mekanizma kart hırsızlığıyla aynıdır. Hesabın hiç parola olmadan ele geçirildiği senaryolar da vardır: PrestaShop Checkout modülünde Ekim 2025'te düzeltilen açık, bir müşteri hesabına e-posta adresi üzerinden sessiz giriş yapılmasına izin veriyordu. Her iki durumda da parola sıfırlamayı zorlamak yetmez; önce kapının kapatılmış olması gerekir.
Konuyla ilgili diğer sayfalar
-
Sitemin ele geçirilip geçirilmediğini doğrulamak
Herhangi bir sonuca varmadan önce yapılacak ücretsiz kontroller.
-
İlk iki saatte ne yapmalı
Şüphe doğrulandığında öncelik sırası ve izlerin korunması.
-
Enfekte bir siteyi temizlemek
Yedeği geri yüklemenin neden yetmediği ve kanıtları yok etmeden nasıl ilerleneceği.
-
PrestaShop hata günlüklerini okumak
Günlükler nerede, ne tutuyor ve ne kadar süreyle saklanıyor.
İhtiyacınızı bir dakikada anlatın
Size bir anket daha değil, doğrudan bir tahmin sunabilmem için birkaç hedefli soru.