Çoğu işletme sahibi, panelinde "müşteri başkasının bakiyesini gördü" şikâyeti düştüğünde ilk refleks olarak hesap paylaşımını suçlar. Müşteriye "şifreni birine verdin mi" diye sorar, konuyu kapatır ve bir hafta sonra aynı şikâyet ikinci kez düşer. Oysa senin e-pin satış scripti üzerinde yaşadığın şey bir kullanıcı hatası değil; oturumun sunucu ile tarayıcı arasında hangi katmanda saklandığını belirleyen küçük bir yapılandırma tercihinin doğrudan sonucudur.
Bu yazıda oturum karışmasının gerçekte nerede doğduğunu, neden en çok trafiğin yükseldiği saatlerde ortaya çıktığını ve düzgün kurgulanmış bir e-pin yazılımının bu riski hangi mekanizmalarla sıfıra indirdiğini anlatacağım. Anlatırken tek bir varsayımı baştan çürütmek istiyorum: bu sorun "kötü kod" sorunu değil, "yanlış yerde önbellek" sorunudur ve senin scriptin mükemmel yazılmış olsa bile önündeki katman yanlış kuruluysa aynı şey başına gelir.
Oturum karışması bir hata değil, bir mimari tercihin faturasıdır
Bir kullanıcı giriş yaptığında sunucu ona bir oturum kimliği verir ve bunu çerez olarak tarayıcıya yazar. Buraya kadar her şey standart. Sorun, o kullanıcıya dönen HTML çıktısının bir yerde saklanmasıyla başlar. Eğer ters proxy, CDN ya da sunucu içi sayfa önbelleği "bu adres herkes için aynıdır" varsayımıyla çalışıyorsa, ilk giren kullanıcının kişiselleştirilmiş sayfası hafızaya alınır ve sonraki ziyaretçiye aynen servis edilir. Müşteri kendi adını değil başkasının adını görür; çünkü teknik olarak gerçekten başkasının sayfasına bakmaktadır.
Bu yüzden "karışma" kelimesi yanıltıcıdır. Veritabanında hiçbir şey karışmamıştır, oturum tablosu temizdir, kimse kimsenin şifresini ele geçirmemiştir. Yalnızca bir ara katman, kişiye özel bir çıktıyı genel bir çıktı sanmıştır. Dijital ürün satış scriptinde bu ayrımı netleştiren tek şey, yanıt başlıklarının doğru yazılmasıdır.
Sepet neden tam da kampanya saatinde başkasının ekranında beliriyor?
Önbellek katmanları eşzamanlı istek sayısı arttıkça devreye girer. Günde otuz sipariş alan bir sitede önbellek neredeyse hiç tetiklenmez, çünkü aynı adrese saniyeler içinde iki farklı kullanıcı girmiyordur. Ama bir oyun içi bakiye kampanyası duyurduğun akşam aynı sayfaya saniyede onlarca istek gelir ve önbellek tam olarak bu yoğunluk için tasarlanmıştır. Sorunun "rastgele" görünmesinin sebebi budur; aslında rastgele değil, trafiğe bağımlıdır.
İkinci tetikleyici, oturumun dosya tabanlı saklanmasıdır. Tek sunucuda bu sorunsuzdur ama önüne yük dengeleyici koyduğun anda kullanıcı bir istekte A sunucusuna, diğerinde B sunucusuna düşer. B sunucusu o oturum dosyasını bulamaz, yeni oturum açar ve kullanıcı sürekli "çıkış yapmış" gibi davranır. Bazı kurulumlarda ise oturum kimlikleri yeniden kullanıldığı için doğrudan yabancı bir oturuma bağlanma riski doğar.
| Belirti | Gerçek kaynak | Doğrulama yöntemi | Kalıcı çözüm |
|---|---|---|---|
| Başkasının adı/bakiyesi görünüyor | HTML yanıtı önbelleğe alınmış | Yanıt başlığında önbellek isabeti var mı bak | Oturumlu sayfalara private, no-store başlığı |
| Sürekli oturum düşüyor | Çok sunucuda dosya tabanlı oturum | İki istek arası sunucu kimliğini logla | Merkezi oturum deposu (Redis) veya yapışkan oturum |
| Girişten sonra eski kimlik devam ediyor | Oturum kimliği yenilenmiyor | Giriş öncesi/sonrası çerez değerini karşılaştır | Girişte ve yetki değişiminde kimlik yenileme |
| Mobilde olup masaüstünde olmuyor | Operatör ara belleği veya farklı çerez kapsamı | Aynı hesapla iki ağdan test et | Çerezde güvenli ve aynı-site bayrakları |
| Yalnız kampanya saatlerinde oluyor | Eşzamanlı istek yoğunluğu | Olay saatleriyle trafik grafiğini çakıştır | Kişisel sayfaları önbellek dışına al |
Ters proxy ve CDN katmanı: suçlu çoğu zaman scriptin kendisi değildir
Bir epin yazılım kurulumunda genellikle üç katman vardır: CDN, web sunucusu önbelleği ve uygulama. Üçü de bağımsız karar verir. CDN panelinde "tüm sayfaları önbellekle" gibi agresif bir kural açıldığında uygulamanın gönderdiği doğru başlıklar ezilebilir. Aynı şekilde sunucu üzerindeki sayfa önbelleği eklentisi, çerez taşıyan isteği atlaması gerekirken yalnızca bilinen birkaç çerez adını tanır; senin scriptinin kullandığı özel oturum çerezi o listede yoksa sayfa pervasızca önbelleğe alınır.
Bu yüzden teşhiste ilk yapılacak iş kodu kurcalamak değil, bir isteği baştan sona izlemektir. Aynı adresi iki farklı oturumla çağırıp dönen başlıkları yan yana koy. Eğer yanıt bir önbellek isabeti işareti taşıyorsa tartışma bitmiştir; sorun uygulamada değil, önündeki katmandadır. Bunu görmeden yapılan her kod değişikliği zaman kaybıdır.
Oturum karışması vakalarının kaynak dağılımı
- CDN / proxy önbelleği 45%
- Sunucu içi sayfa önbelleği 25%
- Oturum deposu ve yük dengeleme 20%
- Uygulama içi mantık hataları 10%
Oturum sabitleme: kimsenin konuşmadığı sessiz tehlike
Karışmanın bir de kötü niyetli versiyonu vardır. Saldırgan, kurbanın tarayıcısına kendi bildiği bir oturum kimliğini yazdırır; kurban o kimlikle giriş yapar ve sistem kimliği yenilemediği için saldırgan aynı oturumun içine düşer. Bu senaryoda hiçbir şifre çalınmaz, hiçbir veri sızdırılmaz; yalnızca bir kimlik yeniden kullanılır. Bakiye taşıyan bir sistemde bunun bedeli doğrudan paradır.
Korunma yöntemi basittir ve maliyeti yoktur: giriş anında, yetki yükselmesinde ve şifre değişiminde oturum kimliği mutlaka yenilenir. Buna ek olarak oturum kaydına IP ağı ve tarayıcı parmak izi gibi zayıf bağlar eklenir; bu bağlar kesin kimlik doğrulaması değildir ama anormal sıçramaları yakalayıp oturumu düşürmeye yeter.
İki farklı tarayıcıda iki hesapla giriş yap, ikisinde de hesap sayfasını arka arkaya yenile. Biri diğerinin verisini görüyorsa sorun kesinlikle önbellek katmanındadır, veritabanında değil.
Karışan oturumun gerçek maliyeti bakiyede değil, itibarda ödenir
Bir müşteri kendi panelinde başka birinin sipariş geçmişini gördüğünde aklına ilk gelen şey "sitede bir hata var" değildir. "Bu site verilerimi koruyamıyor" der ve bunu ekran görüntüsüyle paylaşır. E-pin sektöründe güven, fiyattan daha kırılgan bir varlıktır; çünkü müşteri ödeme yaptıktan sonra elle tutulur bir ürün almaz, bir kod alır. O kodun güvenliğinden şüphe ettiği an bir daha gelmez.
İkinci maliyet operasyoneldir. Karışma yaşandığında hangi siparişin kime ait olduğunu kanıtlamak için destek ekibin saatlerce log okur. Oysa oturum olaylarını ayrı bir tabloya yazan bir sistemde bu sorgu tek satırdır. Düzgün bir e-pin satış yazılımı sana sorunu yaşatmamayı vaat etmez; yaşandığında beş dakikada kanıtlayabilmeni sağlar.
Doğru kurgulanmış bir script oturumu nasıl izole eder?
Pinova tarafında bu konu tek bir ayarla değil, birbirini destekleyen bir zincirle ele alınır. Giriş gerektiren her yanıt, önbelleğe alınamaz olarak işaretlenir ve bu işaret uygulama katmanında üretilir, panel ayarına bırakılmaz. Oturum verisi merkezi bir depoda tutulur, böylece sunucu sayısı arttığında davranış değişmez. Kimlik yenileme, giriş ve yetki değişimi noktalarına gömülüdür; geliştiricinin hatırlamasına bırakılmaz.
Bunun üstüne bir de gözlemlenebilirlik katmanı gelir: her oturum açılışı, IP değişimi ve eşzamanlı cihaz sayısı kayıt altına alınır. Böylece "bu müşteri gerçekten mi başkasının verisini gördü" sorusuna tahminle değil kayıtla cevap verirsin. Özellikler bölümünde bu güvenlik zincirinin hangi başlıklar altında toplandığını, fiyat bölümünde ise hangi pakette hangi log derinliğinin geldiğini görebilirsin.
| Kontrol maddesi | Nerede bakılır | Beklenen durum | Öncelik |
|---|---|---|---|
| Oturumlu sayfalarda önbellek kapalı mı | Yanıt başlıkları | Kişiye özel, saklanamaz | Kritik |
| CDN kuralı HTML'i önbelleklemiyor mu | CDN önbellek kuralları | Yalnızca statik dosyalar | Kritik |
| Oturum çerezi güvenli bayraklı mı | Tarayıcı geliştirici aracı | Güvenli ve betikten erişilemez | Yüksek |
| Girişte kimlik yenileniyor mu | Giriş öncesi/sonrası çerez | Değer değişmeli | Yüksek |
| Oturum deposu merkezi mi | Sunucu yapılandırması | Redis veya eşdeğeri | Orta |
| Oturum olayları loglanıyor mu | Yönetim paneli kayıtları | IP, cihaz, zaman damgası | Orta |
| Eşzamanlı oturum sınırı var mı | Güvenlik ayarları | Hesap başına tanımlı | İsteğe bağlı |
Oturum güvenliğini şansa bırakma
Önbellek, oturum deposu ve kimlik yenileme zincirini kutudan çıktığı gibi doğru kurulmuş bir altyapıyla çalıştır.
Oturum karışması veritabanı hatası mıdır?
Hayır. Vakaların büyük çoğunluğunda veritabanı tamamen tutarlıdır. Sorun, kişiye özel HTML çıktısının bir önbellek katmanında saklanıp başka kullanıcıya sunulmasıdır.
CDN'i tamamen kapatsam sorun biter mi?
Çoğu durumda biter ama bu bir çözüm değil, bir kayıptır. Doğru yaklaşım statik dosyaları önbellekte tutup oturumlu sayfaları önbellek dışına almaktır.
Neden sadece yoğun saatlerde oluyor?
Önbellek isabeti için aynı adrese kısa sürede birden fazla istek gerekir. Düşük trafikte bu pencere neredeyse hiç oluşmaz, kampanya saatlerinde ise sürekli oluşur.
Müşteriye ne söylemeliyim?
Verilerin sızmadığını, görüntüleme katmanında bir önbellek hatası yaşandığını ve düzeltildiğini açıkça yaz. Oturum kayıtların varsa ilgili hesabın hiçbir işlem yapmadığını da kanıtla.
Oturum güvenliği, satın alma kararını fiyattan daha çok etkileyen ama vitrinde görünmeyen bir özelliktir. Kurulumun bu zinciri baştan doğru kuruyor mu, yoksa her sorunda sana mı bırakıyor; bunu en hızlı anlamanın yolu sistemi kendi gözünle çalıştırmaktır. canlı demo üzerinden iki farklı hesapla eş zamanlı giriş yapıp panelin nasıl davrandığını birkaç dakikada test edebilir, ardından paket seçimine geçebilirsin.