RESTFUL API PENTEST — (Part 2)

​

Teknolojiye Göre Zayıf Alanlar​

JAVA (Spring Boot)

- Validation/Input: Backend’de DTO kullanıldığı için geliştirici kendisini güvende hisseder ama @Valid, @NotNull, @Size gibi alan bazlı kısıtlmalar yoksa Spring gelen JSON’ın tamamını kabul eder. Nested objeler otomatik bind edilir, bu yüzden kullanıcı normalde hiç göndermemesi gereken alanları request içine ekleyerek backend’in iç state’ini manipüle edebilir. Bu hatanın sonucu genellikle Mass Assignment olur.

· Endpoint’e ekstra JSON alanı eklersem backend kabul ediyor mu?

- Authz/Yetkilendirme: Spring Boot’da yetkilendirme annotationlar üzerinden çalışır: @PreAuthorize veya method-level security yoksa spring hiçbir şey yapmaz. Geliştirici login kontrolü olduğu için yetki de var sanır ama method seviyesinde kontrol yoksa kullanıcı rolü backend için doğrulanmaz. Sonuç genellikle IDOR veya yetkisiz işlem olur.

· Bu endpointi daha düşük yetkili kullanıcıyla çağırırsam yine çalışıyor mu?

NODE.JS(Express/NestJS/Fastify)

- Auth/Kimlik Doğrulama: Node.js’ te auth genellikle middleware ile yapılır ama middleware sırası yanlışsa veya async/await hatalıysa auth zinciri kırılabilir. Promise resolve olmadan next() çağırılırsa veya async fonksiyon doğru beklenmezse istek auth’dan geçmiş gibi devam eder. Bu yüzden Node uygulamlarında auth mantıksal olarak var ama fiilen atlanabilir.

· İsteği farklı sırayla veya paralel gönderirsem auth atlanıyor mu?

- Business Logic/Async: Node async çalıştığı için state kontrolü yapılmazsa race condition oluşur. Aynı isteği hızlıca iki kez göndermek veya adımları atlamak sistemin normal akışını bozar. Bu durum genellikle double request abuse veya mantıksal açık üretir.

· Bu isteği arka arkaya gönderirsem sistem iki kez işliyor mu?

GO(net/http, Gin, Echo)

- Input: Go backendler minimaldir: JSON decode işlemi tamamen geliştiriciye bırakılmıştır. Struct tanımı varsa geliştirici güvende hisseder ama ekstra alanlar çoğu zaman sessizce ignore edilir veya loglanmaz. Bu durum backend’in beklemediği inputların sisteme ulaşmasına yol açar.

· Bozuk veya ekstra field’lı JSON gönderirsem backend ne yapıyor?

- Error/Output: Go’da hata yönetimi genelde basittir; panic veya error direkt response’a yazdırılabilir. Recover veya custom error handler yoksa stack trace ve internal bilgi kullanıcıya döner.

· Hatalı input gönderirsem backend bana ne döndürüyor?

.NET(ASP.NET Core)

- AuthZ/Yetkilendirme: .NET’de [Authorize] controller seviyesinde olabilir ama method seviyesinde yoksa endpoint korunmaz. Geliştirici Controller koruyor sanır ama bazı methodlar doğrudan çağırılabilir. Bu durum genellikle yetkisiz işlem veya IDOR ile sonuçlanır.

· Bu method’a yetkisiz kullanıcıyla istek atarsam çalışıyor mu?

- Input/Model Binding: Model binding otomatik çalışır ve gelen JSON’daki tüm alanları objeye bağlamaya çalışır. Enum veya beklenmeyen field’lar düzgün filtrelenmezse backend sessizce kabul eder. Bu da input bazlı mantıksal açık üretir.

· Modele ekstra alan eklersem backend bunu farkediyor mu?

PYTHON(Flask/FastAPI/Django)

- Input: Flask’ta neredeyse hiç otomatik doğrulama yoktur; FastAPI’da schema vardır ama opsiyonel alanlar abuse edilebilir. Geliştirici schema var diye güvende hisseder ama backend mantıksal olarak gelen veriyi kontrol etmez. Bu da beklenmeyen inputların sisteme girmesine yol açar.

· Opsiyonel alanları manipüle ederek backend’i kandırabilir miyim?

- Auth: Decorator unutulmuş olabilir veya token sadece decode edilip verify edilmez. Bu durumda backend token’ı gerçek sanır ama aslında doğrulamaz.

· Token doğrulanıyor mu yoksa sadece okunuyor mu?

GRAPHQL

- Input: GraphQL tek endpointtir ve client ne isterse onu sorar. Query depth limit veya nested mutation kontolü yoksa kullanıcı backend’in hiç beklemediği işlemleri tetikler. Bu durum hem veri sızıntısına hem de sistem çökmesine yol açar.

· Query’e ekstra field eklersem backend engelliyor mu?

- AuthZ/Field-Level: GraphQL’de resolver bazlı auth yapılır ama field-level yetki yoksa kullanıcı admin alanlarını okuyabilir. Login olmak yeterli sanılır ama hangi field’a erişileceği kontrol edilmez. Bu klasik user tarafından admin data leak’idir.

· Bu field’ı yetkim yokken okuyabiliyor muyum?

API Gateway/Microservice

- Input ve Trust Boundary: Gateway input’u valide eder ama backend servisler valide etmez. Geliştirici gateway var diye backend’i savunmasız bırakır. Gateway bypass edilirse servisler tamamen kontrolsüz kalır.

· Bu servise gateway’i atlayarak direk erişebiliyor muyum?

- AuthZ: Gateway auth yapar ama internal servislerde yetki kontrolü yoktur. Servisler birbirine güvenir, kullanıcıya güvenmemesi gerektiğini unutur. Bu trust boundary ihlali üretir.

· İnternal endpointler auth istiyor mu?

SERVERLESS(AWS Lambda/Azure Functions/GCP Functions)

- Input/Event Manipulation: Serverless fonksiyonlar klasik HTTP request değil, event objesi üzerinden çalışır. Geliştirici API Gateway veya trigger’ın input’u temizlediğini sanır ama fonksiyon içinde ek bir doğrulama yoksa event içindeki header, body, path veya context alanları olduğu gibi kabul edilir. Bu durumda kullanıcı, normalde backend’in asla görmemesi gereken alanları manipüle ederek fonksiyonun davranışını değiştirebilir.

· Event body veya header içine ekstra alanlar eklersem fonksiyon bunları kullanıyor mu?

- Auth/Kimlik Doğrulama: Serverless mimaride auth çoğu zaman API Gateway veya IAM üzerinden yapılır. Geliştirici gateway auth yapıyor diye fonksiyon içinde ek kontrol koymaz. Ama gateway yanlış yapılandırılmışsa veya farklı bir trigger (direct invoke, test invoke, internal call) varsa fonksiyon authsuz çalışabilir.

· Bu Lambda’yı gateway dışında bir yoldan çağırabiliyor muyum?

- AuthZ/Yetkilendirme: IAM role’ler genelde fazla yetkili verilir, çünkü çalışsın yeter mantığıyla ayarlanır. Fonksiyon içinde hangi kullanıcının hangi kaynağa erişeceği kontrol edilmezse, tek bir fonksiyon çok fazla işlemi yetkisiz şekilde yapabilir. Bu durum genelde Privilege Escalation ile sonuçlanır.

· Bu fonksiyon benim yetkim olmayan bir kaynağa işlem yapabiliyor mu?

- Business Logic: Serverless otomatik retry ve paralel çalışır. Idempotency yoksa aynı istek birden fazla kez işlenir; ödeme, kayıt veya state değişimi iki kez gerçekleşebilir. Geliştirici bunu fark etmez çünkü retry cloud tarafından gizlenir.

· Aynı isteği tekrar tekrar gönderirsem sistem kaç kez işliyor?

Teknolojiye Göre Değişiklik Gösterse de Genel Olarak Test Et

- Login varsa yetki vardır sanılır — Düşük kullanıcıyla test et.

- DTO var valid yoksa — Requestteki JSON’a ekstra ve Nested alan ekle.

- Auth Middleware varsa endpoint korunuyor sanılır — Endpoint’i direkt çağır.

- JWT doğrulanmayıp sadece okunabilir — Başka app’den alınan token dene.

- Gateway input’u doğrular ama backend doğrulamaz — Gateway’den geçmeyecek bozuk payload’ı backend servisine direkt gönder.

- Async sistemlerde state kontrol unutulabilir — Aynı isteği hızlıca tekrar gönder.

- Business Logic varsayımsal olarak doğru kabul edilip kodda yazılmamış olabilir — Adımları yanlış sırayla çağır, backend engelliyor mu bak.

- GraphQL tek endpoint olduğu için her şey ordan gider kabul edilir — Query’e ekstra field ve admin alanları ekle.

• **Framework neyi geliştiricinin yerine yapıyorsa geliştirici onu kontrol etmeyi unutmuştur, bu yüzden framework’ün otomatik yaptığı her şeyi manuel bozmayı dene.***
• ***API pentest ne çalışıyor değil, ne kontrol edilmiyor sorusudur.