API Güvenliği: Bahis Platform Geliştiricileri için Rehber

Bahis platformlarının API'leri; bakiyeleri, kuponları, ödeme akışlarını ve kişisel verileri taşır. Bu yüzden saldırganlar için cazip hedeflerdir ve bir açığın bedeli çoğu zaman doğrudan paraya dönüşür. Pek çok ekip geliştirme sırasında işlevselliğe odaklanır, güvenlik kontrollerini sonraya bırakır; sonradan fark edilen açıklar ise en pahalı anda, yoğun bir maç gününde ortaya çıkar. Bu rehberde bahis API'lerinde en sık görülen açıkları, düzeltme yollarını ve OWASP API Security Top 10 listesinin bahis sektörüne nasıl yansıdığını ele alıyoruz.

IDOR: başka oyuncunun verisine erişim

IDOR (Insecure Direct Object Reference), OWASP listesinde API1 olarak geçen nesne düzeyinde yetkilendirme hatasının en bilinen örneğidir. GET /api/bets/12345 isteği, kaynağın kime ait olduğunu kontrol etmeden bahsi döndürüyorsa, saldırgan kimlikleri sırayla deneyerek başka oyuncuların kupon geçmişine ulaşabilir. Düzeltme her zaman sunucu tarafındadır: sorgu, kaynağı hem kimliğiyle hem de isteği yapan kullanıcıyla eşleştirmelidir.

-- Yanlış: yalnızca kimlikle arama
SELECT id, stake, odds, status FROM bets WHERE id = $1;

-- Doğru: sahiplik sorgunun parçası
SELECT id, stake, odds, status
FROM bets
WHERE id = $1 AND user_id = $2;

Tahmin edilebilir sıralı kimlikler yerine rastgele ve uzun kimlikler kullanmak ek bir katman sağlar, ancak yetkilendirme kontrolünün yerini tutmaz. Kaynak bulunamadığında ve kaynak başkasına ait olduğunda aynı yanıtı dönmek de önemlidir; aksi halde saldırgan hangi kimliklerin var olduğunu yanıt farkından öğrenir.

Kimlik doğrulama ve JWT hataları

• Algoritma karmaşası: Kütüphane "alg: none" ya da beklenmeyen bir algoritmayı kabul ediyorsa imza doğrulaması atlatılabilir. Kabul edilen algoritmaları açıkça sabitle.
• Zayıf gizli anahtar: HS256 ile imzalanan jetonlarda kısa ya da tahmin edilebilir bir anahtar kaba kuvvetle kırılabilir. En az 256 bit rastgele anahtar kullan.
• Uzun ömürlü jetonlar: Erişim jetonları kısa ömürlü olmalı, yenileme jetonları kullanıldıkça döndürülmeli ve sunucuda iptal edilebilmeli.
• Eksik talep doğrulaması: Yayıncı (iss), hedef kitle (aud) ve süre (exp) alanlarını her istekte kontrol et.
• Aşırı geniş kapsam: Bir jeton yalnızca gerektiği kadar yetki taşımalı; çalınması durumunda zarar bu sayede sınırlı kalır.

İmzalı istekler ve yeniden oynatma koruması

Sunucudan sunucuya entegrasyonlarda her istekte statik bir API anahtarı göndermek, anahtar bir log dosyasına ya da ara sunucuya düştüğünde tüm korumanın kaybolması demektir. Daha sağlam bir desen, isteği paylaşılan bir gizli anahtarla imzalamak ve imzaya zaman damgası ile tek kullanımlık bir değer (nonce) eklemektir. Böylece yakalanan bir istek ne değiştirilebilir ne de tekrar gönderilebilir. Gizli anahtarların nerede ve nasıl tutulacağını API anahtar saklama yazımızda anlattık.

LLCBullet'in kişisel API anahtarları bu deseni kullanır: jeton isteği HMAC-SHA256 ile imzalanır, zaman damgası en fazla 5 dakika sapabilir, her nonce yalnızca bir kez kabul edilir ve alınan erişim jetonu 15 dakika geçerlidir. Anahtarlar kapsamla sınırlandırılır; isteğe bağlı IP izin listesi hem jeton alınırken hem de her istekte kontrol edilir. Tasarımın ayrıntıları kişisel API anahtarları rehberinde.

Hız sınırı ve kaynak tüketimi

OWASP listesinde API4 olarak geçen sınırsız kaynak tüketimi, bahis platformlarında hem hizmet kesintisi hem de dolandırıcılık riskidir. Yalnızca IP bazlı hız sınırı, IP rotasyonu yapan botlarla kolayca aşılır.

• Hız sınırını IP, kullanıcı ve jeton düzeyinde birlikte uygula.
• Giriş, çekim talebi ve bonus talebi gibi hassas uçlara ayrı ve daha sıkı limitler koy.
• Sayfalamada üst sınır belirle; tek istekte binlerce kayıt döndürme.
• İstek gövdesinin boyutuna ve JSON iç içe geçme derinliğine sınır koy.
• Aynı hesabın kısa sürede çok sayıda farklı IP'den istek yapmasını anomali olarak işaretle.

Otomatik trafiğe karşı daha geniş önlemler için bot saldırılarından korunma yazımıza bakabilirsin.

Bahis tutarı ve bakiye doğrulaması

İş mantığı hataları, klasik açıklardan daha pahalıya patlayabilir. Negatif bahis tutarı kabul eden bir uç nokta bakiyeyi artırır; ondalık hassasiyeti sınırlanmamış bir alan yuvarlama manipülasyonuna açık kalır. Tutarı sunucuda bir şemayla doğrula, parayı kayan noktalı sayı yerine tam sayı (kuruş) ya da decimal tipinde tut ve bakiye düşümünü tek bir atomik işlemde yap. Aynı kuponun iki kez gönderilmesine karşı istekleri bir idempotency anahtarıyla eşleştir. İstemci tarafındaki kontroller yalnızca kullanıcı deneyimi içindir, güvenlik sınırı değildir.

OWASP API Top 10 bahis perspektifinden

• API1 – Nesne düzeyinde yetkilendirme: Başka oyuncunun kuponu, işlemi ya da belgesi.
• API2 – Kimlik doğrulama: Zayıf jeton yönetimi, sonlandırılmayan oturumlar.
• API3 – Nesne özelliği düzeyinde yetkilendirme: İstek gövdesinde bakiye ya da VIP seviyesi gibi alanların değiştirilebilmesi.
• API5 – Fonksiyon düzeyinde yetkilendirme: Oyuncu jetonuyla yönetici uçlarına erişilebilmesi.
• API6 – Hassas iş akışları: Kayıt ya da bonus talebi akışının otomasyonla toplu kötüye kullanımı.
• API7 – SSRF: Kullanıcının verdiği URL'ye sunucunun istek atması. Webhook gibi özelliklerde yerel ve özel ağ adreslerini reddet; LLCBullet webhook görevleri de bu nedenle yalnızca herkese açık HTTPS adreslerine gönderim yapar ve yönlendirmeleri izlemez.
• API8 – Yanlış yapılandırma: CORS'ta joker karakter, üretimde açık bırakılmış hata ayıklama uçları, ayrıntılı hata mesajları.
• API9 – Envanter yönetimi: Unutulmuş eski API sürümlerinin ve test ortamlarının açık kalması.
• API10 – Güvensiz API tüketimi: Oran ya da ödeme sağlayıcısından gelen verinin doğrulanmadan işlenmesi.

Sonuç

Bahis API'lerinde güvenlik; her istekte sahipliği doğrulamak, jetonları kısa ömürlü ve dar kapsamlı tutmak, hassas uçları ayrı sınırlarla korumak ve para hesaplarını sunucuda atomik yapmakla başlar. Bu kontrolleri geliştirme sürecinin başına koymak, sonradan yama yapmaktan her zaman ucuzdur.

API anahtarları rehberini oku