GraphQL API açıkları
GraphQL açıkları genellikle uygulama hatalarından ve tasarım kusurlarından kaynaklanır. Örneğin introspection özelliği açık bırakılmış olabilir, bu da saldırganların API'yi şema hakkında bilgi edinmek için sorgulamasına olanak tanır.
GraphQL saldırıları, saldırganın veri elde etmesine veya yetkisiz eylemler gerçekleştirmesine olanak tanıyan kötü niyetli isteklerden oluşur. Bu saldırılar ciddi bir etki yaratabilir. Kullanıcı sorguları manipüle ederek veya CSRF açığı kullanarak yönetici ayrıcalıkları elde edebiliyorsa sıkıntı büyük demektir.
Bu bölümde GraphQL API'lerini test etmenin yollarını inceleyeceğiz. GraphQL'e aşina değilseniz dert etmeyin ayrıntılardan ilerledikçe bahsedeceğiz. Ayrıca, öğrendiklerinizi pratiğe dökebileceğiniz bazı lableri de konu sonunda yorum olarak verdik.
GraphQL Endpoints(Uç noktaları) bulma
Bir GraphQL API'sini test etmeden önce, önce uç noktasını bulmanız gerekir. GraphQL API'leri tüm istekler için aynı uç noktayı kullandığından, bu değerli bir bilgidir.
Not: Bu bölüm, GraphQL uç noktalarını manuel olarak nasıl bulacağınızı açıklar. Ancak Burp Scanner, tarama sırasında otomatik olarak GraphQL uç noktalarını kontrol edebilir. "GraphQL endpoint found/GraphQL uç nokta bulundu" yazar ve böylece herhangi bir uç noktanın bulunduğunu anlamış olursunuz.
Evrensel sorgular
Herhangi bir GraphQL uç noktasına query{__typename} gönderirseniz, yanıtında bir yerlerde {"data": {"__typename": "query"}} dizesini içerecektir. Bu, evrensel sorgu olarak bilinir ve bir URL'nin bir GraphQL servisine karşılık gelip gelmediğini test etmek için kullanışlı bir tooldur.
Sorgu, her GraphQL uç noktasının __typename olarak adlandırılan ve sorgulanan nesnenin türünü bir String olarak döndüren ayrılmış bir alana sahip olması nedeniyle çalışır.
Ortak uç nokta adları
GraphQL hizmetleri genellikle benzer uç nokta eklerini kullanır. GraphQL uç noktalarını test ederken, aşağıdaki konumlara evrensel sorgular göndermeye çalışmalısınız:
Eğer bu uç noktalar bir GraphQL yanıtı döndürmüyorsa pathe /v1 eklemeyi de deneyebilirsiniz.
Not: GraphQL hizmetleri genellikle herhangi bir GraphQL dışı isteğe "query not present" veya benzer bir hata ile yanıt verir bu hatanın anlamı sorgu mevcut değil demektir. GraphQL uç noktalarını test ederken bunu aklınızda bulundurmalısınız.
Request Yöntemleri
GraphQL uç noktalarını bulmaya çalışmanın bir sonraki adımı, farklı (request)istek yöntemlerini test etmektir. Production GraphQL uç noktalarının yalnızca application(uygulama)/json içerik türüne sahip POST istekleri kabul etmesi en iyi uygulamadır, çünkü bu CSRF açıklarından da korunmaya yardımcı olur. Ancak, bazı uç noktalar alternatif yöntemler kabul edebilir. Buna örnek olarak GET istekleri veya x-www-form-urlencoded içerik türüne sahip POST istekleri verilebilir. Ortak uç noktalara POST istekleri göndererek GraphQL uç noktasını bulamazsanız, alternatif HTTP yöntemlerini kullanarak evrensel sorguyu yeniden göndermeyi deneyin.
Initial testing
Uç noktanın nasıl çalıştığını biraz daha anlamak için uç noktayı keşfettikten sonra bazı test istekleri gönderebilirsiniz. Uç nokta bir web sitesini çalıştırıyorsa, Burp'ın tarayıcısında web arayüzünü keşfetmeyi ve gönderilen sorguları incelemek için HTTP geçmişini kullanmayı deneyin.
Parametrelerden Faydalanmak
Bu noktada, güvenlik açıkları aramaya başlayabilirsiniz. Sorgu parametrelerini test etmek iyi bir başlangıç olur. API, nesnelere doğrudan erişmek için parametreler kullanıyorsa, (access control vulnerabilities) erişim kontrol açıklarına karşı savunmasız olabilir. Bir kullanıcı, yalnızca o bilgiye karşılık gelen bir argüman sağlayarak sahip olmaması gereken bilgiye potansiyel olarak erişebilir. Bu Insecure direct object reference yani Güvensiz doğrudan nesne referansı olarak da bilinir. (IDOR)
Örneğin aşağıdaki sorgu bir online shop için ürün listesi istiyor
response a bakalım
Bu bilgilerden şu sonuçlara ulaşabiliriz:
Ürünlere ardışık şekilde bir ID atanıyor
ID'si 3 olan ürün yok delist olmuş yüksek ihtimalle
Bu kayıp ürünün ID'sini Shop'ta listelenmemiş olsa bile sorgulayarak detaylarını öğrenebiliriz.
bize gelen response:
Şema Bilgilerini Keşfetme
API'yi test etmenin bir sonraki adımı, temel şema hakkında bilgileri bir araya getirmektir. Bunu yapmanın en iyi yolu, introspection sorguları kullanmaktır. Introspection bir serverdan şema hakkında bilgi sorgulayabileceğiniz bir GraphQL fonksiyonudur.
Introspection, bir GraphQL API'siyle nasıl etkileşime geçebileceğinizi anlamanıza yardımcı olur. Ayrıca potansiyel olarak hassas verileri de (açıklama alanları gibi) ortaya çıkartmanıza yardımcı olur.
Introspection Kullanma
Şema bilgilerini keşfetmek için __schema alanını sorgulayabilirsiniz. Bu alan, tüm sorguların root(kök) kısmında mevcuttur. Normal sorgular gibi, bir introspection sorgusu çalıştırırken döndürülmesini istediğiniz yanıtın alanlarını ve yapısını belirtebilirsiniz. Örneğin, yanıtın yalnızca mevcut türün adlarını içermesini isteyebilirsiniz.
Production ortamlarında introspection'un devre dışı bırakılması en doğrusudur. Ama herkes bu tavsiyeye uymaz.
Aşağıdaki basit sorguyu kullanarak inceleme yapabilirsiniz fakat introspection eğer devre dışı değilse response bütün mevcut sorguların adlarını döndürecektir.
Not:
Burp Scanner, taramaları sırasında otomatik olarak introspection için test yapabilir. Introspection etkinleştirilmişse, "GraphQL introspection enabled" diye bize bildirir.
Tam Introspection sorgusu çalıştırma
Bir sonraki adım, mümkün olduğunca fazla bilgi almak için uç noktaya karşı tam bir introspection sorgusu çalıştırmaktır.
Aşağıdaki örnek sorgu bir sürü detay döndürecektir:
Not: Eğer introspection etkinleştirilmişse ancak yukarıdaki sorgu çalışmıyorsa, sorgu yapısından onOperation, onFragment ve onField'ı kaldırmayı deneyin. Birçok uç nokta, introspection sorgusu içinde bunları kabul etmez ve bunları kaldırarak daha fazla başarı şansı elde etmiş olursunuz.
notlar:
*GraphQL: API'ler için açık kaynaklı bir veri sorgulama ve işleme dili ve bu sorguları yerine getirmek için yazılmış uygulamalardır. GraphQL, 2012'de Facebook tarafından dahili olarak geliştirildi ve 2015'te herkese açık olarak yayınlandı
Introspection: GraphQL, geliştiricilerin mevcut türler, alanlar ve işlemler hakkında ayrıntılar sağlayan API şemasını sorgulamasına olanak tanır. Bu iç gözlem özelliği, API'yi keşfetme ve anlama sürecini basitleştirir.
*Endpoint: Endpoint, api üzerinde belirli bir amaç için oluşturulan metodlara verilen isimdir. Http, günümüz teknolojisinde en yaygın kullanılan istemci ve sunucu arası haberleşme protokolüdür. Http Request ise api üzerinde oluşturulan çeşitli özelliklere sahip endpointlerin, Http protokolü kullanılarak talep iletmesidir.
çeviren: @Gauloran
_________________________________________________________________
..SHELDON
Introspection Sorgulamalarını Görselleştirme
introspection sorgularına verilen yanıtlar zengin miktarda bilgi sağlayabilir, ancak aynı zamanda oldukça uzun ve anlaması zor da olabilir.
Şema varlıkları arasındaki ilişkilerin daha iyi anlaşılmasını kolaylaştırmak için GraphQL görselleştiricisi kullanılmalıdır. Bu çevrimiçi araç, bir sorgunun sonuçlarını alır ve döndürülen verilerin görsel bir temsilini oluşturarak işlemler ve türler arasındaki bağlantıları vurgular.
InQL'i kullanma
Bir introspection sorgusu çalıştırma ve sonuçları görselleştirme sürecini kolaylaştırmak için Burp Suite'in InQL uzantısını kullanmanızı öneririm.
Burp Suite'in bir uzantısı olan InQL, GraphQL API'lerinin güvenli denetimlerini gerçekleştirmek için değerli bir araç olarak hizmet eder. InQL, bir URL girerek (canlı uç nokta bağlantısı aracılığıyla veya bir JSON dosyası yükleyerek), tüm sorguları ve mutasyonları talep eden bir introspection sorgusu başlatır. Daha sonra, sonuçların zahmetsizce araştırılmasını kolaylaştıran bir görünğm sunar.
Burp Suite'de daha fazla InQL kullanımı için: Tıkla bana
Öneriler
İç gözlemin yokluğunda, kişi ara sıra önerilerden yararlanarak bir API'nin yapısına ilişkin içgörüler elde edebilir.
Apollo GraphQL platformunun dikkate değer bir özelliği olan öneriler, sunucunun hata mesajları aracılığıyla sorgu değişiklikleri önermesine olanak tanır. Bu işlevsellik, bir sorgu hala tanımlanabilecek küçük hatalar içerdiğinde özellikle yararlı olur.
(Örnepin , 'productInfo' için herhangi bir sonuç yok. Şunu mu kastettiniz? 'productInformation' ).
"Clairvoyance", iç gözlem devre dışı bırakıldığında bile GraphQL şema bilgilerini almak için kullanışlı bir araçtır. Yararlı öneriler sunarak zaman tasarrufu sağlar. Apollo'nun önerileri devre dışı bırakmanın doğrudan bir yolu yoktur, ancak buna GitHub başlığında bir geçici çözüm bulabilirsiniz.
Not:
Burp Scanner otomatik olarak kendi taramasının parçası olarak öneriler için test yapabilir. Aktif bir öneri bulunur ise Burp, "GraphQL suggestions enabled" (GraphQL önerileri aktif) diye uyarı verir.
GraphQL içgözlemini Bypass Etmek
Test ettiğiniz API için sorgulamaları çalıştırmada zorluk yaşıyorsanız, " __schema" 'dan sonra sonra özel bir karakter ekleyin.
İç gözlemi devre dışı bırakan geliştiriciler, sorgularda __schema anahtar sözcüğünü hariç tutmak için sıklıkla normal ifadeler (regex) kullanır. Boşluklar, yeni satırlar ve virgüller gibi karakterlerle denemeler yapmanız önerilir; çünkü bunlar GraphQL tarafından göz ardı edilir ancak flawed regex'ler tarafından göz ardı edilmez.
Geliştiricinin yalnızca __schema{'yı görmezden gelmesi durumunda aşağıda sağlanan iç gözlem sorgusunun da görmezden gelineceği bilinmelidir:
Bu çalışmazsa alternatif bir request methodu deneyin (malum yalnızca POST üzerinden devre dışı bırakılabiliyor o yüzden GET requesti yapmaya çalışın veya
x-www-form-urlencoded içerikli bir POST request'i yapın
Aşağıdaki örnek bize URL ile kodlanmış parametreler aracılığıyla GET sorgusu gönderen bir iç gözlem probu yer almaktadır
Not:
GET yöntemi aracılığıyla yalnızca iç gözlem sorgularını kabul eden bir uç noktayla karşılaşırsanız ve sorgu sonuçlarını InQL Tarayıcıyı kullanarak analiz etmek istiyorsanız, sorgu sonuçlarını bir dosyaya kaydetmenizin zorunlu olduğunu lütfen unutmayın. Dosya kaydedildikten sonra onu standart ayrıştırma sürecinden geçeceği InQL'e yüklemeye devam edebilirsiniz.
Sahte İsimler Kullanarak Hız Limitini Bypass Etmek
GraphQL alanında nesnelerin aynı adı taşıyan birden fazla özelliği barındırmaktan kaçınması gerekir. Ancak korkmayın, çünkü sizi bu kısıtlamadan kurtaracak takma adlar mevcuttur. Takma adlar kullanarak API'nin sağlamasını istediğiniz özellikleri açıkça belirleme gücüne sahip olursunuz. Bu da size tek bir istekte aynı türden nesnenin birden çok örneğini temin etme olanağı sağlar.
Takma adlar, öncelikle API çağrılarının sıklığını azaltmak için tasarlanmış olsa da, GraphQL uç noktasından zorla yararlanmak için de kullanılabilir.
Pek çok uç noktanın, brute force saldırılarını engellemek için bir güvenlik önlemi olarak hız sınırlayıcıları içerdiğini belirtmekte fayda var. Bu hız sınırlayıcılar, uç noktada yürütülen işlem sayısına değil, aksine alınan HTTP isteklerinin sayısına göre çalışır. Ancak takma adlar, tek bir HTTP mesajı içinde birden fazla sorgunun iletilmesine izin vererek bu korumayı aşma yeteneğine sahiptir. Sonuç olarak bu, yukarıda belirtilen kısıtlamanın atlanmasına olanak sağlar.
Aşağıdaki basitleştirilmiş örnekte de göreceğiniz üzere mağaza indirim kodlarının geçerliliğini doğrulamak için kullanılan takma ad sorgularının bir dizisi kullanılıyor. Bu özel işlem, tek bir HTTP isteğinin çalışma prensibi nedeniyle hız sınırlayıcı önlemleri atlatma potansiyeline sahiptir. Bu yöntemin aynı anda birden fazla sayıda indirim kodunu kontrol edebileceğini de belirtmekte fayda var.
GraphQL CSRF
Bir uygulamada Siteler Arası İstek Sahteciliği (CSRF) güvenlik açıkları mevcutsa kullanıcılar tarafından istenmeyen eylemlerin gerçekleştirilmesine yol açabilir. Bu durum, bir saldırganın kötü amaçlı bir web sitesi oluşturarak güvenlik açığı bulunan uygulamaya hileli bir şekilde alanlar arası istek başlatması durumunda ortaya çıkar. Bu tür güvenlik açıkları, etkilenen sistemin güvenliği ve bütünlüğü açısından önemli bir risk oluşturabilir.
GraphQL, uygulanmasında Siteler Arası İstek Sahteciliği (CSRF) saldırıları için bir kanal görevi görme potansiyeline sahiptir. Bu özel saldırı türü, saldırganın, kurbanın web tarayıcısını farkında olmadan kurban kullanıcı adına kötü niyetli bir sorgu iletmesine yol açtığında meydana gelir. CSRF saldırılarının, mağdur kullanıcının bilgisi veya rızası olmadan yetkisiz eylemler gerçekleştirmesine yol açabileceğinden, bir uygulamanın güvenliği için önemli bir tehdit oluşturabileceğini unutmamak önemlidir.
GraphQL Üstünden CSRF Güvenlik Açıkları Nasıl Oluşur?
GraphQL uç noktasının aldığı isteklerin içerik türünü doğrulamada başarısız olduğu ve CSRF belirteçlerini uygulamayı ihmal ettiği durumlarda CSRF güvenlik açıkları potansiyel olarak ortaya çıkabilir.
Bir uygulama/json içerik türünü kullanan POST istekleri söz konusu olduğunda, içerik türünün uygun şekilde doğrulanması koşuluyla genellikle sahteciliğe karşı güvenli kabul edilir. Bu gibi durumlarda, kurban kötü amaçlı bir web sitesini ziyaret etse bile, saldırgan kurbanın tarayıcısını bu özel isteği gönderecek şekilde yönlendiremez.
Ancak, GET istekleri veya x-www-form-urlencoded içerik türünü kullanan herhangi bir istek gibi alternatif yöntemlerin aslında bir tarayıcı tarafından gönderilebileceğini belirtmekte fayda var. Sonuç olarak söz konusu uç noktanın bu tür istekleri kabul etmesi durumunda kullanıcılar kendilerini olası saldırılara karşı savunmasız bulabilir. Bu senaryolarda saldırganlar, API'ye gönderilecek kötü amaçlı istekleri ustalıkla hazırlayarak bu güvenlik açığından yararlanabilir.
GraphQL Saldırılarını Önleme
GraphQL saldırılarını önlemek için API'nizi dağıtırken şu adımları izleyin:
1. API'niz genel kullanım için değilse iç gözlemi devre dışı bırakın. Bu, saldırganların API hakkında bilgi sahibi olmasını zorlaştırır ve bilgilerin ifşa edilmesi riskini azaltır.
Apollo GraphQL'de iç gözlemi devre dışı bırakma talimatları için bu blog gönderisini okuyun.
Bana tıkla dostum
2.API'nizin genel halk tarafından kullanılması amaçlanıyorsa, iç gözlemin etkin kalması zorunludur. Ancak istenmeyen alanların kamuya açıklanmamasını sağlamak için API şemasını kapsamlı bir şekilde incelemek çok önemlidir.
3.Önerileri tereddüt etmeden devre dışı bırakın. Bu, saldırganların temel şema hakkında bilgi çıkarmak amacıyla Durugörü veya benzer araçlardan yararlanma girişimlerini etkili bir şekilde engelleyecektir.
4.Önerileri doğrudan Apollo'da devre dışı bırakmak ne yazık ki mümkün değil. Ancak bir geçici çözüm mevcuttur. Daha fazla ayrıntı için lütfen bu GitHub konusuna bakın.
5.API şemanızın, e-posta adresleri veya kullanıcı kimlikleri gibi herhangi bir özel kullanıcı alanını yanlışlıkla açığa çıkarmadığından emin olmak için büyük özen gösterin.
GraphQL Brute Force Saldırılarını Engellemek
GraphQL API'lerini kullanırken bazen standart hız sınırlamasını aşmak gerçekten de mümkündür. Bunun bir örneğine tanık olmak için "Takma adlar kullanılarak hız sınırlamasının atlanması" başlıklı bölüme bakın.
Bunu akılda tutarak API'nizi Brute Force saldırılarına karşı korumak için almanız gereken bazı tasarımsal önlemler vardır. Bu öncelikle API'nin kabul ettiği sorguların karmaşıklığının sınırlandırılmasını ve saldırganların hizmet reddi (DoS) saldırıları gerçekleştirme şansını en aza indirmeyi gerektirir.
Brute force'a karşı koyabilmek için:
1-Lütfen API sorgularınızın sorgu derinliğini sınırladığınızdan emin olun. "Sorgu derinliği" kavramı, bir sorgu içindeki iç içe geçme düzeylerinin sayısıyla ilgilidir. Aşırı düzeyde iç içe geçme içeren sorguların performans üzerinde dikkate değer bir etkiye sahip olabileceğini unutmayın. Ayrıca, bu tür sorguların kısıtlama olmaksızın kabul edilmesi halinde Hizmet Reddi (DoS) saldırıları için bir fırsat sunabileceğinin kabul edilmesi çok önemlidir. API'nizin kabul ettiği sorgu derinliğine sınırlamalar getirerek bu sorunlarla karşılaşma olasılığını etkili bir şekilde azaltabilirsiniz.
2-Ayrıca API'niz için işlem sınırlarını yapılandırmanız önemle tavsiye edilir. Bu sınırlar, API'nizin kabul edebileceği maksimum benzersiz alan, takma ad ve root alan sayısını tanımlamanıza olanak tanır. Uygun çalışma limitlerini ayarlayarak API'nizin istenen parametrelerde çalışmasını sağlayabilir, böylece genel verimliliğini ve güvenliğini artırabilirsiniz.
3-Lütfen bir sorgunun içerebileceği maksimum bayt sayısını yapılandırmak için biraz zaman ayırın. Bu, API'nizin optimum performansını sağlamada önemli bir adımdır.
4-Ek olarak, API'nizde maliyet analizinin uygulanmasını düşünmenizi önermek isterim. Maliyet analizi, bir kitaplık uygulamasının, sorgular alındıkça çalıştırılmasıyla ilişkili kaynak maliyetini belirlemesine olanak tanıyan değerli bir süreçtir. Bu analizi gerçekleştirerek, bir sorgunun çalıştırılamayacak kadar hesaplama açısından karmaşık olup olmayacağını belirleyebilirsiniz. Bu gibi durumlarda API, sorguyu bırakarak sistemin performansı üzerinde herhangi bir olumsuz etki oluşmasını önler.
5-Bir sorgunun içerebileceği maksimum bayt miktarını yapılandırarak ve maliyet analizi uygulayarak API'nizin verimliliğini ve etkililiğini güvenle optimize edebilirsiniz.
GraphQL üstünden CSRF'yi Önlemek
Özellikle GraphQL CSRF güvenlik açıklarına önlem alırken API'nizi tasarımıyla ilgili aşağıdakilerden emin olun:
1-API'niz yalnızca JSON kodlu POST üzerinden yapılan sorguları kabul edeceğinden,
2-API, sağlanan içeriğin sağlanan içerik türüyle eşleştiğini doğrulamasından,
3-API'nin güvenli bir CSRF token mekanizması olup olmadığından EMİN OLUN.
portswigger.net
GraphQL açıkları genellikle uygulama hatalarından ve tasarım kusurlarından kaynaklanır. Örneğin introspection özelliği açık bırakılmış olabilir, bu da saldırganların API'yi şema hakkında bilgi edinmek için sorgulamasına olanak tanır.
GraphQL saldırıları, saldırganın veri elde etmesine veya yetkisiz eylemler gerçekleştirmesine olanak tanıyan kötü niyetli isteklerden oluşur. Bu saldırılar ciddi bir etki yaratabilir. Kullanıcı sorguları manipüle ederek veya CSRF açığı kullanarak yönetici ayrıcalıkları elde edebiliyorsa sıkıntı büyük demektir.
Bu bölümde GraphQL API'lerini test etmenin yollarını inceleyeceğiz. GraphQL'e aşina değilseniz dert etmeyin ayrıntılardan ilerledikçe bahsedeceğiz. Ayrıca, öğrendiklerinizi pratiğe dökebileceğiniz bazı lableri de konu sonunda yorum olarak verdik.
GraphQL Endpoints(Uç noktaları) bulma
Bir GraphQL API'sini test etmeden önce, önce uç noktasını bulmanız gerekir. GraphQL API'leri tüm istekler için aynı uç noktayı kullandığından, bu değerli bir bilgidir.
Not: Bu bölüm, GraphQL uç noktalarını manuel olarak nasıl bulacağınızı açıklar. Ancak Burp Scanner, tarama sırasında otomatik olarak GraphQL uç noktalarını kontrol edebilir. "GraphQL endpoint found/GraphQL uç nokta bulundu" yazar ve böylece herhangi bir uç noktanın bulunduğunu anlamış olursunuz.
Evrensel sorgular
Herhangi bir GraphQL uç noktasına query{__typename} gönderirseniz, yanıtında bir yerlerde {"data": {"__typename": "query"}} dizesini içerecektir. Bu, evrensel sorgu olarak bilinir ve bir URL'nin bir GraphQL servisine karşılık gelip gelmediğini test etmek için kullanışlı bir tooldur.
Sorgu, her GraphQL uç noktasının __typename olarak adlandırılan ve sorgulanan nesnenin türünü bir String olarak döndüren ayrılmış bir alana sahip olması nedeniyle çalışır.
Ortak uç nokta adları
GraphQL hizmetleri genellikle benzer uç nokta eklerini kullanır. GraphQL uç noktalarını test ederken, aşağıdaki konumlara evrensel sorgular göndermeye çalışmalısınız:
Kod:
/graphql
/api
/api/graphql
/graphql/api
/graphql/graphqlEğer bu uç noktalar bir GraphQL yanıtı döndürmüyorsa pathe /v1 eklemeyi de deneyebilirsiniz.
Not: GraphQL hizmetleri genellikle herhangi bir GraphQL dışı isteğe "query not present" veya benzer bir hata ile yanıt verir bu hatanın anlamı sorgu mevcut değil demektir. GraphQL uç noktalarını test ederken bunu aklınızda bulundurmalısınız.
Request Yöntemleri
GraphQL uç noktalarını bulmaya çalışmanın bir sonraki adımı, farklı (request)istek yöntemlerini test etmektir. Production GraphQL uç noktalarının yalnızca application(uygulama)/json içerik türüne sahip POST istekleri kabul etmesi en iyi uygulamadır, çünkü bu CSRF açıklarından da korunmaya yardımcı olur. Ancak, bazı uç noktalar alternatif yöntemler kabul edebilir. Buna örnek olarak GET istekleri veya x-www-form-urlencoded içerik türüne sahip POST istekleri verilebilir. Ortak uç noktalara POST istekleri göndererek GraphQL uç noktasını bulamazsanız, alternatif HTTP yöntemlerini kullanarak evrensel sorguyu yeniden göndermeyi deneyin.
Initial testing
Uç noktanın nasıl çalıştığını biraz daha anlamak için uç noktayı keşfettikten sonra bazı test istekleri gönderebilirsiniz. Uç nokta bir web sitesini çalıştırıyorsa, Burp'ın tarayıcısında web arayüzünü keşfetmeyi ve gönderilen sorguları incelemek için HTTP geçmişini kullanmayı deneyin.
Parametrelerden Faydalanmak
Bu noktada, güvenlik açıkları aramaya başlayabilirsiniz. Sorgu parametrelerini test etmek iyi bir başlangıç olur. API, nesnelere doğrudan erişmek için parametreler kullanıyorsa, (access control vulnerabilities) erişim kontrol açıklarına karşı savunmasız olabilir. Bir kullanıcı, yalnızca o bilgiye karşılık gelen bir argüman sağlayarak sahip olmaması gereken bilgiye potansiyel olarak erişebilir. Bu Insecure direct object reference yani Güvensiz doğrudan nesne referansı olarak da bilinir. (IDOR)
Örneğin aşağıdaki sorgu bir online shop için ürün listesi istiyor
Kod:
#Example product query
query {
products {
id
name
listed
}
}response a bakalım
Kod:
#Example product response
{
"data": {
"products": [
{
"id": 1,
"name": "Product 1",
"listed": true
},
{
"id": 2,
"name": "Product 2",
"listed": true
},
{
"id": 4,
"name": "Product 4",
"listed": true
}
]
}
}Bu bilgilerden şu sonuçlara ulaşabiliriz:
Ürünlere ardışık şekilde bir ID atanıyor
ID'si 3 olan ürün yok delist olmuş yüksek ihtimalle
Bu kayıp ürünün ID'sini Shop'ta listelenmemiş olsa bile sorgulayarak detaylarını öğrenebiliriz.
Kod:
#Query to get missing product
query {
product(id: 3) {
id
name
listed
}
}bize gelen response:
Kod:
#Missing product response
{
"data": {
"product": {
"id": 3,
"name": "Product 3",
"listed": no
}
}
}Şema Bilgilerini Keşfetme
API'yi test etmenin bir sonraki adımı, temel şema hakkında bilgileri bir araya getirmektir. Bunu yapmanın en iyi yolu, introspection sorguları kullanmaktır. Introspection bir serverdan şema hakkında bilgi sorgulayabileceğiniz bir GraphQL fonksiyonudur.
Introspection, bir GraphQL API'siyle nasıl etkileşime geçebileceğinizi anlamanıza yardımcı olur. Ayrıca potansiyel olarak hassas verileri de (açıklama alanları gibi) ortaya çıkartmanıza yardımcı olur.
Introspection Kullanma
Şema bilgilerini keşfetmek için __schema alanını sorgulayabilirsiniz. Bu alan, tüm sorguların root(kök) kısmında mevcuttur. Normal sorgular gibi, bir introspection sorgusu çalıştırırken döndürülmesini istediğiniz yanıtın alanlarını ve yapısını belirtebilirsiniz. Örneğin, yanıtın yalnızca mevcut türün adlarını içermesini isteyebilirsiniz.
Production ortamlarında introspection'un devre dışı bırakılması en doğrusudur. Ama herkes bu tavsiyeye uymaz.
Aşağıdaki basit sorguyu kullanarak inceleme yapabilirsiniz fakat introspection eğer devre dışı değilse response bütün mevcut sorguların adlarını döndürecektir.
Kod:
#Introspection probe request
{
"query": "{__schema{queryType{name}}}"
}Not:
Burp Scanner, taramaları sırasında otomatik olarak introspection için test yapabilir. Introspection etkinleştirilmişse, "GraphQL introspection enabled" diye bize bildirir.
Tam Introspection sorgusu çalıştırma
Bir sonraki adım, mümkün olduğunca fazla bilgi almak için uç noktaya karşı tam bir introspection sorgusu çalıştırmaktır.
Aşağıdaki örnek sorgu bir sürü detay döndürecektir:
Kod:
#Full introspection query
query IntrospectionQuery {
__schema {
queryType {
name
}
mutationType {
name
}
subscriptionType {
name
}
types {
...FullType
}
directives {
name
description
args {
...InputValue
}
onOperation #Often needs to be deleted to run query
onFragment #Often needs to be deleted to run query
onField #Often needs to be deleted to run query
}
}
}
fragment FullType on __Type {
kind
name
description
fields(includeDeprecated: true) {
name
description
args {
...InputValue
}
type {
...TypeRef
}
isDeprecated
deprecationReason
}
inputFields {
...InputValue
}
interfaces {
...TypeRef
}
enumValues(includeDeprecated: true) {
name
description
isDeprecated
deprecationReason
}
possibleTypes {
...TypeRef
}
}
fragment InputValue on __InputValue {
name
description
type {
...TypeRef
}
defaultValue
}
fragment TypeRef on __Type {
kind
name
ofType {
kind
name
ofType {
kind
name
ofType {
kind
name
}
}
}
}Not: Eğer introspection etkinleştirilmişse ancak yukarıdaki sorgu çalışmıyorsa, sorgu yapısından onOperation, onFragment ve onField'ı kaldırmayı deneyin. Birçok uç nokta, introspection sorgusu içinde bunları kabul etmez ve bunları kaldırarak daha fazla başarı şansı elde etmiş olursunuz.
notlar:
*GraphQL: API'ler için açık kaynaklı bir veri sorgulama ve işleme dili ve bu sorguları yerine getirmek için yazılmış uygulamalardır. GraphQL, 2012'de Facebook tarafından dahili olarak geliştirildi ve 2015'te herkese açık olarak yayınlandı
Introspection: GraphQL, geliştiricilerin mevcut türler, alanlar ve işlemler hakkında ayrıntılar sağlayan API şemasını sorgulamasına olanak tanır. Bu iç gözlem özelliği, API'yi keşfetme ve anlama sürecini basitleştirir.
*Endpoint: Endpoint, api üzerinde belirli bir amaç için oluşturulan metodlara verilen isimdir. Http, günümüz teknolojisinde en yaygın kullanılan istemci ve sunucu arası haberleşme protokolüdür. Http Request ise api üzerinde oluşturulan çeşitli özelliklere sahip endpointlerin, Http protokolü kullanılarak talep iletmesidir.
çeviren: @Gauloran
_________________________________________________________________
..SHELDON
Introspection Sorgulamalarını Görselleştirme
introspection sorgularına verilen yanıtlar zengin miktarda bilgi sağlayabilir, ancak aynı zamanda oldukça uzun ve anlaması zor da olabilir.
Şema varlıkları arasındaki ilişkilerin daha iyi anlaşılmasını kolaylaştırmak için GraphQL görselleştiricisi kullanılmalıdır. Bu çevrimiçi araç, bir sorgunun sonuçlarını alır ve döndürülen verilerin görsel bir temsilini oluşturarak işlemler ve türler arasındaki bağlantıları vurgular.
InQL'i kullanma
Bir introspection sorgusu çalıştırma ve sonuçları görselleştirme sürecini kolaylaştırmak için Burp Suite'in InQL uzantısını kullanmanızı öneririm.
Burp Suite'in bir uzantısı olan InQL, GraphQL API'lerinin güvenli denetimlerini gerçekleştirmek için değerli bir araç olarak hizmet eder. InQL, bir URL girerek (canlı uç nokta bağlantısı aracılığıyla veya bir JSON dosyası yükleyerek), tüm sorguları ve mutasyonları talep eden bir introspection sorgusu başlatır. Daha sonra, sonuçların zahmetsizce araştırılmasını kolaylaştıran bir görünğm sunar.
Burp Suite'de daha fazla InQL kullanımı için: Tıkla bana
Öneriler
İç gözlemin yokluğunda, kişi ara sıra önerilerden yararlanarak bir API'nin yapısına ilişkin içgörüler elde edebilir.
Apollo GraphQL platformunun dikkate değer bir özelliği olan öneriler, sunucunun hata mesajları aracılığıyla sorgu değişiklikleri önermesine olanak tanır. Bu işlevsellik, bir sorgu hala tanımlanabilecek küçük hatalar içerdiğinde özellikle yararlı olur.
(Örnepin , 'productInfo' için herhangi bir sonuç yok. Şunu mu kastettiniz? 'productInformation' ).
"Clairvoyance", iç gözlem devre dışı bırakıldığında bile GraphQL şema bilgilerini almak için kullanışlı bir araçtır. Yararlı öneriler sunarak zaman tasarrufu sağlar. Apollo'nun önerileri devre dışı bırakmanın doğrudan bir yolu yoktur, ancak buna GitHub başlığında bir geçici çözüm bulabilirsiniz.
Not:
Burp Scanner otomatik olarak kendi taramasının parçası olarak öneriler için test yapabilir. Aktif bir öneri bulunur ise Burp, "GraphQL suggestions enabled" (GraphQL önerileri aktif) diye uyarı verir.
GraphQL içgözlemini Bypass Etmek
Test ettiğiniz API için sorgulamaları çalıştırmada zorluk yaşıyorsanız, " __schema" 'dan sonra sonra özel bir karakter ekleyin.
İç gözlemi devre dışı bırakan geliştiriciler, sorgularda __schema anahtar sözcüğünü hariç tutmak için sıklıkla normal ifadeler (regex) kullanır. Boşluklar, yeni satırlar ve virgüller gibi karakterlerle denemeler yapmanız önerilir; çünkü bunlar GraphQL tarafından göz ardı edilir ancak flawed regex'ler tarafından göz ardı edilmez.
Geliştiricinin yalnızca __schema{'yı görmezden gelmesi durumunda aşağıda sağlanan iç gözlem sorgusunun da görmezden gelineceği bilinmelidir:
#Introspection query with newline
{
"query": "query{__schema
{queryType{name}}}"
}Bu çalışmazsa alternatif bir request methodu deneyin (malum yalnızca POST üzerinden devre dışı bırakılabiliyor o yüzden GET requesti yapmaya çalışın veya
x-www-form-urlencoded içerikli bir POST request'i yapın
Aşağıdaki örnek bize URL ile kodlanmış parametreler aracılığıyla GET sorgusu gönderen bir iç gözlem probu yer almaktadır
# Introspection probe as GET request
GET /graphql?query=query%7B__schema%0A%7BqueryType%7Bname%7D%7D%7D
Not:
GET yöntemi aracılığıyla yalnızca iç gözlem sorgularını kabul eden bir uç noktayla karşılaşırsanız ve sorgu sonuçlarını InQL Tarayıcıyı kullanarak analiz etmek istiyorsanız, sorgu sonuçlarını bir dosyaya kaydetmenizin zorunlu olduğunu lütfen unutmayın. Dosya kaydedildikten sonra onu standart ayrıştırma sürecinden geçeceği InQL'e yüklemeye devam edebilirsiniz.
Sahte İsimler Kullanarak Hız Limitini Bypass Etmek
GraphQL alanında nesnelerin aynı adı taşıyan birden fazla özelliği barındırmaktan kaçınması gerekir. Ancak korkmayın, çünkü sizi bu kısıtlamadan kurtaracak takma adlar mevcuttur. Takma adlar kullanarak API'nin sağlamasını istediğiniz özellikleri açıkça belirleme gücüne sahip olursunuz. Bu da size tek bir istekte aynı türden nesnenin birden çok örneğini temin etme olanağı sağlar.
Takma adlar, öncelikle API çağrılarının sıklığını azaltmak için tasarlanmış olsa da, GraphQL uç noktasından zorla yararlanmak için de kullanılabilir.
Pek çok uç noktanın, brute force saldırılarını engellemek için bir güvenlik önlemi olarak hız sınırlayıcıları içerdiğini belirtmekte fayda var. Bu hız sınırlayıcılar, uç noktada yürütülen işlem sayısına değil, aksine alınan HTTP isteklerinin sayısına göre çalışır. Ancak takma adlar, tek bir HTTP mesajı içinde birden fazla sorgunun iletilmesine izin vererek bu korumayı aşma yeteneğine sahiptir. Sonuç olarak bu, yukarıda belirtilen kısıtlamanın atlanmasına olanak sağlar.
Aşağıdaki basitleştirilmiş örnekte de göreceğiniz üzere mağaza indirim kodlarının geçerliliğini doğrulamak için kullanılan takma ad sorgularının bir dizisi kullanılıyor. Bu özel işlem, tek bir HTTP isteğinin çalışma prensibi nedeniyle hız sınırlayıcı önlemleri atlatma potansiyeline sahiptir. Bu yöntemin aynı anda birden fazla sayıda indirim kodunu kontrol edebileceğini de belirtmekte fayda var.
#Request with aliased queries
query isValidDiscount($code: Int) {
isvalidDiscount(code:$code){
valid
}
isValidDiscount2:isValidDiscount(code:$code){
valid
}
isValidDiscount3:isValidDiscount(code:$code){
valid
}
}GraphQL CSRF
Bir uygulamada Siteler Arası İstek Sahteciliği (CSRF) güvenlik açıkları mevcutsa kullanıcılar tarafından istenmeyen eylemlerin gerçekleştirilmesine yol açabilir. Bu durum, bir saldırganın kötü amaçlı bir web sitesi oluşturarak güvenlik açığı bulunan uygulamaya hileli bir şekilde alanlar arası istek başlatması durumunda ortaya çıkar. Bu tür güvenlik açıkları, etkilenen sistemin güvenliği ve bütünlüğü açısından önemli bir risk oluşturabilir.
GraphQL, uygulanmasında Siteler Arası İstek Sahteciliği (CSRF) saldırıları için bir kanal görevi görme potansiyeline sahiptir. Bu özel saldırı türü, saldırganın, kurbanın web tarayıcısını farkında olmadan kurban kullanıcı adına kötü niyetli bir sorgu iletmesine yol açtığında meydana gelir. CSRF saldırılarının, mağdur kullanıcının bilgisi veya rızası olmadan yetkisiz eylemler gerçekleştirmesine yol açabileceğinden, bir uygulamanın güvenliği için önemli bir tehdit oluşturabileceğini unutmamak önemlidir.
GraphQL Üstünden CSRF Güvenlik Açıkları Nasıl Oluşur?
GraphQL uç noktasının aldığı isteklerin içerik türünü doğrulamada başarısız olduğu ve CSRF belirteçlerini uygulamayı ihmal ettiği durumlarda CSRF güvenlik açıkları potansiyel olarak ortaya çıkabilir.
Bir uygulama/json içerik türünü kullanan POST istekleri söz konusu olduğunda, içerik türünün uygun şekilde doğrulanması koşuluyla genellikle sahteciliğe karşı güvenli kabul edilir. Bu gibi durumlarda, kurban kötü amaçlı bir web sitesini ziyaret etse bile, saldırgan kurbanın tarayıcısını bu özel isteği gönderecek şekilde yönlendiremez.
Ancak, GET istekleri veya x-www-form-urlencoded içerik türünü kullanan herhangi bir istek gibi alternatif yöntemlerin aslında bir tarayıcı tarafından gönderilebileceğini belirtmekte fayda var. Sonuç olarak söz konusu uç noktanın bu tür istekleri kabul etmesi durumunda kullanıcılar kendilerini olası saldırılara karşı savunmasız bulabilir. Bu senaryolarda saldırganlar, API'ye gönderilecek kötü amaçlı istekleri ustalıkla hazırlayarak bu güvenlik açığından yararlanabilir.
GraphQL Saldırılarını Önleme
GraphQL saldırılarını önlemek için API'nizi dağıtırken şu adımları izleyin:
1. API'niz genel kullanım için değilse iç gözlemi devre dışı bırakın. Bu, saldırganların API hakkında bilgi sahibi olmasını zorlaştırır ve bilgilerin ifşa edilmesi riskini azaltır.
Apollo GraphQL'de iç gözlemi devre dışı bırakma talimatları için bu blog gönderisini okuyun.
Bana tıkla dostum
2.API'nizin genel halk tarafından kullanılması amaçlanıyorsa, iç gözlemin etkin kalması zorunludur. Ancak istenmeyen alanların kamuya açıklanmamasını sağlamak için API şemasını kapsamlı bir şekilde incelemek çok önemlidir.
3.Önerileri tereddüt etmeden devre dışı bırakın. Bu, saldırganların temel şema hakkında bilgi çıkarmak amacıyla Durugörü veya benzer araçlardan yararlanma girişimlerini etkili bir şekilde engelleyecektir.
4.Önerileri doğrudan Apollo'da devre dışı bırakmak ne yazık ki mümkün değil. Ancak bir geçici çözüm mevcuttur. Daha fazla ayrıntı için lütfen bu GitHub konusuna bakın.
5.API şemanızın, e-posta adresleri veya kullanıcı kimlikleri gibi herhangi bir özel kullanıcı alanını yanlışlıkla açığa çıkarmadığından emin olmak için büyük özen gösterin.
GraphQL Brute Force Saldırılarını Engellemek
GraphQL API'lerini kullanırken bazen standart hız sınırlamasını aşmak gerçekten de mümkündür. Bunun bir örneğine tanık olmak için "Takma adlar kullanılarak hız sınırlamasının atlanması" başlıklı bölüme bakın.
Bunu akılda tutarak API'nizi Brute Force saldırılarına karşı korumak için almanız gereken bazı tasarımsal önlemler vardır. Bu öncelikle API'nin kabul ettiği sorguların karmaşıklığının sınırlandırılmasını ve saldırganların hizmet reddi (DoS) saldırıları gerçekleştirme şansını en aza indirmeyi gerektirir.
Brute force'a karşı koyabilmek için:
1-Lütfen API sorgularınızın sorgu derinliğini sınırladığınızdan emin olun. "Sorgu derinliği" kavramı, bir sorgu içindeki iç içe geçme düzeylerinin sayısıyla ilgilidir. Aşırı düzeyde iç içe geçme içeren sorguların performans üzerinde dikkate değer bir etkiye sahip olabileceğini unutmayın. Ayrıca, bu tür sorguların kısıtlama olmaksızın kabul edilmesi halinde Hizmet Reddi (DoS) saldırıları için bir fırsat sunabileceğinin kabul edilmesi çok önemlidir. API'nizin kabul ettiği sorgu derinliğine sınırlamalar getirerek bu sorunlarla karşılaşma olasılığını etkili bir şekilde azaltabilirsiniz.
2-Ayrıca API'niz için işlem sınırlarını yapılandırmanız önemle tavsiye edilir. Bu sınırlar, API'nizin kabul edebileceği maksimum benzersiz alan, takma ad ve root alan sayısını tanımlamanıza olanak tanır. Uygun çalışma limitlerini ayarlayarak API'nizin istenen parametrelerde çalışmasını sağlayabilir, böylece genel verimliliğini ve güvenliğini artırabilirsiniz.
3-Lütfen bir sorgunun içerebileceği maksimum bayt sayısını yapılandırmak için biraz zaman ayırın. Bu, API'nizin optimum performansını sağlamada önemli bir adımdır.
4-Ek olarak, API'nizde maliyet analizinin uygulanmasını düşünmenizi önermek isterim. Maliyet analizi, bir kitaplık uygulamasının, sorgular alındıkça çalıştırılmasıyla ilişkili kaynak maliyetini belirlemesine olanak tanıyan değerli bir süreçtir. Bu analizi gerçekleştirerek, bir sorgunun çalıştırılamayacak kadar hesaplama açısından karmaşık olup olmayacağını belirleyebilirsiniz. Bu gibi durumlarda API, sorguyu bırakarak sistemin performansı üzerinde herhangi bir olumsuz etki oluşmasını önler.
5-Bir sorgunun içerebileceği maksimum bayt miktarını yapılandırarak ve maliyet analizi uygulayarak API'nizin verimliliğini ve etkililiğini güvenle optimize edebilirsiniz.
GraphQL üstünden CSRF'yi Önlemek
Özellikle GraphQL CSRF güvenlik açıklarına önlem alırken API'nizi tasarımıyla ilgili aşağıdakilerden emin olun:
1-API'niz yalnızca JSON kodlu POST üzerinden yapılan sorguları kabul edeceğinden,
2-API, sağlanan içeriğin sağlanan içerik türüyle eşleştiğini doğrulamasından,
3-API'nin güvenli bir CSRF token mekanizması olup olmadığından EMİN OLUN.
GraphQL API vulnerabilities | Web Security Academy
GraphQL vulnerabilities generally arise due to implementation and design flaws. For example, the introspection feature may be left active, enabling ...
portswigger.net
Moderatör tarafında düzenlendi:
