Güvenlik Açığı Tarama: Bahis Sitesi Denetim Rehberi

Bahis platformları sürekli değişen bir saldırı yüzeyine sahiptir: yeni kampanya sayfaları, yeni ödeme yöntemleri, yeni API uçları. Her değişiklik, farkında olmadan yeni bir açık getirebilir. Düzenli güvenlik taraması bu açıkları kötü niyetli kişilerden önce bulmanın en pratik yoludur. Bu rehberde kendi sistemlerin için bir tarama düzeni kurmayı, hangi araçları kullanabileceğini ve bulguları nasıl önceliklendireceğini anlatıyoruz.

Önce kapsam ve yazılı izin

Güvenlik taraması yalnızca sahibi olduğun ya da yazılı olarak test etme iznin bulunan sistemlerde yapılır. Beyaz etiket ya da turnkey bir altyapı kullanıyorsan platformun önemli bir kısmı sağlayıcıya aittir; sağlayıcının sistemlerini izinsiz taramak sözleşme ihlali olabileceği gibi hukuki sonuçlar da doğurabilir. Taramaya başlamadan önce kapsamı yaz: hangi alan adları, hangi ortamlar (tercihen test ortamı), hangi zaman aralığı ve kimlerin haberdar olduğu. Canlı ortamda agresif taramalar performansı etkileyebilir ve güvenlik duvarını tetikleyebilir.

Temel araçlar

• OWASP ZAP: Ücretsiz ve açık kaynaklı web uygulama güvenlik tarayıcısı. Otomatik tarama ve elle keşif modları vardır; başlangıç için iyi bir noktadır.
• Burp Suite: Tarayıcı ile sunucu arasındaki trafiği yakalayıp incelemeni sağlayan proxy aracı. Form parametrelerini ve API isteklerini elle değiştirerek test etmek için kullanılır.
• Nikto: Web sunucusu yapılandırma sorunlarını, eski yazılım sürümlerini ve eksik başlıkları tarayan komut satırı aracı. Hızlı bir ilk bakış için uygundur.

Tarama öncelikleri

1. Giriş ve oturum yönetimi: Kimlik doğrulama, oturum çerezleri, çıkış ve oturum süresi davranışı.
2. Bahis ve kupon uç noktaları: Tutar, oran ve etkinlik kimliği gibi parametrelerin sunucu tarafında doğrulanması.
3. Ödeme akışları: Para yatırma ve çekme formları ile ödeme sağlayıcısından gelen geri çağrıların doğrulanması.
4. Yönetim paneli: Yetki kontrolleri, dışarıya açık olup olmadığı ve erişim kısıtları.
5. Yeni özellikler: Yayına çıkmadan önce ilgili uç noktaların ayrıca test edilmesi.

Bahis platformlarında sık görülen açık türleri

Enjeksiyon

Kullanıcıdan gelen verinin sorgulara doğrudan eklenmesiyle ortaya çıkar. Sayısal görünen parametreler, örneğin etkinlik ya da kupon kimliği, çoğu zaman gözden kaçar. Kalıcı çözüm, tüm sorgularda parametreli ifadeler kullanmak ve girdiyi sunucu tarafında türüne göre doğrulamaktır.

XSS (siteler arası betik çalıştırma)

Oyuncu adı, arama kutusu ya da destek mesajı gibi kullanıcı girdisinin kaçışsız biçimde sayfaya basılmasıyla oluşur. Yönetim panelinde görünen bir alandaki XSS, yönetici oturumunun ele geçirilmesine kadar gidebileceği için özellikle kritiktir.

IDOR (yetkisiz nesne erişimi)

Kupon, işlem ya da kullanıcı kimliğini değiştirerek başka bir oyuncunun verisine ulaşılabiliyorsa sunucu sahiplik kontrolü yapmıyor demektir. Her istekte kaynağın o kullanıcıya ait olup olmadığı sunucuda doğrulanmalıdır.

Kimlik doğrulama ve oturum zafiyetleri

Eksik çerez bayrakları (HttpOnly, Secure ve SameSite), çıkıştan sonra geçerli kalan oturumlar, giriş denemelerinde hız sınırı olmaması ve şifre sıfırlama akışlarındaki tahmin edilebilir bağlantılar bu gruptadır. Yönetim paneli için ikinci doğrulama adımı ve IP kısıtlaması riski belirgin biçimde azaltır.

İş mantığı hataları

Otomatik tarayıcıların en zor bulduğu açıklardır: aynı bonusun eşzamanlı isteklerle birden fazla kez alınması, oran değiştikten sonra eski oranla kupon onaylanması ya da bir çekim talebinin iki kez işlenmesi gibi. Bu tür senaryoları elle ve eşzamanlı isteklerle test etmek gerekir.

Güvenlik başlıklarını hızlıca kontrol etmek

Eksik güvenlik başlıkları en kolay düzeltilen bulgulardır. Kendi alan adında basit bir kontrol için şu komutu kullanabilirsin:

curl -sI https://ornek-alanadin.com | grep -iE "strict-transport-security|content-security-policy|x-frame-options|x-content-type-options|referrer-policy"

Çıktıda görünmeyen başlıklar eksik demektir. HSTS, içerik güvenlik politikası (CSP), çerçeveleme koruması ve MIME türü koruması temel sayılır; CSP'yi sıkılaştırırken sitenin kullandığı üçüncü taraf betikleri tek tek gözden geçirmek gerekir. TLS yapılandırması için SSL/TLS sertifika yönetimi rehberimize bakabilirsin.

Bulguları önceliklendirmek

Tarama araçları çok sayıda bulgu üretir ve bunların bir kısmı yanlış alarmdır. Her bulgu için iki soru sor: istismar edilmesi ne kadar kolay ve etkilenen veri ya da işlem ne kadar kritik? Oyuncu bakiyesine, ödeme akışına ya da yönetim paneline dokunan bulgular en üste çıkar. Düzeltmeden sonra aynı testi tekrarlayarak açığın gerçekten kapandığını doğrula. API tarafındaki kontroller için API güvenliği rehberimiz iyi bir tamamlayıcıdır.

Taramayı rutine bağlamak

Tek seferlik bir tarama, o günün fotoğrafıdır. Otomatik taramayı sürüm sürecine bağlamak, örneğin her büyük yayından önce test ortamında çalıştırmak, yeni açıkların üretime çıkmadan yakalanmasını sağlar. Bulguları bir iş takip aracında tutmak ve kapanan maddeleri bir sonraki taramada doğrulamak, aynı açığın tekrar tekrar geri gelmesini önler.

Ne zaman profesyonel pentest?

Kendi taramaların düzenli bakım içindir ve bilinen açık türlerini yakalar. Bağımsız bir güvenlik firmasının yaptığı sızma testi ise iş mantığı hatalarını ve zincirleme saldırı senaryolarını bulmakta çok daha başarılıdır. Ödeme entegrasyonunu değiştirdiğinde, büyük bir mimari güncellemeden önce ve lisans ya da iş ortağı gereksinimleri bunu istediğinde profesyonel test planlamak iyi bir pratiktir. Test sonucunda kritik bir açık bulunursa müdahale adımları için olay müdahale planı yazımıza göz atabilirsin.

Kısa kontrol listesi

• Kapsam ve izin yazılı olarak belirlendi mi?
• Tarama önce test ortamında mı yapılıyor?
• Giriş, bahis, ödeme ve yönetim uç noktaları kapsamda mı?
• Güvenlik başlıkları ve TLS yapılandırması kontrol edildi mi?
• Bulgular önceliklendirilip sorumlulara atandı mı?
• Düzeltmelerden sonra yeniden test yapıldı mı?