# Bir müşteri kendini başkasının hesabında oturum açmış buldu

> Bir alıcı hesabında kendisine ait olmayan siparişler görüyor ya da hiç girilmemiş bir adres için şikâyet alıyorsunuz: bu bir kimlik doğrulama açığıdır ve sipariş akışı bunun klasik yerlerinden biridir.

- Source canonique : [https://allaux.fr/tr/securite/client-connecte-sur-le-compte-d-un-autre](https://allaux.fr/tr/securite/client-connecte-sur-le-compte-d-un-autre)
- Langue : TR
- Dernière mise à jour : 2026-09-30

## Doğrudan yanıt

> Yolculuğu gizli pencerede, başka bir cihazda ve hesapsız olarak yeniden deneyin. Hiç hesabı olmamış bir ziyaretçiye bir ad, bir sepet veya bir hesap bloğu görünüyorsa kişiselleştirilmiş sayfa önbelleğe alınmıştır ve iz önbellektedir. İçerik yalnızca giriş sonrası görünüyorsa oturum çerezlerine ve sepet kimliğine bakın.

## Üç neden, tek bir belirti

Bildirim neredeyse her zaman aynı sözlerle gelir: bir müşteri hesabında kendisine ait olmayan siparişler görüyor ya da hiç kimsenin girmediği bir teslimat adresi için şikâyet alıyorsunuz. İlk refleks, uzun süre benimki de dâhil, önbelleği suçlamaktır. Bazen gerçekten önbellektir. Her zaman değil ve bu fark, bundan sonra ne yapacağınızı tamamen değiştirir.

Aynı belirtiyi üreten üç ayrı neden vardır.

Yanlış yapılandırılmış bir önbellek. Kişiselleştirilmiş bir sayfa — adın göründüğü bir başlık, bir sepet, bir hesap bloğu — bir müşterinin ziyareti sırasında önbelleğe alınmış ve olduğu gibi başka bir ziyaretçiye sunulmuştur. Görünen içerik yanlıştır ama oturumun kendisi doğrudur.

Paylaşılan bir oturum. İki kişi aynı cihazda aynı tarayıcıyı kullanır: bir aile bilgisayarı, bir danışma bilgisayarı, mağazadaki bir tablet. Açık kalan oturum hiçbir zaman kapatılmamıştır.

Gerçek bir kimlik doğrulama açığı. Sunucu oturumu gerçekten yanlış hesapla ilişkilendirmiştir. Bu artık bir görüntüleme sorunu değildir: hesap ele geçirmedir.

## Müşterilerin anlattıkları

- Bir müşteri geçmişinde hiç vermediği siparişleri görüyor.
- Bir müşteri hesabında tanınmayan bir teslimat adresi beliriyor.
- Başlıkta görünen ad, oturum açmış kişinin adı değil.
- Sahibinin vermediğini söylediği bir hesaptan sipariş ödemesi yapılmış.
- Bir müşteri hiçbir parola girmediği hâlde oturumu açık şekilde geldiğini söylüyor.
- Hiçbir şeyle örtüşmeyen saatlerde girişler veya hesap oluşturmaları görünüyor.

## Üç nedeni birbirinden ayıran test

1. **Temiz bir bağlamdan yeniden deneyin** — Gizli pencere, başka bir cihaz, başka bir ağ ve oturum açmadan. Mağazada hiç hesabı olmamış bir ziyaretçide kişiselleştirilmiş içerik görünüyorsa, büyük olasılıkla bir önbellek sorunuyla karşı karşıyasınız.
2. **Önbelleğe alınan bir sayfa ile alınmayanı karşılaştırın** — Bir başlık ya da sayfa bloğu kolayca yanıltabilir; hesap detay sayfası çok daha az. Doğru kişiyi gösteriyorsa sorun bir görüntüleme sorunudur. Diğer kişiyi gösteriyorsa sunucu tarafındaki oturum zaten yanlış hesabı işaret ediyordur.
3. **Gerçek bir işlemin tamamlanıp tamamlanmadığına bakın** — Önbellekten sunulan bir sayfa işlem yapmanıza izin vermez: kaydedilen bir değişiklik doğru hesaba düşer. Bir adres, parola veya sipariş başkasının hesabında gerçekten değiştirilebiliyorsa, bu artık önbellek değildir.
4. **Ortak cihaz ihtimalini eleyin** — Oturumu kapatıp kendi bilgileriyle yeniden açmak, paylaşılan tarayıcı durumunu kesin olarak çözer. Sorun hiç kimseye verilmemiş kişisel bir cihazda yeniden ortaya çıkıyorsa bu neden elenir.
5. **Kimlik doğrulama günlüklerini açın** — Gerçekten karar verdiren tek adım budur. Sunucu ve uygulama günlüklerine erişim gerektirir ve yalnızca bildirimin yapıldığı günü değil, ilgili tüm dönemi kapsamalıdır.

## Gerçekten bir kimlik doğrulama açığı olduğunda

Bu tür açıkların en sık ortaya çıktığı yer sipariş akışıdır ve en hassas nokta hızlı ödemedir. Hızlı ödeme tam olarak adımları ortadan kaldırmak için vardır: müşteri bir düğmeden gelir, ödeme yöntemi bir kimlik sağlar ve mağaza saniyenin küçük bir diliminde bu siparişi hangi hesaba bağlayacağına karar etmek zorundadır. Kaldırılan her adım, başka bir yerde düzgün biçimde yeniden yapılması gereken bir doğrulamadır.

PrestaShop’un resmi ödeme modülü ps_checkout bu durumdan etkilendi. Express Checkout özelliğindeki eksik bir doğrulama, sessiz bir oturum açmaya ve dolayısıyla bir müşteri hesabının e-posta adresinden yola çıkılarak ele geçirilmesine imkân veriyordu. Açığın tanımlayıcısı CVE-2025-61922, CVSS puanı 9,1: ağ üzerinden istismar edilebilir, saldırı karmaşıklığı düşük, hiçbir ayrıcalık gerekmiyor, kullanıcı etkileşimi gerekmiyor. Düzeltmeler 16 Ekim 2025’te 4.4.1 ve 5.0.5 sürümleriyle yayınlandı.

Sessiz oturum açma ifadesini somutlaştırmakta yarar var. Mağaza, müşteri parolasını girmeden ve haberi olmadan onun adına bir oturum açar. Müşteri tarafında hiçbir şey olmaz: e-posta yok, onay isteği yok, hesabında görünür bir iz yok. Sorunun geç fark edilmesinin sebebi bu sessizliktir. Başarısız deneme yoktur, fark edilecek bir giriş hatası dizisi yoktur; yalnızca uzaktan bakıldığında son derece normal görünen bir oturum daha vardır.

## Bir müşteri hesabı gerçekte neler barındırır

Bir hesabın, içine giren kişiye ne verdiği çoğu zaman hafife alınır. Bu yalnızca bir alışveriş geçmişi değildir.

Eksiksiz sipariş geçmişi: ne alındığı, ne zaman, hangi tutarla, hangi adrese teslim edildiği.

Adres defteri: posta adresleri, telefon numaraları, bazen bir iş adresi ve şirket adı.

İletişim bilgileri: gerçek bir siparişten söz edilmesine imkân verdiği için, o müşteriye yönelik inandırıcı bir oltalama saldırısında doğrudan kullanılabilir.

Ele geçirilen hesaptan sipariş verme imkânı; varsa sağlayıcı tarafında kayıtlı ödeme yöntemleriyle birlikte.

Bu son noktada temkinli davranıyorum, siz de davranmalısınız. Gerçekten yeniden kullanılabilir olanın ne olduğu tamamen ödeme sağlayıcısına ve kayıtlı ödeme yönteminin nasıl uygulandığına bağlıdır. Mağaza normalde kart numarasını saklamaz. Günlükler olmadan söyleyebileceğim şey neyin mümkün olduğudur; neyin fiilen yapıldığını söyleyemem.

## Günlüklerin söyledikleri ve söylemeyecekleri

Bu açık için yayınlanan duyuru; gecikmeden güncellemeyi, kimlik doğrulama günlüklerini yeniden incelemeyi, etkilenmiş olabilecek müşterileri bilgilendirmeyi ve olağan dışı siparişleri ve hesap oluşturmalarını izlemeyi tavsiye ediyor. Uygulamada baktıklarım şunlardır.

Öncesinde hiçbir giriş formu gönderimi bulunmayan başarılı oturum açmalar.

Kısa bir aralıkta çok farklı iki bağlamdan aynı hesaba yapılan girişler.

Bu tür bir girişin hemen ardından verilen siparişler.

Bir siparişin izlediği e-posta, parola veya teslimat adresi değişiklikleri.

Art arda yapılan ya da aynı adres kalıbı üzerine kurulmuş hesap oluşturmaları.

Bu günlükler olmadan bilemeyeceklerim ise şunlardır: kaç hesabın etkilendiği, tek bir müşterinin mi hedef alındığı yoksa mağazanın sistematik biçimde mi tarandığı, tam olarak hangi tarihten itibaren ve erişimin sipariş vermek dışında başka bir şey için kullanılıp kullanılmadığı. Barındırma tarafında çok kısa bir saklama süresi, bu soruları kalıcı olarak yanıtsız bırakabilir. Bunu, bir müşteri aradığı gün değil, ihtiyaç duymadan önce kontrol etmek gerekir.

## Bir müşteri hesabı kişisel veri barındırır, dolayısıyla GDPR uygulanır

> Bir güvenlik olayı, kişisel verilerin kazara veya hukuka aykırı biçimde yetkisiz ifşasına yol açtığı andan itibaren GDPR anlamında bir ihlal söz konusudur. Her ihlal, bildirmedikleriniz de dâhil olmak üzere iç bir kayıt defterine işlenmelidir. Kişilerin hak ve özgürlükleri için bir risk taşıyorsa, öğrenildikten sonraki 72 saat içinde yetkili makama, Fransa’da CNIL’e bildirilmelidir. Risk yüksekse, ilgili kişiler de koruma tavsiyeleriyle birlikte doğrudan bilgilendirilmelidir. Risk olmadığı sonucuna varırsanız bildirim yapmazsınız, ancak değerlendirmenizin gerekçelendirilebilir olması gerekir.

## Konuyla ilgili diğer sayfalar

- **Şüpheli siparişler ve müşteri hesapları** — Alışılmışa benzemeyen bir sipariş veya hesap dizisi nasıl okunur. ([/securite/commandes-comptes-clients-suspects](/securite/commandes-comptes-clients-suspects))
- **Sipariş akışı** — Terimin tam olarak neyi kapsadığı ve neden hassas bir bölge olduğu. ([/glossaire/tunnel-de-commande](/glossaire/tunnel-de-commande))
- **PrestaShop ödeme sorunu** — Güvenlik söz konusu olmadan sipariş akışının bozulduğu durumlar. ([/prestashop/probleme-paiement](/prestashop/probleme-paiement))
- **Sitem ele geçirilmiş mi kontrol etme** — Şüphe kurulumun tamamını kapsadığında izlenecek yol. ([/securite/verifier-si-mon-site-est-compromis](/securite/verifier-si-mon-site-est-compromis))

## FAQ

### Bu mutlaka bir saldırı anlamına mı gelir?

Hayır ve bu yüzden her zaman ayırt edici testle başlarım. Yanlış yapılandırılmış bir önbellek ile ortak bir cihaz, müşteri tarafında tamamen aynı anlatıyı üretir. Yalnızca önbelleğe alınmayan bir sayfa ve kimlik doğrulama günlükleri karar verdirir.

### Ödeme modülüm güncel, güvende miyim?

Kapatılan açığa karşı güvendesiniz, belirtiye karşı değil. Güncelleme kapıyı ileriye dönük kapatır; daha önce olmuş olabilecekleri geri almaz. Mağazanız savunmasız bir sürümde çalıştıysa günlüklerin incelenmesi yine de gerekir.

### Etkilenen müşterileri bilgilendirmeli miyim?

Bu açık için yayınlanan duyuru, etkilenmiş olabilecek müşterilerin bilgilendirilmesini açıkça tavsiye ediyor. Bunun ötesinde GDPR, ihlal kişilerin hak ve özgürlükleri için yüksek risk taşıdığında ilgili kişilerin bilgilendirilmesini zorunlu kılar.

### Tüm müşterilerin oturumunu kapatmalı mıyım?

Düzeltmeden sonra, yönetim oturumlarının kapatılması gibi makul bir adımdır. Biraz konfor kaybettirir ve açığın istismar edilebilir olduğu dönemde açılmış tüm oturumları ortadan kaldırır.

### Bir siparişin ele geçirilmiş bir hesaptan verildiğini nasıl anlarım?

Siparişi, onu önceleyen oturum açma ile karşılaştırarak: giriş bağlamı, giriş formu gönderiminin bulunmaması, hesabın alışkanlıklarından sapma. Kimlik doğrulama günlükleri olmadan bu kontrol yapılamaz.