Mağazamın adında yazmadığım bir metin görünüyor
Alt bilgide, tarayıcı sekmesinde veya sipariş e-postalarında bir kod parçası beliriyor: mağaza adını taşıyan yapılandırma değeri doğrudan veritabanında değiştirilmiş ve taşıyıcı olarak kullanılıyor.
Aslında bir görüntüleme hatası olmayan hata
Belirti neredeyse her zaman aynı şekilde anlatılır: « alt bilgide anlamsız bir metin var », « tarayıcı sekmesi kod gösteriyor », « sipariş e-postalarında mağazamın adı bozuk ». Alışılmış refleks, hatalı bir çeviri, yanlış yapılandırılmış bir tema veya içe aktarma sırasında bozulmuş bir karakter aramaktır. Neredeyse hiçbir zaman bu değildir.
Mağaza adı bir tema metni değildir. PS_SHOP_NAME anahtarı altında veritabanında saklanan bir yapılandırma değeridir. Mağaza bu değeri okur ve onlarca yerde yeniden gösterir: üst bilgi, alt bilgi, tarayıcı sekmesindeki sayfa başlığı, işlem e-postaları, faturalar, dâhili bildirimler. Veritabanında tek bir satır, her yerde sunulur ve yeniden göründüğü yere göre her zaman aynı biçimde işlenmez.
Bu değeri saldırgan için kullanışlı bir hedef hâline getiren şey budur. Tema dosyasını değiştirmesi, ödeme adımına dokunması veya sunucuda dosya bırakması gerekmez. Bir yapılandırma değerine bir kez yazar ve içeriği artık tüm sayfalarda, tüm ziyaretçilere, ödeme yapmakta olanlar da dâhil olmak üzere sunulur. Alt bilgide gördüğünüz tuhaf metin sorunun kendisi değildir: geri kalanı sessiz olan bir zincirin görünen parçasıdır.
Sizi uyarması gerekenler
- Mağaza adının normalde göründüğü yerde, alt bilgide görünen bir etiket veya kod parçası.
- Hiç yazmadığınız bir metin içeren tarayıcı sekmesi başlığı.
- Sipariş onay e-postalarında veya faturalarda bozulmuş mağaza adı.
- Yönetim panelinde normal görünen ama herkese açık sitede başka türlü görünen « Mağaza adı » alanı.
- Ödeme adımı da dâhil olmak üzere sayfa kaynağında tanımadığınız bir betik.
- Ödeme bilgilerinin kendilerinden iki kez istendiğini bildiren müşteriler.
PrestaShop'un Ocak 2025'te belgelediği durum
22 Ocak 2025'te PrestaShop, çekirdekte değil üçüncü taraf modüllerde bulunan SQL enjeksiyonu açıklarını istismar eden bir saldırı dalgası hakkında resmi bir uyarı yayınladı. Anlatılan yöntem tam olarak budur: saldırganlar, veritabanında saklanan PS_SHOP_NAME yapılandırma değerine zararlı içerik ekler; bu değer daha sonra müşterilerin girdilerini yakalayan yetkisiz JavaScript'i yüklemek için kullanılır. PrestaShop'un önerdiği kontrol basit biçimde ifade edilebilir: veritabanındaki PS_SHOP_NAME değerinin içinde beklenmeyen bir betik veya içerik aramak.
Bu JavaScript görünümü bozmak için orada değildir. Müşterilerinizin ödeme adımında yazdıklarını okumak için oradadır: iletişim bilgileri, adres, ödeme bilgileri. En özenli kampanyalarda üst katman dikkatle hazırlanır: önce sahte bir ödeme formu görünür, müşteri kart bilgilerini girer, ardından gerçek form aynı bilgileri yeniden ister. Müşterilerin çoğu bu ikinci girişi kabul eder ve verilerinin çoktan çalındığından şüphelenmeden siparişini tamamlar. Bu nedenle bu belirti kozmetik bir kusur gibi ele alınamaz.
Düzeltme tarafında PrestaShop, resmi ps_contactinfo modülünün düzeltilmiş sürümünü yayınladı: PrestaShop 1.7.2 ve üzeriyle uyumlu 3.3.3 sürümü, GitHub bildirimi GHSA-35pq-7pv2-2rfw. Resmi öneriler bununla sınırlı değil: yerleşik ve üçüncü taraf tüm modülleri güncellemek, varsayılan yerine özel bir veritabanı ön eki kullanmak, bir web uygulaması güvenlik duvarı devreye almak, düzenli yedek almak ve PrestaShop güvenlik bildirimlerini takip etmek.
SELECT name, value FROM ps_configuration WHERE name = 'PS_SHOP_NAME';Değeri neden yönetim panelinde değil veritabanında okumalısınız
Yukarıdaki sorgu yalnızca okuma yapar, hiçbir şeyi değiştirmez. ps_ ön ekini kendi kurulumunuzunkiyle değiştirmelisiniz: özel ön ek önerisine uyduysanız tablonun adı sizde farklıdır.
Neden yönetim panelindeki alan yerine veritabanı? Çünkü yönetim paneli değeri bir form içinde gösterir ve bir form, aldığı içeriğin bir kısmını kaçışlar, kısaltır veya gizler. Bir giriş kutusunda zararsız görünen bir değer, sayfada sunulduğunda bambaşka bir şey içerebilir. Veritabanını okumak size ham değeri, yani gerçekten kayıtlı olanı, arada hiçbir görüntüleme katmanı olmadan verir. Sonucu kesinleştiren tek kontrol budur.
Varsayılan ön ekin burada doğrudan bir rolü vardır. Bir tabloya yazmayı hedefleyen bir işlem, o tablonun adını bilmek zorundadır. Standart ön ekle bu ad yüz binlerce mağazada aynıdır: tahmin edilecek bir şey kalmaz ve bir kez yazılmış bir saldırı hiçbir uyarlama gerektirmeden her yerde çalışır. Ön eki değiştirmek hiçbir açığı kapatmaz, tek başına bir koruma değildir; PrestaShop bunu tam olarak otomatik saldırılara bedava sunulan bir kolaylığı ortadan kaldırdığı için önerir.
Bu sırayla ilerliyorum
-
Ham değeri veritabanında okuyun
Yukarıdaki salt okuma sorgusunu kendi ön ekinize uyarlayarak kullanın. Yalnızca yanlış yazılmış bir ad değil, değerin içinde beklenmeyen bir betik veya içerik arıyorsunuz.
-
Herkese açık sayfanın gerçekte sunduğuyla karşılaştırın
Bir sayfanın kaynak kodunu görüntüleyin ve mağaza adının yeniden yazıldığı yerlere bakın: üst bilgi, alt bilgi, belge başlığı. Veritabanı ile sayfa arasındaki fark, değerin nerede yeniden yorumlandığını gösterir.
-
Tema dosyalarını kontrol edin
Yapılandırma değeri tek olası taşıyıcı değildir. Betik etiketleri doğrudan tema dosyalarına da, özellikle her sayfada yüklenen şablonlara enjekte edilebilir. Temayı temiz bir kopyayla karşılaştırın.
-
Değeri düzeltin, sonra yazma işlemini bulun
Temiz bir mağaza adını geri koymak belirtiyi birkaç dakikada ortadan kaldırır. Ancak bu, değerin nasıl yazıldığı hakkında hiçbir şey söylemez. Bu yazmaya izin veren modül yerinde durduğu sürece değer yeniden yazılabilir.
-
Tüm modülleri güncelleyin
İlk resmi öneri budur: yerleşik modüller kadar üçüncü taraf modüller de. Resmi ps_contactinfo modülünün düzeltilmiş sürümü, PrestaShop 1.7.2 ve üzeriyle uyumlu 3.3.3 sürümüdür.
-
Olayı olası bir veri ihlali gibi ele alın
Ödeme sayfalarında yetkisiz JavaScript sunulduysa müşteri girdileri yakalanmış olabilir. Bu, bildirim yükümlülüklerini doğurur ve belgelenmesi gerekir: tarihler, etkilenen sayfalar, maruz kalma süresi.
Konuyla ilgili diğer sayfalar
-
SQL enjeksiyonları açıklandı
Dışarıdan bir yapılandırma tablosuna yazmayı mümkün kılan mekanizma.
-
Sitemin ele geçirilip geçirilmediğini kontrol etme
Veritabanındaki bir değer değiştirildiğinde incelenmesi gereken diğer yerler.
-
Virüslü bir siteyi temizleme
Kaynak belirlendikten sonra neyin, hangi sırayla kaldırılacağı.
-
Veritabanı
Bir mağazanın veritabanında ne bulunur ve yapılandırma neden orada saklanır.
İhtiyacınızı bir dakikada anlatın
Size bir anket daha değil, doğrudan bir tahmin sunabilmem için birkaç hedefli soru.