E-pin Scriptinin Yönetim Panelinde Sessizce Bekleyen İki Açık: CSRF ve XSS'in Bakiyeni Tek Tıkla Nasıl Boşalttığını Sana Kimse Anlatmadı

Çoğu panel sahibi güvenliği sunucu tarafında biten bir iş sanır. Güçlü şifre koydun, iki aşamalı doğrulamayı açtın, SSL sertifikan yeşil yanıyor ve hosting firman "günlük yedek alıyoruz" diyor. Bu tabloya bakıp rahatlamak çok kolay. Oysa e-pin satışında yaşanan kayıpların büyük bölümü sunucuya sızmakla değil, senin kendi tarayıcını kullanarak gerçekleşiyor. Saldırgan panele girmeye çalışmaz; girmiş olan kişiye, yani sana, istemediğin bir işlemi yaptırır.

İşte tam burada iki isim devreye giriyor: CSRF ve XSS. İkisi de yeni değil, ikisi de egzotik değil, ama e-pin panellerinde neredeyse standart hâlde duruyorlar. Çünkü bir e-pin satış scripti doğası gereği üç şeyi bir arada barındırır: anında para hareketi, anlık teslim edilen stok ve müşterinin serbestçe metin girebildiği alanlar. Bu üçlü, tarayıcı tabanlı saldırılar için biçilmiş kaftandır. Bu yazıda o sessiz açıkların panelinde nerelerde durduğunu, hangi ekranda nasıl patladığını ve satın alacağın dijital ürün satış yazılımında neye bakman gerektiğini tek tek açacağım.

CSRF gerçekten "senin tıkladığın" bir şey mi, yoksa tıklattırılan mı?

CSRF'in mantığı acımasız derecede basittir. Panele giriş yaptığında tarayıcın bir oturum çerezi tutar ve o çerezi, o alan adına giden her isteğe otomatik ekler. İsteği kimin başlattığını sormaz. Yani bir forumda gördüğün masum bir görsel etiketi, bir Telegram grubundaki kısaltılmış bağlantı ya da "bayilik başvurusu" diye gelen bir HTML dosyası, arka planda senin panelindeki bakiye ekleme adresine istek gönderirse, sunucu bunu yetkili yöneticinin talebi olarak okur.

Burada kritik nokta şu: saldırganın şifreni bilmesine gerek yok. Cevabı görmesine bile gerek yok. Tek ihtiyacı, işlemin tetiklenmesi. Bakiye yükleme, sipariş iadesi, kullanıcı yetkisi değiştirme, kupon oluşturma gibi tek adımda sonuç üreten ekranlar bu yüzden en değerli hedefler. Doğru kurulmuş bir e-pin scripti her durum değiştiren isteğe oturuma bağlı, tek kullanımlık bir token ekler ve sunucu tarafında bu token'ı sabit zamanlı karşılaştırmayla doğrular. Token yoksa istek reddedilir; token eskiyse reddedilir; token başka bir oturuma aitse reddedilir. Buna ek olarak çerezlerin SameSite değerinin en az Lax olması, dış kaynaklı POST isteklerinin çerezi taşımasını baştan engeller.

XSS neden "sadece bir uyarı penceresi" değil?

İnternette XSS anlatan içerikler genelde ekrana bir uyarı kutusu çıkararak biter ve insan "tamam, ne olacak ki" der. E-pin panelinde olan şey çok daha sıkıcı ve çok daha pahalıdır. Saldırgan destek talebine, sipariş notuna veya bayi profil başlığına bir betik yerleştirir. Sen o talebi yönetim ekranında açtığın anda betik senin yetkinle çalışır. Oturum bilgini dışarıya taşır, panelde gizli bir istek gönderir, hatta CSRF korumasını okuyup token'ı kendi isteğine ekler. Yani XSS varsa, CSRF koruman da anlamını yitirir.

Depolanan XSS'in en tehlikeli tarafı gecikmeli patlamasıdır. Kayıt bugün girilir, sen üç gün sonra o sayfayı açarsın, olay o an gerçekleşir. Kayıtlarda "yönetici giriş yaptı, bir sayfa açtı, bir işlem yaptı" yazar. Hiçbir şey tuhaf görünmez. Bu yüzden bir epin yazılım değerlendirirken "XSS filtremiz var" cümlesiyle yetinme; çıktının nerede kaçışlandığını sor. Doğru cevap, girdiyi kaydederken temizlemek değil, ekrana basarken bağlama göre kaçışlamaktır: HTML gövdesinde, etiket niteliğinde, JavaScript bloğunda ve URL içinde kurallar birbirinden farklıdır.

Panelini yönetici olarak gezerken farkında olmadığın risk nedir?

Yönetici oturumu açıkken internette dolaşmak, kasanın kapağını açık bırakıp dükkândan çıkmaya benzer. Aynı tarayıcıda aynı anda bayi forumları, rakip siteler, e-posta ekleri ve reklam panelleri açıksa, CSRF için gereken ortam hazırdır. Pratik disiplin şu: yönetim işlerini ayrı bir tarayıcı profilinde yap, işini bitirince oturumu kapat, panel için uzun süreli "beni hatırla" seçeneğini kullanma.

Yazılım tarafında beklentin ise oturum ömrünün kısa olması, hassas işlemler öncesi şifre veya doğrulama kodu istenmesi ve yetki yükseltme gerektiren her adımın ayrı kayda geçmesidir. Pinova gibi lisanslı bir e-pin satış yazılımında bu katmanların hazır gelmesi beklenir; çünkü bunları sonradan eklemek, çalışan bir panelin her formuna tek tek dokunmak anlamına gelir ve o noktada bir yeri atlama olasılığın neredeyse kesindir.

Token koydum, iş bitti mi?

Hayır, ve bu en sık yapılan hata. Token'ı forma yazdırmak yeterli değil; sunucunun onu gerçekten kontrol etmesi gerekiyor. Sahada gördüğüm klasik hatalar şunlar: token üretilip doğrulanmaması, tek bir sabit değerin bütün kullanıcılar için kullanılması, doğrulamanın yalnızca POST'ta yapılıp durum değiştiren GET adreslerinin açıkta bırakılması ve AJAX çağrılarının kontrol dışı tutulması. Modern panellerin çoğu iş mantığını JavaScript üzerinden yürüttüğü için, asıl açık o AJAX uçlarında saklanıyor.

İkinci katman olarak içerik güvenlik politikası devreye girmeli. Satır içi betiğe izin vermeyen, yalnızca kendi alan adından kaynak yükleyen bir politika, XSS'in yüzde yüzünü değil ama istismar edilebilirliğinin çok büyük kısmını kapatır. Buna HttpOnly ve Secure işaretli çerezleri, katı çerez yolu tanımını ve yönetim dizininin ayrı bir alt yol altında olmasını ekle. Tek başına hiçbiri sihirli değil; birlikte savunma derinliği kuruyorlar.

Bu açıkların faturasını kim ödüyor?

E-pin işinde zarar iki katmanlı gelir. Birincisi doğrudan kayıp: haksız yazılan bakiye, bedava teslim edilen kod, tedarikçiye ödenmiş ama satılmamış stok. İkincisi ve daha uzun soluklusu itibar kaybı. Bayilerin senin paneline güvenerek kendi müşterilerine satış yapıyor. Tek bir oturum devralma olayı, bayi cüzdanlarında hareket oluşturursa geri kazanmak aylar sürer. Ödeme sağlayıcının gözünde de itiraz oranı yükselir ve bu, komisyon pazarlığından tamamen hesap kapanmasına kadar giden bir zincirin ilk halkasıdır.

Bu yüzden güvenlik, dijital ürün satış scripti seçiminde sonradan bakılacak bir madde değil, ilk üç maddeden biri olmalı. Kendi geliştiricine sıfırdan yazdırmak cazip görünür ama CSRF token yönetimi, çıktı kaçışlama disiplini ve yetki matrisi gibi konular, her biri ayrı ayrı test edilmesi gereken alanlar. Hazır ve bakımı süren bir altyapıyla başlamak, bu maddelerin çoğunu ilk günden kapatmak demek.

Hangi sırayla ilerlemelisin?

Önce envanter çıkar: panelde durum değiştiren tüm adresleri listele. Sonra her birine token doğrulaması ekle ve doğrulamanın gerçekten çalıştığını, yukarıdaki kontrol tablosundaki gibi kırmaya çalışarak test et. Ardından çıktı katmanına geç; kullanıcıdan gelen her verinin ekrana basıldığı noktaları tara ve kaçışlamayı bağlama göre uygula. Üçüncü adımda çerez ve başlık sertleştirmesini yap. Son adımda ise kayıt tutmayı iyileştir: kim, hangi IP'den, hangi işlemi, hangi tutarla yaptı sorusunun cevabı tek ekrandan okunabilmeli.

Bu sıralamanın mantığı şu: token disiplini en hızlı kazanımı verir, kaçışlama en kalıcı korumayı sağlar, sertleştirme istismar maliyetini yükseltir, kayıt tutma ise bir gün bir şey olursa ne olduğunu anlayabilmeni mümkün kılar. Panelinin hangi özellikleri hazır sunduğunu görmek için özellik listesine bakabilir, kurulum ve lisans tarafını fiyat bölümünde değerlendirebilirsin.

Güvenlik, bir gün oturup bitirdiğin bir görev değil; panelinin her yeni ekranıyla birlikte tekrar sorulan bir soru. Yeni bir ödeme yöntemi, yeni bir bayi raporu veya yeni bir kampanya modülü eklediğin her seferde "bu ekranda durum değiştiren bir istek var mı, kullanıcı verisi nereye basılıyor" diye sormayı alışkanlık yap. Bu disiplini sıfırdan kurmak yerine hazır kurulmuş bir yapının üzerine oturmak istiyorsan, token doğrulamadan işlem kayıtlarına kadar tüm katmanların nasıl çalıştığını canlı demo üzerinden kendi gözünle inceleyebilir, kendi senaryolarını deneyerek karar verebilirsin.