Web uygulamaları ve API güvenlik denetimlerinde otomatik tarama araçlarının (DAST) en yetersiz kaldığı alanların başında nesne seviyesinde yetkilendirme (BOLA / IDOR) zafiyetleri geliyor. Uygulamanın kimlik doğrulama katmanının sorunsuz çalışması, erişim denetiminin de doğru yapılandırıldığı anlamına gelmez. Birçok mimaride geçerli bir oturum bulunsa dahi, talep edilen kaynağın o oturumun yetki sınırları içinde olup olmadığı doğrulanmayabiliyor.
Bu yazıda konunun mimari arka planını, denetim süreçlerindeki analiz metodolojisini ve kod seviyesinde doğru çözüm yaklaşımlarını bir araya getirdim.
---
1. Mimari Hatalar ve Yaygın Yanılgılar
- Tahmin Edilemez ID (UUID) Yanılgısı:
Sistemlerde artan tam sayı (sequential ID) yerine UUID veya rastgele hash değerleri kullanılması yaygın bir savunma sanrısıdır. UUID sadece tahmin edilebilirliği zorlaştırır; nesne sahipliği kontrolünün yerini tutmaz. Public bir profil, log veya liste endpoint'inden elde edilen geçerli bir UUID, backend tarafında sahiplik kontrolü yapılmıyorsa kritik bir işlemde (güncelleme, silme, indirme) doğrudan yetkisiz erişim sağlayabilir.
- API Rotaları ve Versiyon Uyuşmazlıkları:
Modern mikroservislerde `/api/v2/orders/{id}` üzerinde katı yetki kuralları işletilirken, geriye dönük uyumluluk adına açık unutulan `/api/v1/orders/{id}` rotasında bu kontrollerin atlandığı senaryolar sıklıkla görülür.
- Metod ve Başlık Tabanlı Denetim Eksiklikleri:
Bazı erişim katmanları yalnızca GET isteklerini denetleyecek şekilde yapılandırıldığında; aynı nesneye PUT, PATCH veya DELETE istekleri atıldığında middleware katmanının atlanıp doğrudan controller'a erişilebildiği durumlar mevcuttur.
---
2. Denetim ve Test Metodolojisi
Otomasyon araçları nesneler arasındaki mantıksal iş kurallarını (business logic) yorumlayamadığı için bu denetimler metodolojik bir süreç gerektirir:
- Çift Oturum (Dual-Session) Analizi:
Sistem üzerinde aynı yetki seviyesinde iki farklı profil (Kullanıcı A ve Kullanıcı B) oluşturulur. Kullanıcı B'ye ait özel bir nesne referansı (fatura ID, doküman UUID vb.) belirlenir. Ardından Kullanıcı A'nın aktif oturum bilgileriyle bu nesneye istek gönderilir. Sunucunun 403 Forbidden veya 404 Not Found dönmek yerine veriyi Kullanıcı A'ya sunması yetkilendirme eksikliğini doğrular.
- Yetki Matrisi Çıkarılması:
Tüm API rotaları ve bunlara ait HTTP metodları listelenerek her bir endpoint için "Yetkisiz Erişim / Farklı Kullanıcı Erişimi / Kendi Erişimi" matrisi çıkarılır. Bu yöntem, hangi controller'ların merkezi filtreye dahil edilip hangilerinin geliştirici inisiyatifinde kaldığını gösterir.
- Proxy Seviyesinde Doğrulama:
Denetim laboratuvarlarında proxy araçlarının Match & Replace veya oturum karşılaştırma eklentileri (AuthMatrix, Authorize vb.) kullanılarak, bir oturumda gezilirken gönderilen isteklerin arka planda diğer oturumun token'ı ile otomatik yinelenmesi sağlanır. Yanıt durum kodları ve gövde boyutları karşılaştırılarak şüpheli uç noktalar ayrıştırılır.
---
3. Kod Düzeyinde Güvenli Tasarım (Remediation)
Zafiyetin temel kaynağı, veri tabanı sorgularında nesnenin yalnızca istemciden gelen parametreye göre çekilmesidir.
Hatalı Tasarım:
Sorgu doğrudan URL parametresiyle çalıştırıldığında nesne sahipliği doğrulanmaz:
SELECT * FROM documents WHERE id = :doc_id
Güvenli Tasarım:
Sorgu katmanında, istemciden gelen ID'nin yanı sıra oturumdan (session context) gelen kullanıcı kimliği zorunlu bir koşul olarak eklenmelidir:
SELECT * FROM documents WHERE id = :doc_id AND user_id = :current_user_id
Temel Güvenlik İlkeleri:
1. Merkezi Yetkilendirme (RBAC / ABAC): Yetki kontrolleri controller seviyesinde dağınık bırakılmamalı; merkezi bir middleware katmanında zorunlu tutulmalıdır.
2. İndirekt Referans Kullanımı: Hassas dahili anahtarlar doğrudan istemciye verilmemeli, oturum bazlı geçici haritalar (indirect mapping) tercih edilmelidir.
3. Varsayılan Olarak Reddet (Deny by Default): Uç noktalar tanımlanırken açıkça yetkilendirilmemiş tüm roller için erişim kısıtlanmalıdır.
Siz API mimarilerini tasarlarken veya denetlerken nesne seviyesinde yetkilendirmeyi merkezi bir middleware ile mi çözüyorsunuz, yoksa ORM/sorgu seviyesinde scoping kurallarıyla mı ilerliyorsunuz?
Bu yazıda konunun mimari arka planını, denetim süreçlerindeki analiz metodolojisini ve kod seviyesinde doğru çözüm yaklaşımlarını bir araya getirdim.
---
1. Mimari Hatalar ve Yaygın Yanılgılar
- Tahmin Edilemez ID (UUID) Yanılgısı:
Sistemlerde artan tam sayı (sequential ID) yerine UUID veya rastgele hash değerleri kullanılması yaygın bir savunma sanrısıdır. UUID sadece tahmin edilebilirliği zorlaştırır; nesne sahipliği kontrolünün yerini tutmaz. Public bir profil, log veya liste endpoint'inden elde edilen geçerli bir UUID, backend tarafında sahiplik kontrolü yapılmıyorsa kritik bir işlemde (güncelleme, silme, indirme) doğrudan yetkisiz erişim sağlayabilir.
- API Rotaları ve Versiyon Uyuşmazlıkları:
Modern mikroservislerde `/api/v2/orders/{id}` üzerinde katı yetki kuralları işletilirken, geriye dönük uyumluluk adına açık unutulan `/api/v1/orders/{id}` rotasında bu kontrollerin atlandığı senaryolar sıklıkla görülür.
- Metod ve Başlık Tabanlı Denetim Eksiklikleri:
Bazı erişim katmanları yalnızca GET isteklerini denetleyecek şekilde yapılandırıldığında; aynı nesneye PUT, PATCH veya DELETE istekleri atıldığında middleware katmanının atlanıp doğrudan controller'a erişilebildiği durumlar mevcuttur.
---
2. Denetim ve Test Metodolojisi
Otomasyon araçları nesneler arasındaki mantıksal iş kurallarını (business logic) yorumlayamadığı için bu denetimler metodolojik bir süreç gerektirir:
- Çift Oturum (Dual-Session) Analizi:
Sistem üzerinde aynı yetki seviyesinde iki farklı profil (Kullanıcı A ve Kullanıcı B) oluşturulur. Kullanıcı B'ye ait özel bir nesne referansı (fatura ID, doküman UUID vb.) belirlenir. Ardından Kullanıcı A'nın aktif oturum bilgileriyle bu nesneye istek gönderilir. Sunucunun 403 Forbidden veya 404 Not Found dönmek yerine veriyi Kullanıcı A'ya sunması yetkilendirme eksikliğini doğrular.
- Yetki Matrisi Çıkarılması:
Tüm API rotaları ve bunlara ait HTTP metodları listelenerek her bir endpoint için "Yetkisiz Erişim / Farklı Kullanıcı Erişimi / Kendi Erişimi" matrisi çıkarılır. Bu yöntem, hangi controller'ların merkezi filtreye dahil edilip hangilerinin geliştirici inisiyatifinde kaldığını gösterir.
- Proxy Seviyesinde Doğrulama:
Denetim laboratuvarlarında proxy araçlarının Match & Replace veya oturum karşılaştırma eklentileri (AuthMatrix, Authorize vb.) kullanılarak, bir oturumda gezilirken gönderilen isteklerin arka planda diğer oturumun token'ı ile otomatik yinelenmesi sağlanır. Yanıt durum kodları ve gövde boyutları karşılaştırılarak şüpheli uç noktalar ayrıştırılır.
---
3. Kod Düzeyinde Güvenli Tasarım (Remediation)
Zafiyetin temel kaynağı, veri tabanı sorgularında nesnenin yalnızca istemciden gelen parametreye göre çekilmesidir.
Hatalı Tasarım:
Sorgu doğrudan URL parametresiyle çalıştırıldığında nesne sahipliği doğrulanmaz:
SELECT * FROM documents WHERE id = :doc_id
Güvenli Tasarım:
Sorgu katmanında, istemciden gelen ID'nin yanı sıra oturumdan (session context) gelen kullanıcı kimliği zorunlu bir koşul olarak eklenmelidir:
SELECT * FROM documents WHERE id = :doc_id AND user_id = :current_user_id
Temel Güvenlik İlkeleri:
1. Merkezi Yetkilendirme (RBAC / ABAC): Yetki kontrolleri controller seviyesinde dağınık bırakılmamalı; merkezi bir middleware katmanında zorunlu tutulmalıdır.
2. İndirekt Referans Kullanımı: Hassas dahili anahtarlar doğrudan istemciye verilmemeli, oturum bazlı geçici haritalar (indirect mapping) tercih edilmelidir.
3. Varsayılan Olarak Reddet (Deny by Default): Uç noktalar tanımlanırken açıkça yetkilendirilmemiş tüm roller için erişim kısıtlanmalıdır.
Siz API mimarilerini tasarlarken veya denetlerken nesne seviyesinde yetkilendirmeyi merkezi bir middleware ile mi çözüyorsunuz, yoksa ORM/sorgu seviyesinde scoping kurallarıyla mı ilerliyorsunuz?
