Selamlar,
Klasik enjeksiyon zafiyetlerinin yerini artık mikroservis haberleşmeleri, modern protokol tutarsızlıkları ve yapay zeka entegrasyonlarından doğan iş mantığı (business logic) açıkları aldı. Güncel sızma testlerinde ve mimari denetimlerde en sık karşılaşılan üç modern zafiyet sınıfını, tespit yaklaşımlarını ve savunma yöntemlerini derledim.
1. Indirect Prompt Injection ve AI Agent Yetki Aşımı (LLM01 / Excess Agency)
Şirketlerin müşteri destek panellerine, belge özetleyicilerine veya iç yönetim araçlarına doğrudan LLM (Büyük Dil Modeli) entegre etmesi yeni bir saldırı yüzeyi oluşturdu. Buradaki temel risk kullanıcının bizzat bota bir şey yazması değil; botun dış kaynaklardan (web sayfası, PDF, e-posta veya veritabanı kaydı) okuduğu verinin içine gizlenmiş talimatları kendi sistem komutu sanmasıdır (Indirect Prompt Injection).
- Mimari Analiz ve Tespit Yaklaşımı:
Denetimlerde ilk bakılan nokta, LLM'in arka planda hangi dahili API'lara (Function Calling / Tool Use) erişim yetkisi olduğudur. Eğer model; kullanıcı bilgilerini sorgulama, şifre sıfırlama veya veritabanında güncelleme yapma gibi araçlara (tools) doğrudan bağlıysa ve okuduğu harici metinlerle sistem talimatlarını (system prompt) birbirinden ayıramıyorsa zafiyet oluşur. Test sürecinde, modelin işlediği harici veri kaynaklarına bağlam değiştirici metinler yerleştirilerek modelin yetkisiz bir API fonksiyonunu tetikleyip tetiklemediği gözlemlenir.
- Savunma ve Doğru Mimari:
LLM'in çalıştırdığı fonksiyonlar asla "sistem/admin" yetkisiyle koşturulmamalıdır. Model, o anki aktif kullanıcının JWT/Session yetkisi neyse yalnızca o kapsamda (Least Privilege) işlem yapabilmeli, kritik durum değişiklikleri (veri silme, para transferi vb.) için mutlaka kullanıcıdan ikincil bir onay (Human-in-the-loop) alınmalıdır.
2. GraphQL Mimarilerinde Batching ve Derinlik (Depth) Suistimali
REST API'ların yerini hızla alan GraphQL, tek bir uç nokta (`/graphql`) üzerinden esnek sorgulama imkanı sunsa da yetkilendirme ve kaynak sınırlandırma (rate limiting) tarafında ciddi kör noktalar barındırıyor.
- Mimari Analiz ve Tespit Yaklaşımı:
Standart bir REST API'da IP bazlı rate-limit uygulandığında 100 istekten fazlası bloklanabilir. Ancak GraphQL'de "Array Batching" veya "Alias" özelliği aktifse, tek bir HTTP POST isteğinin gövdesine yüzlerce alt sorgu (query/mutation) sıkıştırılabilir. Denetimlerde; OTP doğrulama, kupon deneme veya nesne listeleme işlemleri tek bir HTTP paketi içinde alias kullanılarak (örneğin `q1: checkCode(...)`, `q2: checkCode(...)`) gönderildiğinde, WAF ve klasik rate-limit katmanlarının bunu sadece "1 istek" olarak görüp görmediği denetlenir. Ayrıca iç içe geçmiş ilişkisel nesnelerin (`User -> Posts -> Comments -> Author -> Posts`) döngüsel olarak çağrılmasıyla sunucu kaynaklarının tükenip tükenmediği (Query Depth kontrolü) incelenir.
- Savunma ve Doğru Mimari:
Üretim ortamlarında GraphQL Introspection kapatılmalı, sorgu derinliği (Maximum Query Depth) ve tek istekte çalıştırılabilecek maksimum alias/batch sayısı katı bir şekilde sınırlandırılmalıdır. Rate-limit mekanizması HTTP isteği sayısına göre değil, sorgunun karmaşıklık maliyetine (Query Cost Analysis) göre hesaplanmalıdır.
3. HTTP/2 Request Tunneling ve Frontend/Backend Desynchronization
Modern CDN ve yük dengeleyiciler (Load Balancer) istemciyle HTTP/2 üzerinden konuşurken, arkadaki origin sunucuya (backend) trafiği genellikle HTTP/1.1'e dönüştürerek (downgrading) iletir. Bu protokol dönüşümü sırasında başlıkların (headers) doğrulanmaması ciddi senkronizasyon kayıplarına yol açar.
- Mimari Analiz ve Tespit Yaklaşımı:
HTTP/2 protokolü paket uzunluğunu kendi binary çerçevesinde (frame length) belirlerken, HTTP/1.1 `Content-Length` veya `Transfer-Encoding` başlıklarına güvenir. Denetim aşamasında, HTTP/2 istek başlıklarının veya değerlerinin içine satır sonu karakterleri (CRLF) ya da çelişkili uzunluk bilgileri yerleştirildiğinde, öndeki proxy'nin bunu tek bir istek olarak kabul edip arkadaki HTTP/1.1 sunucusunun bunu iki ayrı istek olarak yorumlayıp yorumlamadığı (Request Smuggling / Tunneling) analiz edilir. Bu uyumsuzluk, iç ağa özel başlıkların (`X-Internal-Admin` vb.) ezilmesine veya önbellek katmanlarının (Cache) zehirlenmesine zemin hazırlar.
- Savunma ve Doğru Mimari:
Frontend proxy ile backend sunucu arasında HTTP/2'den HTTP/1.1'e düşürme (downgrading) işlemi mümkünse kaldırılmalı ve uçtan uca (End-to-End) HTTP/2 kullanılmalıdır. Eğer dönüşüm zorunluysa, reverse proxy katmanında RFC kurallarına uymayan tüm başlık adları ve kontrol karakterleri (özellikle `\r` ve `\n`) backend'e iletilmeden önce reddedilmelidir.
Klasik enjeksiyon zafiyetlerinin yerini artık mikroservis haberleşmeleri, modern protokol tutarsızlıkları ve yapay zeka entegrasyonlarından doğan iş mantığı (business logic) açıkları aldı. Güncel sızma testlerinde ve mimari denetimlerde en sık karşılaşılan üç modern zafiyet sınıfını, tespit yaklaşımlarını ve savunma yöntemlerini derledim.
1. Indirect Prompt Injection ve AI Agent Yetki Aşımı (LLM01 / Excess Agency)
Şirketlerin müşteri destek panellerine, belge özetleyicilerine veya iç yönetim araçlarına doğrudan LLM (Büyük Dil Modeli) entegre etmesi yeni bir saldırı yüzeyi oluşturdu. Buradaki temel risk kullanıcının bizzat bota bir şey yazması değil; botun dış kaynaklardan (web sayfası, PDF, e-posta veya veritabanı kaydı) okuduğu verinin içine gizlenmiş talimatları kendi sistem komutu sanmasıdır (Indirect Prompt Injection).
- Mimari Analiz ve Tespit Yaklaşımı:
Denetimlerde ilk bakılan nokta, LLM'in arka planda hangi dahili API'lara (Function Calling / Tool Use) erişim yetkisi olduğudur. Eğer model; kullanıcı bilgilerini sorgulama, şifre sıfırlama veya veritabanında güncelleme yapma gibi araçlara (tools) doğrudan bağlıysa ve okuduğu harici metinlerle sistem talimatlarını (system prompt) birbirinden ayıramıyorsa zafiyet oluşur. Test sürecinde, modelin işlediği harici veri kaynaklarına bağlam değiştirici metinler yerleştirilerek modelin yetkisiz bir API fonksiyonunu tetikleyip tetiklemediği gözlemlenir.
- Savunma ve Doğru Mimari:
LLM'in çalıştırdığı fonksiyonlar asla "sistem/admin" yetkisiyle koşturulmamalıdır. Model, o anki aktif kullanıcının JWT/Session yetkisi neyse yalnızca o kapsamda (Least Privilege) işlem yapabilmeli, kritik durum değişiklikleri (veri silme, para transferi vb.) için mutlaka kullanıcıdan ikincil bir onay (Human-in-the-loop) alınmalıdır.
2. GraphQL Mimarilerinde Batching ve Derinlik (Depth) Suistimali
REST API'ların yerini hızla alan GraphQL, tek bir uç nokta (`/graphql`) üzerinden esnek sorgulama imkanı sunsa da yetkilendirme ve kaynak sınırlandırma (rate limiting) tarafında ciddi kör noktalar barındırıyor.
- Mimari Analiz ve Tespit Yaklaşımı:
Standart bir REST API'da IP bazlı rate-limit uygulandığında 100 istekten fazlası bloklanabilir. Ancak GraphQL'de "Array Batching" veya "Alias" özelliği aktifse, tek bir HTTP POST isteğinin gövdesine yüzlerce alt sorgu (query/mutation) sıkıştırılabilir. Denetimlerde; OTP doğrulama, kupon deneme veya nesne listeleme işlemleri tek bir HTTP paketi içinde alias kullanılarak (örneğin `q1: checkCode(...)`, `q2: checkCode(...)`) gönderildiğinde, WAF ve klasik rate-limit katmanlarının bunu sadece "1 istek" olarak görüp görmediği denetlenir. Ayrıca iç içe geçmiş ilişkisel nesnelerin (`User -> Posts -> Comments -> Author -> Posts`) döngüsel olarak çağrılmasıyla sunucu kaynaklarının tükenip tükenmediği (Query Depth kontrolü) incelenir.
- Savunma ve Doğru Mimari:
Üretim ortamlarında GraphQL Introspection kapatılmalı, sorgu derinliği (Maximum Query Depth) ve tek istekte çalıştırılabilecek maksimum alias/batch sayısı katı bir şekilde sınırlandırılmalıdır. Rate-limit mekanizması HTTP isteği sayısına göre değil, sorgunun karmaşıklık maliyetine (Query Cost Analysis) göre hesaplanmalıdır.
3. HTTP/2 Request Tunneling ve Frontend/Backend Desynchronization
Modern CDN ve yük dengeleyiciler (Load Balancer) istemciyle HTTP/2 üzerinden konuşurken, arkadaki origin sunucuya (backend) trafiği genellikle HTTP/1.1'e dönüştürerek (downgrading) iletir. Bu protokol dönüşümü sırasında başlıkların (headers) doğrulanmaması ciddi senkronizasyon kayıplarına yol açar.
- Mimari Analiz ve Tespit Yaklaşımı:
HTTP/2 protokolü paket uzunluğunu kendi binary çerçevesinde (frame length) belirlerken, HTTP/1.1 `Content-Length` veya `Transfer-Encoding` başlıklarına güvenir. Denetim aşamasında, HTTP/2 istek başlıklarının veya değerlerinin içine satır sonu karakterleri (CRLF) ya da çelişkili uzunluk bilgileri yerleştirildiğinde, öndeki proxy'nin bunu tek bir istek olarak kabul edip arkadaki HTTP/1.1 sunucusunun bunu iki ayrı istek olarak yorumlayıp yorumlamadığı (Request Smuggling / Tunneling) analiz edilir. Bu uyumsuzluk, iç ağa özel başlıkların (`X-Internal-Admin` vb.) ezilmesine veya önbellek katmanlarının (Cache) zehirlenmesine zemin hazırlar.
- Savunma ve Doğru Mimari:
Frontend proxy ile backend sunucu arasında HTTP/2'den HTTP/1.1'e düşürme (downgrading) işlemi mümkünse kaldırılmalı ve uçtan uca (End-to-End) HTTP/2 kullanılmalıdır. Eğer dönüşüm zorunluysa, reverse proxy katmanında RFC kurallarına uymayan tüm başlık adları ve kontrol karakterleri (özellikle `\r` ve `\n`) backend'e iletilmeden önce reddedilmelidir.
