Selamlar,
Son dönemde incelediğim mimarilerde ve bug bounty raporlarında sıklıkla karşılaştığım bir tablo var: Güvenlik değerlendirmelerinde genellikle karmaşık enjeksiyon zafiyetlerine odaklanılırken, modern mikroservis ve reverse proxy mimarilerinin getirdiği yapılandırma ile mantık hataları gözden kaçabiliyor.
Özellikle erişim denetimi mekanizmaları, proxy-backend normalizasyon farkları ve yetkilendirme katmanlarındaki mimari açıklara dair sahada karşılaştığım pratik notları derlemek istedim.
---
1. Reverse Proxy & Backend Arasındaki Path Normalizasyon Uyuşmazlıkları
Ön yüzde Nginx, Envoy veya Cloudflare gibi bir proxy/WAF katmanı bulunup arkada Spring, Express veya Tomcat gibi uygulama sunucuları çalıştığında, URL parse etme mantıklarındaki RFC yorumlama farkları ciddi erişim denetimi bypass senaryolarına yol açabiliyor:
- Matrix Parametreleri ve Path Delimiter Tutarsızlığı: Proxy katmanı path bazlı kural işletirken `;` (matrix parameter) veya `%2e` gibi karakterleri statik kabul edip geçirebilirken, backend tarafı bu karakterleri ayıklayarak kısıtlanmış bir controller'a erişimi tetikleyebiliyor.
- Forwarded & Rewrite Header Manipülasyonları: İç ağ yönlendirmelerinde ve dahili admin panellerinde yetki doğrulaması sadece `X-Forwarded-Host`, `X-Original-URL` veya `X-Rewrite-URL` gibi başlıklara dayanıyorsa, proxy yapılandırmasında bu başlıkların ezilmemesi (override edilmemesi) yetki zincirinin bozulmasına neden olabiliyor.
---
2. Broken Object Level Authorization (BOLA / IDOR) ve Durum Yönetimi
API uç noktalarında kimlik doğrulama (authentication) doğru kurgulansa bile, nesne seviyesindeki yetkilendirme (authorization) kontrolünün merkezi bir middleware yerine her controller içinde manuel bırakılması tipik bir zafiyet kaynağıdır:
- UUID ve Tahmin Edilemez ID Yanılgısı: Nesne kimliklerinin UUID olması tek başına güvenli bir erişim kontrolü sağlamaz. Çoğu mimaride bir public API (örneğin kullanıcı profil detayı veya log akışı) üzerinden elde edilen geçerli bir nesne referansı, sahiplik doğrulaması (tenant/owner validation) yapılmayan kritik bir PATCH/DELETE isteğinde doğrudan kullanılabiliyor.
- HTTP Metod ve Content-Type Geçişleri: REST API mimarilerinde bazı güvenlik katmanları yalnızca belirli HTTP metodlarını (örneğin `POST`) denetleyecek şekilde kural içerirken, uygulamanın aynı işlevi `PUT` veya `PATCH` üzerinden kabul etmesi ya da JSON bekleyen yapının multipart form-data ile çağrılması güvenlik filtrelerinin atlanmasına zemin hazırlayabiliyor.
---
3. Dosya Dahil Etme (LFI / Traversal) ve Ortam Değişkenleri Sızıntısı
Uygulamanın statik dosya servis ettiği veya dinamik şablon render ettiği noktalarda path traversal kontrolleri eksik bırakıldığında:
- Konteynerize Mimarilerde Runtime Sızıntıları: Standart sistem dosyaları kısıtlı konteyner ortamlarında sınırlı bilgi sunsa da; `/proc/self/environ` ve `/proc/self/cmdline` gibi sanal dosya yolları, container orchestration (Kubernetes, Docker) süreçlerinde ortama tanımlanmış veritabanı bağlantı dizgilerini ve API anahtarlarını açığa çıkarabiliyor.
- Framework Yapılandırma Dosyaları: Statik sunucu bloklarında (örneğin web root dışına çıkması gereken dizinlerin yanlış tanımlanması) `.env`, `application.yml` veya `settings.py` gibi hassas yapılandırma dosyalarının public dizine açık kalması, uygulamanın doğrudan veritabanı ve session güvenliğini tehdit eder hale geliyor.
---
Savunma ve Doğru Mimari Yaklaşımları:
1. Path normalizasyonu daima mimarinin en dış katmanında (reverse proxy/WAF) katı kurallarla tamamlanmalı ve arkadaki servislere standardize edilmiş (canonical) URI iletilmelidir.
2. Yetkilendirme kontrolleri kod içerisinde dağınık biçimde değil; nesneye erişim anında veri tabanı sorgu katmanında (örneğin `WHERE user_id = current_user`) zorunlu tutulmalıdır.
3. Dosya okuma operasyonlarında kullanıcı girdileri dosya yolu oluşturmak için kullanılmamalı, sistem genelinde katı whitelist veya sabit anahtar-değer (mapping) mekanizmaları benimsenmelidir.
4. Gizli anahtarlar ve ortam değişkenleri asla web kök dizini altında veya genel okuma izinlerine sahip dosyalarda saklanmamalıdır.
Son dönemde incelediğim mimarilerde ve bug bounty raporlarında sıklıkla karşılaştığım bir tablo var: Güvenlik değerlendirmelerinde genellikle karmaşık enjeksiyon zafiyetlerine odaklanılırken, modern mikroservis ve reverse proxy mimarilerinin getirdiği yapılandırma ile mantık hataları gözden kaçabiliyor.
Özellikle erişim denetimi mekanizmaları, proxy-backend normalizasyon farkları ve yetkilendirme katmanlarındaki mimari açıklara dair sahada karşılaştığım pratik notları derlemek istedim.
---
1. Reverse Proxy & Backend Arasındaki Path Normalizasyon Uyuşmazlıkları
Ön yüzde Nginx, Envoy veya Cloudflare gibi bir proxy/WAF katmanı bulunup arkada Spring, Express veya Tomcat gibi uygulama sunucuları çalıştığında, URL parse etme mantıklarındaki RFC yorumlama farkları ciddi erişim denetimi bypass senaryolarına yol açabiliyor:
- Matrix Parametreleri ve Path Delimiter Tutarsızlığı: Proxy katmanı path bazlı kural işletirken `;` (matrix parameter) veya `%2e` gibi karakterleri statik kabul edip geçirebilirken, backend tarafı bu karakterleri ayıklayarak kısıtlanmış bir controller'a erişimi tetikleyebiliyor.
- Forwarded & Rewrite Header Manipülasyonları: İç ağ yönlendirmelerinde ve dahili admin panellerinde yetki doğrulaması sadece `X-Forwarded-Host`, `X-Original-URL` veya `X-Rewrite-URL` gibi başlıklara dayanıyorsa, proxy yapılandırmasında bu başlıkların ezilmemesi (override edilmemesi) yetki zincirinin bozulmasına neden olabiliyor.
---
2. Broken Object Level Authorization (BOLA / IDOR) ve Durum Yönetimi
API uç noktalarında kimlik doğrulama (authentication) doğru kurgulansa bile, nesne seviyesindeki yetkilendirme (authorization) kontrolünün merkezi bir middleware yerine her controller içinde manuel bırakılması tipik bir zafiyet kaynağıdır:
- UUID ve Tahmin Edilemez ID Yanılgısı: Nesne kimliklerinin UUID olması tek başına güvenli bir erişim kontrolü sağlamaz. Çoğu mimaride bir public API (örneğin kullanıcı profil detayı veya log akışı) üzerinden elde edilen geçerli bir nesne referansı, sahiplik doğrulaması (tenant/owner validation) yapılmayan kritik bir PATCH/DELETE isteğinde doğrudan kullanılabiliyor.
- HTTP Metod ve Content-Type Geçişleri: REST API mimarilerinde bazı güvenlik katmanları yalnızca belirli HTTP metodlarını (örneğin `POST`) denetleyecek şekilde kural içerirken, uygulamanın aynı işlevi `PUT` veya `PATCH` üzerinden kabul etmesi ya da JSON bekleyen yapının multipart form-data ile çağrılması güvenlik filtrelerinin atlanmasına zemin hazırlayabiliyor.
---
3. Dosya Dahil Etme (LFI / Traversal) ve Ortam Değişkenleri Sızıntısı
Uygulamanın statik dosya servis ettiği veya dinamik şablon render ettiği noktalarda path traversal kontrolleri eksik bırakıldığında:
- Konteynerize Mimarilerde Runtime Sızıntıları: Standart sistem dosyaları kısıtlı konteyner ortamlarında sınırlı bilgi sunsa da; `/proc/self/environ` ve `/proc/self/cmdline` gibi sanal dosya yolları, container orchestration (Kubernetes, Docker) süreçlerinde ortama tanımlanmış veritabanı bağlantı dizgilerini ve API anahtarlarını açığa çıkarabiliyor.
- Framework Yapılandırma Dosyaları: Statik sunucu bloklarında (örneğin web root dışına çıkması gereken dizinlerin yanlış tanımlanması) `.env`, `application.yml` veya `settings.py` gibi hassas yapılandırma dosyalarının public dizine açık kalması, uygulamanın doğrudan veritabanı ve session güvenliğini tehdit eder hale geliyor.
---
Savunma ve Doğru Mimari Yaklaşımları:
1. Path normalizasyonu daima mimarinin en dış katmanında (reverse proxy/WAF) katı kurallarla tamamlanmalı ve arkadaki servislere standardize edilmiş (canonical) URI iletilmelidir.
2. Yetkilendirme kontrolleri kod içerisinde dağınık biçimde değil; nesneye erişim anında veri tabanı sorgu katmanında (örneğin `WHERE user_id = current_user`) zorunlu tutulmalıdır.
3. Dosya okuma operasyonlarında kullanıcı girdileri dosya yolu oluşturmak için kullanılmamalı, sistem genelinde katı whitelist veya sabit anahtar-değer (mapping) mekanizmaları benimsenmelidir.
4. Gizli anahtarlar ve ortam değişkenleri asla web kök dizini altında veya genel okuma izinlerine sahip dosyalarda saklanmamalıdır.
