# Ödeme formu sipariş sırasında iki kez görünüyor

> Müşteri kartını girer, sayfa yeniden yüklenir ve asıl ödeme formu aynı bilgileri yeniden ister: bu çift giriş bir görüntü hatası değil, tarayıcı tarafında kart verisi hırsızlığının imzasıdır.

- Source canonique : [https://allaux.fr/tr/securite/formulaire-de-paiement-affiche-deux-fois](https://allaux.fr/tr/securite/formulaire-de-paiement-affiche-deux-fois)
- Langue : TR
- Dernière mise à jour : 2026-09-30

## Doğrudan yanıt

> Her sayfada yüklenen şablonları açın — PrestaShop’ta _partials/head.tpl, WooCommerce’de etkin temanın header.php dosyası — ve eklemediğiniz bir script etiketi arayın. Değiştirilme tarihlerini son müdahalenizle karşılaştırın. Sonra ödeme sağlayıcınızı bilgilendirin: script yerinde kaldığı sürece verilen her sipariş toplamayı beslemeye devam eder.

## Çift giriş neden en güvenilir belirtidir

Bir müşteri size kartını iki kez girmek zorunda kaldığını yazar: ilk sayfa yeniden yükleniyor gibi olmuş, ardından her zamanki ödeme formu aynı bilgileri tekrar istemiştir. Sipariş normal şekilde tamamlanmıştır, tutar doğrudur, tek bir çekim görünür. Yönetim panelinde ters giden hiçbir şey yoktur.

Bu, Sansec’in Şubat 2026’da “double-tap skimming” adıyla belgelediği tekniğin tam olarak imzasıdır. 16 Şubat 2026’da, dünyanın ilk 10 perakendecisi arasında yer alan bir süpermarket zincirinin mağazasında tespit edilmiştir: yıllık yaklaşık 100 milyar avro ciro, 25 ülkede 10.000’den fazla mağaza; e-ticaret altyapısının bir bölümü PrestaShop üzerinde çalışmaktadır. Önce sahte bir ödeme formu görünür ve kart bilgilerini yakalar, ardından gerçek form devreye girer ve sipariş normal biçimde tamamlanır. Müşterilerin çoğu, verilerinin çoktan çalındığından şüphelenmeden bu ikinci girişi kabul eder.

Belirti güvenilirdir, çünkü yapısaldır. Hırsızlığın çalışması için müşterinin hiçbir yere varmayan bir formu doldurması gerekir; dolayısıyla ona yeniden başlatmak zorundadır. Satıcı tarafında ise hiçbir uyarı, anormal bir hata oranı veya siparişlerde tuhaf bir satır yoktur: bilgi ancak durumu garip bulan bir müşteriden ya da bir ay sonra gelen bir dolandırıcılık itirazından gelir.

## Bir kontrol başlatmanız gereken durumlar

- Bir müşteri, aynı sipariş içinde kart bilgilerini iki kez girdiğini anlatıyor.
- Bir müşteri, görünümü bildiğinizden biraz farklı olan bir ödeme ekranından söz ediyor.
- Aynı dönemde sipariş vermiş birden fazla müşteriyle ilgili kart dolandırıcılığı itirazı geliyor.
- Ödeme sağlayıcınız veya bankanız, siparişlerinizde olağan dışı bir dolandırıcılık yoğunlaşması bildiriyor.
- Bir tema dosyasının değişiklik tarihi, sizin yaptığınız hiçbir işle açıklanamıyor.

## Nereye bakmalı: önce tema dosyaları, sonra veritabanı

Sansec, satıcı tarafında iki yer gösteriyor. Birincisi, tema dosyalarına enjekte edilen script etiketleri; özellikle PrestaShop’ta _partials/head.tpl: bu, sipariş adımları dâhil tüm sayfalarda yüklenen şablondur. İkincisi, giriş alanlarını izleyen ve değerleri tarayıcının localStorage alanında bir önekle saklayan, sonra bunları alıp başka yere gönderen JavaScript. Hedef adresi burada yayınlamıyorum.

Açılması gereken diğer yer veritabanıdır. PrestaShop, Ocak 2025’te çekirdekte değil üçüncü taraf modüllerde SQL enjeksiyonu açıklarını kullanan bir saldırı dalgasını belgeledi: saldırganlar PS_SHOP_NAME yapılandırma değerine zararlı içerik yerleştiriyordu. Bu değer daha sonra, müşteri girdilerini yakalayan yetkisiz JavaScript’i yüklemek için kullanılır. Önerilen kontrol doğrudandır: veritabanındaki PS_SHOP_NAME değerini okuyun ve mağaza adınızdan başka bir şey içermediğini doğrulayın. PrestaShop ayrıca tüm yerleşik ve üçüncü taraf modüllerin güncellenmesini, ps_ yerine özel bir veritabanı öneki kullanılmasını ve bir uygulama güvenlik duvarı devreye alınmasını öneriyor.

Her iki yol da aynı şeyi anlatır: bir tema şablonu ile bir yapılandırma değeri, kimsenin bir daha okumadığı iki yerdir ve ödeme sayfasında neyin çalışacağına onlar karar verir.

## Ödemenin sağlayıcıda barındırılması sizi korumaz

Birçok satıcı, kart girişi ödeme sağlayıcısının barındırdığı bir çerçevede veya sayfada yapıldığı ve kart numaraları kendi sunucularından hiç geçmediği için konuyu kapanmış sayar. Bu, formun kendisi için doğrudur. Onu çevreleyen sayfa için doğru değildir.

Çift giriş senaryosunda enjekte edilen kod sağlayıcının alanına saldırmaz: kendi katmanını ondan önce, sizin kontrol ettiğiniz sayfada gösterir. Müşteri, kendi dilinde ve sizin markanızla inandırıcı bir ödeme ekranı görür. Sansec, bu katmanların artık özenle yerelleştirildiğini ve üretken yapay zekâ araçlarının bunların hazırlanmasını hızlandırdığını belirtiyor. Ödemeyi barındıran sayfa değiştirilebildiği sürece, barındırılan entegrasyon hırsızlığı engellemez.

## Bu sırayla kontrol ederim

1. **Tema dosyalarını temiz bir referansla karşılaştırın** — Bir dağıtım kopyası, daha eski bir yedek veya bir Git deposu karşılaştırma noktası sağlar. Tüm sayfalarda yüklenen bir şablona eklenmiş her script etiketi, aksi kanıtlanana kadar ele geçirilme olarak değerlendirilmelidir.
2. **Sunucudaki değişiklik tarihlerini çıkarın** — Sizin hiçbir müdahaleniz olmadan yakın zamanda değişmiş dosyalar olayın zaman aralığını belirler: erişim günlüklerinde ve yönetim paneli oturum geçmişinde aranacak bir başlangıç tarihi verir.
3. **Veritabanındaki PS_SHOP_NAME değerini okuyun** — PrestaShop’ta bu yapılandırma değeri yalnızca mağaza adını içermelidir. Oradaki her etiket, script veya adres parçası doğrudan bir sinyaldir ve giriş noktası olarak savunmasız bir üçüncü taraf modülü işaret eder.
4. **Ödeme sayfasında gerçekten yüklenen scriptleri envanterleyin** — Sipariş adımlarını bir tarayıcıda açın ve yüklenen scriptleri listeleyin. Her biri, kurmaya karar verdiğiniz bir modüle, temaya veya araca karşılık gelmelidir. Karşılığını bulamadığınız her şey, yerinde bırakılmadan önce gerekçelendirilmelidir.
5. **Dosyalardan önce erişimleri ele alın** — Erişimleri (yönetim paneli, FTP/SFTP, veritabanı, barındırma) yenilemeden bir şablonu temizlemek kapıyı açık bırakmaktır: kod geri gelir. Sansec’in belgelediği olayda, altı bildirim denemesinden sonra skimmer 20 Şubat 2026’da hâlâ etkindi. Bu tür bir bulaşma kendiliğinden durmaz.

## PCI DSS 31 Mart 2025’ten beri ne istiyor

> PCI DSS v4.x’in 6.4.3 ve 11.6.1 gereksinimleri 31 Mart 2025’ten beri uygulanmaktadır ve tam olarak bu riski hedefler. 6.4.3, bir ödeme sayfasında yüklenen ve çalıştırılan tüm scriptlerin yetkilendirilmiş, yazılı olarak gerekçelendirilmiş, envanterlenmiş olmasını ve bütünlüklerinin denetlenmesini şart koşar. 11.6.1, HTTP başlıklarında ve ödeme sayfasının müşterinin tarayıcısına ulaşan içeriğinde yetkisiz bir değişiklik olduğunda uyarı veren bir tespit mekanizması ister. PCI Security Standards Council, bu iki gereksinimin yaygın biçimde yanlış anlaşıldığını görünce tamamlayıcı rehberler yayınladı.

## Bu sayfada bulunmayanlar

Burada saldırıyı yeniden üretmeye yarayacak hiçbir yöntem, hiçbir enjekte kod, hiçbir hedef adres ve savunmasız mağazaları bulmaya yarayacak hiçbir yol yazmıyorum. Bu sayfa tespit etmek, doğrulamak ve düzeltmek içindir; kimseyi donatmak için değil.

Anlatılan işaretlerden biri varsa, sonraki adım tek bir dosyayı düzeltmek değildir: eksiksiz bir temizlik, tüm erişimlerin yenilenmesi ve bir sonraki değişikliğin bir ay sonra bir banka itirazıyla değil aynı gün yakalanması için ödeme sayfasına bütünlük denetimi konmasıdır.

## Bulduğunuza göre devamı

- **Sitem ele geçirildi mi diye kontrol etmek** — Yalnızca ödeme sayfasının ötesinde, eksiksiz bir inceleme. ([/securite/verifier-si-mon-site-est-compromis](/securite/verifier-si-mon-site-est-compromis))
- **Bulaşmış bir siteyi temizlemek** — Kodun geri gelmesini engelleyen bir temizliğin gerçekte gerektirdikleri. ([/securite/nettoyer-un-site-infecte](/securite/nettoyer-un-site-infecte))
- **PrestaShop ödeme sorunları** — Kötü davranan bir sipariş akışının diğer olası nedenleri. ([/prestashop/probleme-paiement](/prestashop/probleme-paiement))
- **Sipariş akışı** — Bu terimin tam olarak neyi kapsadığı, adım adım. ([/glossaire/tunnel-de-commande](/glossaire/tunnel-de-commande))

## FAQ

### Yalnızca bir müşteri şikâyet etti, gerçekten her şeyi kontrol etmeli miyim?

Evet. Tarayıcı tarafındaki bir hırsızlık siparişlerinizde hiçbir iz bırakmaz. Tek bir bildirim, çoğu zaman herkesi etkileyen bir sorunla ilgili alacağınız tek geri bildirimdir.

### Ödeme sağlayıcım beni uyarmaz mıydı?

Mutlaka değil. Bu senaryoda veriler sağlayıcıya ulaşmadan önce, sizin sayfanızın içinde yakalanır. Onun tarafında işlem tamamen normal görünür.

### Bu yalnızca PrestaShop’u mu ilgilendiriyor?

Hayır. Sansec, WordPress, Magento, PrestaShop ve OpenCart için entegrasyonlar öngören, yeniden kullanılabilir bir zararlı yazılım iskeletinden söz ediyor. Çift giriş belirtisi platformdan bağımsız olarak aynıdır.

### Değiştirilmiş tema dosyasını temizlemek yeterli mi?

Hayır. Giriş noktası belirlenmediği ve tüm erişimler yenilenmediği sürece kod geri gelir. İşin uzun süren kısmı budur ve sonucu belirleyen de odur.

### 6.4.3 ve 11.6.1 gereksinimlerini pratikte nasıl karşılarım?

Ödeme sayfasında izin verilen scriptlerin yazılı bir envanterini tutarak, bütünlüklerini denetleyerek ve HTTP başlıkları ya da bu sayfanın içeriği müşterinin tarayıcısında değiştiğinde uyarı veren bir tespit düzeneği kurarak.

### Kontrol süresince mağazayı kapatmalı mıyım?

Çift giriş bir müşteri tarafından doğrulandıysa evet: kontrol sırasında verilen her sipariş bir kartı daha açığa çıkarır. Sipariş akışına konan bir bakım sayfası, bir dizi itirazdan daha ucuza gelir.