Vaka Çalışması: Fintech API Pentestinde BOLA/IDOR Zinciri

Bu yazı, iki taraflı NDA kapsamında tamamlanan bir angajmandan; müşteri, uç nokta ve veri detayları anonimleştirilerek derlenmiştir. Amaç, benzer mimarilere sahip ekiplere somut bir test ve düzeltme referansı sunmaktır.

Müşteri Profili ve Kapsam

Sektör: Ödeme kuruluşu (lisanslı, KVKK ve PCI DSS kapsamında)

Sistem: Çok kiracılı (multi-tenant) ödeme API'si — kiracı bazında izole edilmiş işlem geçmişi, webhook bildirimleri ve yönetim paneli

Angajman tipi: 2 haftalık siyah kutu API sızma testi + yetkili hesaplarla gri kutu doğrulama

Kural: Otomatik tarayıcı çıktısı raporlanmaz; her bulgu için istismar kanıtı (PoC) üretilir.

Keşif Fazı: Saldırı Yüzeyinin Haritası

İlk üç gün standart keşif: OpenAPI şeması tersine mühendislik, JWT yapısının çözümlenmesi, rol bazlı uç nokta matrisinin çıkarılması. İki sinyal dikkat çekti:

Kiracı kimliği (tenant ID) JWT'de değil, istek gövdesinde taşınıyordu — sunucu tarafı yetkilendirmenin istemci verisine dayandığı anlamına gelir.
İşlem listeleme uç noktası sayfalama parametrelerinde monoton artan bir internal kayıt ID'si kabul ediyordu.

Kritik Bulgu: BOLA Zinciri (CVSS 9.1)

GET /v1/transactions/{id} uç noktasında, A kiracısına ait yetkili bir oturumla B kiracısının işlem ID'si istendiğinde HTTP 200 ve tam işlem detayı döndü. Sunucu, kayıt sahipliğini doğrulamıyordu; sadece oturum geçerliliğini kontrol ediyordu.

Zinciri genişleten ikinci parça: işlem ID'leri monoton artıktı. Bu, IDOR'u tekil sızıntıdan toplu veri çıkarımına dönüştürüyordu — bir saldırgan script ile milyonlarca kaydı sıralayabilirdi.

Kanıtlenen etki: İşlem tutarı, karşı taraf adı, IBAN maskesi ve iç açıklama alanları. KVKK anlamında kişisel veri ihlali; PCI DSS anlamında kart sahibi verisi komşuluğu.

İkincil Bulgu: Webhook İmza Atlatması (CVSS 7.5)

Webhook doğrulaması HMAC imzasını X-Signature başlığından okuyor, ancak boş başlıkta doğrulamayı atlıyordu. Başlık tamamen çıkarıldığında sahte "ödeme başarılı" bildirimi kabul ediliyordu — sipariş durumunun ödeme olmadan güncellenebildiği bir ticari mantık hatası.

Düzeltme ve Yeniden Test

Rapor, her bulgu için kod düzeyinde düzeltme önerisiyle teslim edildi:

Bulgu	Düzeltme	Yeniden test
BOLA	Nesne sahipliği kontrolünün middleware'e taşınması, kiracı bağlamının JWT claim'inden zorlanması	48 saat sonra, çapraz kiracı isteklerin tamamı 403 ✓
Monoton ID	UUID v7'ye geçiş + hız limiti	Tahmin edilebilirlik kaldırıldı ✓
Webhook	Zorunlu imza, başlık yoksa reddetme, zaman damgası toleransı	Sahte bildirim reddedildi ✓

Toplam süre: keşiften yeniden test onayına 19 gün.

Benzer Mimaride Kontrol Edilecekler

Her kaynak erişiminde sunucu tarafı sahiplik doğrulaması var mı?
Kiracı bağlamı istemci verisinden mi, doğrulanmış token'dan mı geliyor?
Sıralı ID'ler dışa açılıyor mu?
Webhook/imza doğrulaması "yoksa atla" davranışında mı?
Yetkilendirme testleri otomatik regresyon testine dönüştürüldü mü?

Bu liste tek başına yeterli değildir — zincirleme saldırı yolları ancak gerçek istismar denemesiyle doğrulanır.

Angajman Zaman Çizelgesi: 19 Gün Nasıl Geçti?

Gün	Faz	Çıktı
1-3	Keşif	OpenAPI tersine mühendislik, uç nokta matrisi, JWT analizi
4-6	Kimlik doğrulama testi	JWT doğrulama zinciri, OAuth akışları, rol geçişleri
7-9	BOLA/IDOR avı	Çapraz kiracı test matrisi, ilk ispat (PoC)
10-11	Webhook ve iş mantığı	İmza atlatması, sahte bildirim senaryosu
12-13	Kanıt standardizasyonu	Her bulgu için yeniden üretilebilir PoC, CVSS skorlama
14-16	Rapor yazımı	Yönetici özeti + kod düzeyi düzeltme kılavuzu
17	Teslim + bulgu sunumu	Mühendislik ekibiyle canlı geçiş
18-19	Yeniden test	Düzeltmelerin doğrulanması, kapanış onayı

Kritik bulgunun (BOLA) ilk kanıtı 9. günde üretildi; müşteri, raporu beklemeden 10. gün düzeltmeye başladı. Bu, angajman kurallarımızın bir parçası: kritik bulgu, rapor yazımı beklemeden güvenli kanalla bildirilir.

Müşteri Bu Zinciri Kendi Nasıl Yakalardı?

Sızma testi sonrası en sık aldığımız soru: "Bunu tespit sistemimiz yakalardı mı?" Bu angajmandaki dürüst cevap: hayır. Nedenleri ve çözümleri:

1. Yetkilendirme hataları loglarda görünmez. Çapraz kiracı istek, sunucu açısından "geçerli oturumla normal istek"tir — HTTP 200 döner, alarm üretmez. Çözüm: Yetkilendirme middleware'inde sahiplik kontrolü reddi (403) için özel metrik; aynı oturumdan farklı kiracı ID'lerine gelen isteklerde anormallik alarmı.

2. WAF bu sınıf zafiyeti görmez. BOLA/IDOR, imza bazlı tespitin kör noktasıdır: istek tamamen meşru formattadır, yalnızca ID farklıdır. Çözüm: Uygulama katmanında yetkilendirme birim testleri + CI/CD'de yetkilendirme regresyon paketi.

3. Webhook atlatması sessizdir. İmzasız bildirim kabul edildiğinde logda "başarılı webhook" görünür. Çözüm: İmza doğrulama reddi sayacı; imzasız bildirim denemesi anında alarm.

Bu üç tespit kuralı, düzeltmeyle birlikte müşteriye teslim edildi ve SIEM'e eklendi. Sızma testinin ikinci değeri tam olarak budur: zafiyeti kapatmak + kapattığını izleyebilmek.

Bulguların İş Değeri: Sadece Teknik Risk Değil

Bulgu	Teknik etki	İş etkisi
BOLA zinciri	Çapraz kiracı veri erişimi	KVKK kişisel veri ihlali bildirimi, müşteri güveni, PCI DSS uyum riski
Monoton ID	Toplu veri çıkarımı	Toplu sızıntı = toplu bildirim yükümlülüğü
Webhook atlatması	Ödemesiz sipariş onayı	Doğrudan gelir kaybı, mutabakat bozulması

Yönetici sunumunda bu tabloyu göstermek, teknik bulgunun bütçe ve öncelik kazanmasını sağlar. Güvenlik bulgusu, iş diliyle anlatılmadığında backlog'un dibinde kalır.

Metodoloji Notları: BOLA Testinde Sistematik Yaklaşım

Bu angajmanda izlenen adımlar, benzer testlerde şablon oluşturur:

Kimlik matrisi: Her rol için (kiracı admin, kiracı kullanıcı, salt okunur) token al, uç nokta başına yetki beklentisi tablosu oluştur
Çapraz erişim otomasyonu: A rolü token'ıyla B rolünün kaynak ID'lerini otomatik dene; 200 dönen her kombinasyon şüpheli
ID semantiği: Monoton mu, UUID mi, şifreli mi? Monoton ise tahmin aralığı test et
Yanıt karşılaştırması: Sahiplik kontrolü olan uç nokta 403/404 döner; 200 + kısmi veri de bir sızıntı biçimidir (alan bazlı karşılaştır)
Zincir değerlendirmesi: Tek bulgunun zincirle birleşince etki derecesi değişir — CVSS'i zincir sonuna göre ver

Sık Sorulan Sorular

BOLA ve IDOR arasındaki fark nedir?

IDOR (Insecure Direct Object Reference) zafiyetin teknik adıdır: nesne referansının doğrudan kullanılıp yetkilendirmenin kontrol edilmemesi. BOLA (Broken Object Level Authorization) ise API Security Top 10'daki kategori adıdır ve aynı sorunun API bağlamındaki halini tanımlar. Pratikte aynı sorunu iki perspektiften isimlendirmenin farkıdır.

Sızma testinde bulgu raporlanmadan düzeltmeye başlamak doğru mu?

Kritik bulgular için evet — saldırı yolu canlıysa her gün risk demektir. Angajman kurallarımız: kritik bulgu, güvenli kanalla anında bildirilir; müşteri düzeltmeye başlar; rapor, tüm bulguların bağlamıyla teslim edilir. Düzeltme ile rapor paralel yürür, sıralı değil.

Çok kiracılı mimaride yetkilendirme testi nasıl kapsamlandırılır?

Kiracı sayısı kadar kombinasyon değil, rol × kaynak tipi matrisi test edilir: her rol için kendi kiracısındaki ve başka kiracıdaki kaynaklara erişim denemeleri. Matris, OpenAPI şemasından otomatik türetilebilir; manuel değerlendirme şüpheli kombinasyonlara odaklanır.

Pilot Kapsam Talebi

Ödeme veya finansal altyapınız için benzer bir doğrulama planlamak üzere görüşme talep edin. Kapsam önerisini 48 saat içinde döndürüyoruz.