API Güvenliği Testi ve Koruma Hizmeti

Mobil uygulamanızı kullanıcı görür, web sitenizi Google görür, ama saldırgan ikisinin de arkasındaki API'yi görür. Ekran sadece bir kabuktur; verinin gerçekte aktığı yer, uygulamanın sunucuyla konuştuğu o JSON uçlarıdır. DSET pentest ekibinin sahada en sık karşılaştığı tablo şudur: firma web sitesini test ettirmiş, sızma testi raporunu dosyalamış, "biz güvendeyiz" demiş; oysa o web sitesini besleyen otuz kırk API ucu hiç dokunulmadan, hiç dokümante edilmeden, çoğu zaman kimsenin haberi olmadan ayakta durmaktadır. Asıl açık kapı oradadır.

Bunun bir sebebi var. Klasik web uygulaması bir HTML sayfası döner, içine veriyi gömer, araya bir sürü görsel katman koyar. API ise nezaket göstermez. İstediğiniz nesneyi sorarsınız, size doğrudan JSON olarak döner. Saldırgan için bu hediyedir: ayrıştırması kolay, otomatize etmesi kolay, milyonlarca kaydı saniyeler içinde sıyırması kolay. İşte bu yüzden API'ler, klasik web uygulamalarından çok daha fazla veri sızdırır. Tek bir hatalı uç, tüm müşteri tablonuzu satır satır dışarı taşıyabilir.

BOLA: OWASP API Top 10'un bir numarası ve neden bu kadar yıkıcı

OWASP API Security Top 10'un 2023 sürümünde listenin başında BOLA (Broken Object Level Authorization), yani nesne düzeyinde bozuk yetkilendirme oturur. Mantığı utanç verici derecede basittir, etkisi ise feci. Bir API ucu düşünün: GET /api/v1/invoices/1043. Bu sizin faturanız. Peki ya 1044 yazarsanız? Sağlam bir sistemde sunucu "bu kayıt senin değil" deyip kapıyı kapatmalıdır. Zayıf sistemlerde ise hiçbir şey sormaz, başkasının faturasını size uzatır. Bir id'yi bir artırarak bütün bir veritabanını tarayabilirsiniz.

Bu neden bu kadar sık görülür? Çünkü geliştiriciler kimlik doğrulamayı (authentication, "sen kimsin") yetkilendirmeyle (authorization, "bu kayda erişme hakkın var mı") karıştırır. Token geçerlidir, kullanıcı giriş yapmıştır, sistem tatmin olur. Ama o token'ın sahibinin tam olarak hangi kaydı görmeye hakkı olduğu her istekte, her nesne için ayrı ayrı kontrol edilmek zorundadır. Otomatik tarayıcılar bunu neredeyse hiç yakalayamaz, çünkü iki geçerli hesap arasındaki iş mantığını bilmezler. Bunu ancak iki ayrı kullanıcı hesabıyla, elle, kasıtlı olarak çapraz erişim deneyen bir test uzmanı bulur. DSET ekibinin BOLA bulgularının neredeyse tamamı bu çift hesaplı çapraz denetimden çıkar.

BOLA'nın yakın akrabası BFLA'dır (Broken Function Level Authorization), yani fonksiyon düzeyinde bozuk yetkilendirme. Burada saldırgan başkasının verisine değil, kendi yetkisinin üstündeki bir işleve uzanır. Sıradan kullanıcı, normalde panelde göremediği DELETE /api/v1/users/55 ya da POST /api/v1/admin/roles ucunu doğrudan çağırır. Arayüzde o düğme yoktur ama uç ayaktadır ve kimse "sen admin misin" diye sormaz.

Shadow API ve zombie API: kimsenin haberi olmayan kapılar

Sahada bulduğumuz en sinsi sızıntı kaynağı, dokümantasyonda hiç görünmeyen uçlardır. İkiye ayırırız.

Shadow API, resmi envanterde olmayan, geliştiricinin bir akşam hızlıca eklediği, API ağ geçidinin (gateway) görmediği, güvenlik ekibinin varlığından habersiz olduğu uçtur. Zombie API ise bir zamanlar dokümante edilmiş ama artık terk edilmiş eski sürümdür: /api/v1 yeni sürümle /api/v3'e taşınmıştır, herkes v3'ü korur, ama v1 hâlâ ayaktadır, hâlâ yanıt verir ve genellikle eski, yamasız, savunmasız koddur. Kimse kapatmamıştır çünkü kimse hatırlamamaktadır.

Bunların tehlikesi şudur: koruyamadığınız şeyi göremezsiniz. WAF kuralınız, rate limit politikanız, izleme paneliniz hepsi bildiğiniz uçlara bakar. Shadow ve zombie uçlar tam da bu gözetimin dışında kaldığı için saldırganın ilk uğradığı yerdir. Bu yüzden DSET'te her API testi bir envanter ve keşif aşamasıyla başlar; uçları yalnızca size verilen dokümandan değil, trafikten, mobil uygulama ikilisinden, JavaScript paketlerinden ve geçmiş sürüm izlerinden de çıkarırız. Test edilecek yüzeyi siz değil, gerçek dünya belirler.

WAF neden çoğu API saldırısını göremez

Pek çok firma "WAF'ımız var, korunuyoruz" der. WAF (Web Application Firewall) bilinen imzaları, SQL enjeksiyon kalıplarını, betik enjeksiyonunu yakalamakta iyidir. Ama BOLA'da yük tamamen meşru görünür: geçerli bir token, geçerli bir istek, sadece yanlış bir id. WAF için bu normal trafiktir. Aşırı veri ifşasında (excessive data exposure) sunucu, istemcinin ihtiyacından çok daha fazla alanı JSON'a koyar; parola hash'i, dahili notlar, başka kullanıcıların alanları gizlice döner ve istemci bunları ekranda göstermese de veri tel üzerinden çoktan gitmiştir. WAF bunu da göremez, çünkü ortada hiçbir saldırı imzası yoktur, sadece fazla cömert bir yanıt vardır.

Buna bir de rate limiting eksikliğini ekleyin. Sınırsız istek atılabilen bir kimlik doğrulama ucu, kaba kuvvet ve kullanıcı sayımı (enumeration) için açık davetiyedir. BOLA ile birleştiğinde tablo netleşir: saldırgan id'leri tek tek dener, her seferinde bir kaydı sıyırır ve onu durduran hiçbir frekans sınırı yoktur.

OWASP API Security Top 10 (2023): kısa harita

Sıra Risk Sahadaki gerçek karşılığı
API1 BOLA, nesne düzeyinde yetki kırığı id değiştirerek başkasının kaydına erişim
API2 Bozuk kimlik doğrulama Zayıf JWT, süresiz token, tahmin edilebilir oturum
API3 Bozuk nesne özelliği düzeyi (aşırı ifşa + mass assignment) Fazla alan dönen yanıt, istemciden rol/yetki yazma
API4 Sınırsız kaynak tüketimi Rate limit yok, sayfalama yok, servis dışı bırakma riski
API5 BFLA, fonksiyon düzeyi yetki kırığı Sıradan kullanıcının admin ucunu çağırması
API6 Hassas iş akışlarına sınırsız erişim Otomasyonla kötüye kullanılabilen kritik işlemler
API7 Sunucu tarafı istek sahteciliği (SSRF) API'nin saldırgan adına iç ağa istek atması
API8 Güvenlik yanlış yapılandırması Açık CORS, ifşa olmuş hata yığını, varsayılan ayarlar
API9 Yanlış envanter yönetimi Shadow ve zombie API'ler, dokümante edilmemiş uçlar
API10 API'lerin güvensiz tüketimi Üçüncü taraf API'lere körü körüne güven

Bu tablo, neden tek bir tarayıcı çıktısının yetmediğini özetler. API1, API3, API5 ve API6 doğrudan iş mantığıdır; bunları ancak uygulamanızın ne yaptığını anlayan bir insan, iki farklı hesapla, kasıtlı kötüye kullanım senaryolarıyla test ederek bulur.

JWT, mass assignment ve GraphQL: sık göz ardı edilen üç cephe

JWT zafiyetleri, bozuk kimlik doğrulamanın en sevilen yuvasıdır. Sahada sık gördüklerimiz: imza algoritmasının "none" olarak kabul edilmesi, sunucunun token imzasını hiç doğrulamaması, simetrik anahtarın zayıf ya da sızmış olması, token süresinin (exp) hiç dolmaması ve oturum kapatıldığında token'ın iptal edilmemesi. Bir tek bunlardan biri, başkasının kimliğine bürünmek için yeterlidir.

Mass assignment, istemcinin gönderdiği JSON'daki her alanı sunucunun körü körüne nesneye yazmasıdır. Profil güncelleme isteğinize sessizce "role": "admin" alanını eklersiniz; sunucu süzgeçten geçirmediği için bunu kabul eder ve siz yetkinizi kendiniz yükseltirsiniz. Klasik web formlarında nadir olan bu hata, JSON tabanlı API'lerde bolca görülür.

GraphQL kendine has bir cephedir. Introspection açık bırakıldığında saldırgan tek bir sorguyla tüm şemayı, tüm tipleri ve tüm alanları öğrenir; haritanızı eline alır. İç içe sorgularla derin ve pahalı isteklerle servisi yorabilir, alan bazlı yetki kontrolü eksikse REST'teki BOLA'nın aynısını GraphQL'de yaşatabilir.

DSET API güvenliği hizmeti nasıl ilerler

Yaklaşımımız klasik web sızma testinden bilinçli olarak ayrışır; çünkü API'nin tehdit yüzeyi de farklıdır.

1. Envanter ve keşif

Shadow ve zombie uçlar dahil tüm API yüzeyini çıkarırız. Yalnızca verilen dokümana güvenmez; trafiği, mobil uygulama ikilisini, ön yüz JavaScript'ini ve eski sürüm izlerini tarayarak gerçek saldırı yüzeyini ortaya koyarız.

2. OWASP API Top 10 bazlı sızma testi

Listenin tamamını, özellikle iş mantığı gerektiren BOLA, BFLA, mass assignment ve aşırı veri ifşasını, en az iki farklı yetki seviyesindeki hesapla, elle ve kasıtlı kötüye kullanım senaryolarıyla test ederiz.

3. Kimlik doğrulama ve yetkilendirme denetimi

JWT yapılandırması, token yaşam döngüsü, oturum iptali, her nesne ve her fonksiyon için yetki kontrolünü ayrı ayrı doğrularız. "Sen kimsin" ile "buna hakkın var mı" sorularını birbirinden ayırarak inceleriz.

4. Remediation ve doğrulama

Her bulgu için somut, geliştiricinin doğrudan uygulayabileceği düzeltme adımı sunarız; düzeltme sonrası yeniden test ederek açığın gerçekten kapandığını kanıtlarız.

5. Sürekli izleme

Tek seferlik test bir anlık görüntüdür. Yeni uçlar her dağıtımda doğar; sürekli izleme ile envanteri canlı tutar, yeni shadow API'leri ve yetki kaymalarını ortaya çıktıkça yakalarız.

Web uygulaması güvenliği hâlâ önemlidir ve onu da yaparız; ayrıntılar için web sitesi güvenlik ve sızma testi hizmetimize bakabilirsiniz. Sızma testinin genel sürecini, ne zaman gerektiğini ve fiyatlamayı merak ediyorsanız sızma testi süreci yazımız iyi bir başlangıçtır. Bulunan açıkların düzenli takibi içinse güvenlik açığı yönetimi hizmetimizi inceleyin.

Sık Sorulan Sorular (SSS)

API güvenliği testi, normal web sızma testinden ne farkı var? Web testi tarayıcıyla görünen sayfalara odaklanır. API testi ise arkadaki JSON uçlarına, iş mantığına ve yetkilendirmeye odaklanır. BOLA, BFLA, mass assignment gibi açıklar yalnızca API katmanında, çoğu zaman birden fazla hesapla elle test edilerek bulunur. İkisi birbirinin yerini tutmaz.

Zaten WAF kullanıyoruz, yine de API testi gerekir mi? Evet. WAF bilinen saldırı imzalarını yakalar ama BOLA ve aşırı veri ifşası gibi açıklarda yük tamamen meşru görünür. Geçerli token, geçerli istek, yanlış id; WAF bunu normal trafik sanır. WAF tamamlayıcıdır, yetkilendirme açığının yerini tutmaz.

Shadow API ve zombie API nedir, neden tehlikelidir? Shadow API, envanterde olmayan ve güvenlik ekibinin haberi olmadan eklenmiş uçtur. Zombie API ise terk edilmiş eski sürümdür. İkisi de izleme ve koruma kapsamı dışında kaldığı için saldırganın ilk uğradığı, en kolay sızıntı veren noktalardır.

GraphQL kullanıyoruz, REST'ten daha mı güvenli? Hayır, sadece farklı. Açık introspection tüm şemanızı ifşa eder, alan bazlı yetki eksikliği REST'teki BOLA'nın aynısını yaşatır, iç içe sorgular servis yükü oluşturur. GraphQL'in kendine özgü bir test disiplini vardır.

Test bir kez yapılınca yeterli mi? Tek seferlik test yalnızca o günün fotoğrafıdır. Her yeni dağıtımda yeni uçlar ve yeni shadow API'ler doğabilir. Bu yüzden envanteri canlı tutan sürekli izlemeyi öneririz; risk tek seferde bitmez, yönetilir.

Kaynaklar

DSET - 2003'ten beri siber güvenlik ve sızma testi. Adres: Hacettepe Teknokent, Beytepe, Ankara. Telefon: +90 536 662 38 09. İlk teşhis ve kapsam görüşmesi ücretsizdir.