BOLA ve IDOR Zafiyetinin Derinlikleri: REST ve GraphQL API'leri Nasıl Sömürülür?

Modern mikroservis mimarilerindeki en yaygın ve en tehlikeli ölüm sebebi, sunucuların çökerilmesi veya kriptografik algoritmaların kırılması değildir. Milyonlarca kullanıcının verisi, genellikle çok daha basit ancak otomatik kod analizi araçlarıyla bulunması neredeyse imkansız olan bir mantık hatası üzerinden çalınır: BOLA (Broken Object Level Authorization), eski adıyla IDOR (Insecure Direct Object Reference).

OWASP API Top 10 listesinde yıllardır zirvedeki yerini kimseye bırakmayan BOLA, modern REST ve GraphQL mimarilerinde geliştiricilerin objeler üzerinde yetkilendirme (authorization) kontrolü yapmayı unutmasından kaynaklanır.

Bir Senior Offensive Security uzmanının gözünden BOLA zafiyetinin nasıl sömürüldüğünü (exploit) ve Eresus Security'nin otonom ajanlarıyla bu mantık hatalarının nasıl kökünden kazındığını teknik bir vaka üzerinden inceleyelim.

---

1. BOLA (IDOR) Zafiyetinin Anatomisi

Sisteme geçerli kimlik bilgileriyle (örneğin geçerli bir JWT token) giriş yapmış standart bir "User A" düşünün. Bu kullanıcı kendi banka hesap detaylarını görmek için backend'e şu isteği gönderiyor:

GET /api/v2/accounts/8475
Host: api.banka.com
Authorization: Bearer <User_A_Token>

Sunucu tarafındaki (Backend) kod mantığı ise basitçe şöyledir:

// Güvensiz Backend Kodu
app.get('/api/v2/accounts/:id', async (req, res) => {
    // SADECE kimlik doğrulaması yapıyor, nesne yetki doğrulaması YOK!
    const account = await Database.getAccountById(req.params.id);
    return res.json(account);
});

BOLA zafiyeti tam olarak burada başlar. Geliştirici, isteği yapan kullanıcının "Sisteme kayıtlı olup olmadığını" kontrol eder (Authentication), fakat kullanıcının "Sorguladığı 8475 numaralı hesaba erişim yetkisinin olup olmadığını" kontrol etmez (Authorization).

Bir saldırgan izinsiz şekilde başka birisinin kimlik numarasını, banka bakiyesini veya adresini çekmek için sadece URL parametresindeki 8475 ID'sini 8476 olarak değiştirir (Fuzzing).

GET /api/v2/accounts/8476
Host: api.banka.com
Authorization: Bearer <User_A_Token>

Sonuç: Saniyeler içinde binlerce kullanıcının şahsi verileri sızdırılır.

---

2. Geleneksel Tarayıcılar (Scanner) BOLA'yı Neden Bulamaz?

Elinizde on binlerce dolarlık geleneksel bir DAST harici tarama aracı (Scanner) veya SAST statik kod analiz aracı olabilir. Ancak hiçbiri BOLA zafiyetini yakalayamaz. Neden mi?

Çünkü BOLA bir söz dizimi (syntax) değil, bir iş mantığı (business logic) hatasıdır. Geleneksel tarayıcılar için /api/v2/accounts/8476 isteğine dönen 200 OK HTTP kodu tamamen yasal ve geçerlidir. Tarayıcı (Scanner), sizin 8475 veya 8476 numaralı müşterilerden hangisi olduğunuzu, kimin neye yetkisi olup olmadığını bilemez. Uygulama mantığına sağır ve kördür.

---

3. GraphQL Üzerinden Karmaşık BOLA Hedefleri

BOLA sadece RESTful mimarilerde değil, GraphQL uç noktalarında (endpoints) çok daha ölümcül bir şekilde karşımıza çıkar. REST API'lerde geliştiriciler her uç nokta için genellikle yetkilendirme katmanları (middleware) yazar. Ancak GraphQL'de, ilişkisel veri hiyerarşisi nedeniyle yetkilendirmeler sıkça gözden kaçar.

Örnek Saldırı Payload'u: Standart bir e-ticaret platformunda kullanıcı kendi profilini çekerken:

query {
  user(id: "me") {
    name
    email
  }
}

Saldırgan (Attacker), nesne düzeyindeki esnekliği fırsat bilip sorguyu genişleterek başka bir kullanıcıya ait ödeme yöntemlerine sızmayı hedefler:

query {
  user(id: "1004") {
    name
    email
    creditCards {
      cardNumber
      cvv
    }
  }
}

Eğer Resolver fonksiyonları her seviyedeki veri (Node) için katı bir sahiplik (Ownership) doğrulaması yapmıyorsa, Graph ağacı istenilen her veriyi sızdıracaktır.

---

4. Otonom Ajanlar (Agentic Security) ile Kesin Çözüm: "Eresus Yaklaşımı"

Bir geliştirimci ekibiniz varsa, bu mantık hatalarını geleneksel araçlarla asla bulamazsınız. Canlı sistemlerde BOLA'yı tespit etmenin tek yolu, sistemi gerçek bir Red Team uzmanı gibi ele almak ve parametre-fuzzing operasyonlarını yetki matrisleriyle kıyaslamaktır.

İşte Eresus Security AI Otonom Ajanlarının geleneksel araçları çöpe atan çalışma şekli:

1. Rol Temelli Analiz (RBAC/ABAC Mapping): Ajan sistemlerinize bir "Admin", bir "User A" ve bir "User B" tanımlanır.
2. Davranış Dinamiği: Ajan, User A için ait olan referans ID'lerini çıkartır.
3. Çapraz Saldırı: Ajan otonom olarak User A kimliğiyle girip, User B'ye ait ID'lere erişmeye çalışır.
4. Mantıksal Kod Doğrulaması: Eğer Ajan User B'nin verisini çekerse, BOLA uyarısını patlatır ve kod deponuza doğrudan bir düzeltme önerisi (Örn: if(account.ownerId !== req.user.id) return HTTP 403) PR'ı yollar.

Kod tabanınızın ve API yapınızın içindeki görünmez mantık sızıntılarını durdurmak için siber güvenlikte "Ajan Mimarisine" geçiş yapın. Eresus Security uzmanlarıyla bugün iletişime geçin ve API'lerinizi güvence altına alın.

SSS

API güvenliği sadece endpoint taraması mıdır?

Hayır. Endpoint taraması yararlı bir başlangıçtır fakat gerçek API güvenliği object ownership, tenant isolation, rol sınırları, async iş akışları, webhook güveni ve maliyet suistimali gibi davranışları da test eder.

BOLA ve IDOR neden bu kadar kritik?

Çünkü saldırgan çoğu zaman karmaşık exploit yazmadan sadece başka bir nesnenin kimliğini deneyerek veri okuyabilir veya aksiyon tetikleyebilir. Bu hata özellikle SaaS ve fintech sistemlerinde doğrudan müşteri verisi riskine dönüşür.

Ne zaman profesyonel destek gerekir?

API birden fazla rol, müşteri, ödeme akışı, provider entegrasyonu veya hassas veri taşıyorsa manuel yetkilendirme testi gerekir. Scanner çıktısı bu iş mantığını tek başına doğrulayamaz.

Ek Kontrol Soruları

• Bu risk hangi varlıkları etkiliyor?
• Hangi kullanıcı rolleri bu akışa erişebiliyor?
• Aynı sorun başka endpoint veya entegrasyonda tekrar ediyor mu?
• Bulgunun müşteri verisine etkisi var mı?
• Loglardan olayın izi sürülebiliyor mu?
• Düzeltme sonrası retest nasıl yapılacak?
• Geçici önlem ile kalıcı çözüm ayrıldı mı?
• İş etkisi teknik ekibin dışında da anlaşılır mı?
• Benzer hata için önleyici kontrol eklenebilir mi?
• Ekip bu kontrolü release sürecine bağlayabilir mi?
• Gerekirse bağımsız doğrulama için hangi kanıtlar hazırlanmalı?
• Sonraki sprintte hangi iç bağlantı ve servis sayfası desteklemeli?