Hızlı cevap: GraphQL güvenliği, tek bir uç nokta üzerinden esnek sorgular kabul eden GraphQL API'lerinde yetkilendirme, aşırı veri çekme ve hizmet dışı bırakma risklerini yönetmektir. GraphQL, istemcinin istediği alanları seçmesine izin verdiği için güçlüdür, ama bu esneklik yanlış kurulduğunda saldırgana da aynı özgürlüğü verir. En sık sorunlar şunlardır: açık bırakılan introspection ile tüm şemanın görülmesi, alan ve nesne düzeyinde eksik yetki kontrolü, iç içe ve döngüsel sorgularla sunucunun tüketilmesi ve tek istekte binlerce işlemi çalıştıran toplu sorgular. Kök çözüm, yetkiyi her alan ve nesne için sunucuda zorlamak, sorgu derinliği ve karmaşıklığını sınırlamak, üretimde introspection'ı kapatmak ve hız sınırı uygulamaktır.

GraphQL, REST'e göre daha az uç nokta ve daha esnek veri çekme sunar, bu yüzden hızla yaygınlaştı. Ama güvenlik modeli REST'ten farklıdır: tek uç nokta, sonsuz sorgu kombinasyonu demektir. Bu yazı, GraphQL API'lerinde en sık görülen açıkları ve doğru savunmayı anlatır.

GraphQL neden farklı bir saldırı yüzeyi

REST'te her uç nokta belirli bir işi yapar ve tek tek korunabilir. GraphQL'de tek bir uç nokta, şemadaki her alanı birleştiren sonsuz sorguya izin verir. Bu, yetkilendirmenin uç nokta düzeyinde değil, her alan ve nesne düzeyinde yapılması gerektiği anlamına gelir. Geliştiriciler REST alışkanlığıyla yalnızca uç noktayı korursa, alan düzeyinde büyük boşluklar kalır.

En sık GraphQL açıkları

Açık Ne yapıyor Sonuç
Açık introspection Tüm şemayı sorgulatır Saldırgana tam harita verir
Alan düzeyi yetki eksiği Yetkisiz alanı döndürür Hassas veri ifşası, IDOR
İç içe sorgu Döngüsel derin sorgu Hizmet dışı bırakma (DoS)
Toplu sorgu Tek istekte çok işlem Kaba kuvvet ve hız sınırı atlatma
Ayrıntılı hata Şema ve iç yapı sızdırır Keşif kolaylaşır

Introspection tek başına bir açık değildir ama üretimde açık bırakıldığında saldırganın işini büyük ölçüde kolaylaştırır.

Yetkilendirme, asıl risk

GraphQL'de en ciddi ve en sık atlanan risk, alan ve nesne düzeyinde eksik yetkilendirmedir. Bir kullanıcı, kendi verisini çekmesi gereken bir sorguyla başka kullanıcının kimliğini vererek onun verisine ulaşabilir. Bu, klasik IDOR ve bozuk erişim kontrolünün GraphQL'deki karşılığıdır. Yetki, her çözümleyicide (resolver) ayrı ayrı zorlanmalıdır, yalnızca girişte değil.

Hizmet dışı bırakma riski

GraphQL'in esnekliği, iç içe ve döngüsel sorgularla kötüye kullanılabilir. Birbirine referans veren nesneler arasında derin bir sorgu, sunucuyu üssel biçimde çalıştırıp tüketebilir. Toplu sorgular ise tek istekte binlerce işlem çalıştırarak hem sunucuyu yorar hem hız sınırını atlatır. Bu, klasik DoS saldırısının uygulama katmanındaki halidir.

Doğru savunma

1. Alan ve nesne düzeyinde yetki

Yetki, uç noktada değil, her çözümleyicide zorlanmalıdır. Kullanıcı yalnızca yetkili olduğu alan ve nesnelere ulaşabilmelidir. Bu, API güvenliğinin temelidir.

2. Sorgu derinliği ve karmaşıklık sınırı

Sorgu derinliği ve karmaşıklığı için üst sınır konmalı, bu sınırı aşan sorgular çalıştırılmadan reddedilmelidir. Döngüsel sorgular engellenmelidir.

3. Hız sınırı ve toplu sorgu kontrolü

Tek istekte çalıştırılabilecek işlem sayısı sınırlanmalı, hız sınırı sorgu maliyetine göre uygulanmalıdır. Basit istek sayısı sınırı toplu sorguya karşı yetersizdir.

4. Üretimde introspection ve ayrıntılı hataları kapatma

Introspection üretimde kapatılmalı, hata mesajları iç yapıyı sızdırmayacak biçimde sadeleştirilmelidir.

KAOS ile GraphQL taraması

DSET'in yerel yapay zekâ güvenlik motoru KAOS, GraphQL API'lerini kanıt temelli test eder. Şemayı çıkarır, alan ve nesne düzeyinde yetki boşluklarını dener, iç içe ve toplu sorgularla hizmet dışı bırakma yüzeyini ölçer ve bir yetki atlatmanın gerçekten başka kullanıcının verisini döndürüp döndürmediğini kontrollü biçimde doğrular. Yalnızca gerçekten istismar edilebilir bulguyu, yanlış pozitif gürültüsü olmadan raporlar. Böylece web uygulama sızma testinin bir parçası olarak GraphQL katmanınızın gerçek durumunu görürsünüz.

Sık sorulan sorular

Introspection'ı kapatınca GraphQL güvenli olur mu? Hayır. Introspection'ı kapatmak keşfi zorlaştırır ama asıl riski, alan düzeyi yetki eksikliğini çözmez. Saldırgan şemayı tahmin ederek ya da sızan bilgiden yararlanarak yine yetkisiz alanlara ulaşabilir. Güvenlik, her çözümleyicideki yetki zorlamasındadır.

GraphQL REST'ten daha mı güvensiz? Daha güvensiz değil, farklı. GraphQL'in esnekliği yanlış kurulduğunda daha geniş bir yüzey açar, ama doğru kurulduğunda güvenli olur. Fark, korumanın uç nokta yerine alan düzeyinde yapılması gerektiğidir.

Hız sınırı GraphQL DoS'unu durdurur mu? Basit istek sayısı sınırı yetersizdir çünkü tek bir karmaşık sorgu sunucuyu tüketebilir. Doğru yaklaşım, sorgu maliyetine ve karmaşıklığına dayalı sınırdır.

Kaynaklar

GraphQL API'nizi yetki, introspection ve DoS riskleri açısından çalışan bir kanıtla test ettirmek için DSET ile iletişime geçin. Ankara Hacettepe Teknokent laboratuvarımızdan sızma testi ve güvenli kod denetimi sağlıyoruz.