Graphql nasıl güvence altına alınır

GraphQL’deki ortak güvenlik açıklarının bir özeti ve bunların azaltma stratejileri.

GraphQL, müşterilerin tam olarak ihtiyaç duydukları verileri istemelerine izin vererek geleneksel dinlenme API’lerine kıyasla üstün esneklik ve verimlilik sağlar. Ancak, bu esneklik benzersiz güvenlik zorlukları ortaya koymaktadır. Düzgün ele alınmazsa, bunlar veri sızıntılarına, hizmetlerin reddedilmesine ve ayrıcalık artış sorunlarına yol açabilir.

Bu yazıda, GraphQL ile ilgili büyük güvenlik tehditlerini açıklayacağım ve GraphQL tabanlı uygulamaları korumak için pratik stratejiler sağlayacağım. Temel ilke, güvenlik kontrollerini yalnızca ağ sınırında değil, aynı zamanda uygulama mantığının derinliklerinde de uygulamaktır.

Graphql isteği yaşam döngüsü

Güvenli bir GraphQL istek işleme akışı, birkaç doğrulama ve doğrulama katmanı içerir.

 graph TD
    A[Client Request] --> B{HTTP Middleware};
    B --> C{Authentication};
    C -- Authenticated --> D[Parse Query];
    C -- Failed --> Z[Reject Request];
    D --> E{Validation};
    E -- Cost/Depth OK --> F[Execute Resolvers];
    E -- Invalid Query --> Z;
    F -- For each field --> G{Authorization Check};
    G -- Authorized --> H[Fetch Data];
    G -- Unauthorized --> I[Return Null/Error];
    H --> J[Format Response];
    I --> J;
    J --> K[Return to Client];

    subgraph "Pre-Execution"
        B
        C
        D
        E
    end

    subgraph "Execution"
        F
        G
        H
        I
    end

İçgözlemin kötüye kullanılması

Sorun: Intrumpection, müşterilerin tüm türleri, alanları, sorguları ve mutasyonları ortaya çıkararak GraphQL şemasını sorgulamasına izin verir. Geliştirme araçları için yararlı olsa da, saldırganlara API’nizin tüm yapısının bir haritasını verir.
Azaltma: Üretim ortamlarında içgözlemi devre dışı bırakın. Bu genellikle GraphQL Server kitaplığınızda bir yapılandırma bayrağı olarak kullanılabilir. Örneğin, apollo-serversunucuyu somutlaştırırken ayarlayabilirsiniz:

const server = new ApolloServer({
  typeDefs,
  resolvers,
  introspection: process.env.NODE_ENV !== 'production'
});

Hizmet Reddi (DOS)

Sorun: Saldırganlar, aşırı sunucu kaynaklarını tüketen derin iç içe veya karmaşık sorgular hazırlayabilir ve bu da meşru kullanıcılar için hizmet reddine neden olabilir.
Hafifletmeler:
- Sorgu Derinlik Sınırlama: Sorguların maksimum yuvalama seviyesini kısıtlayın. Örneğin, 10’dan fazla seviye derinlikte yuvalanmış sorguları reddet.
- Sorgu Maliyet Analizi: Hesaplama karmaşıklığına göre her alana sayısal “maliyetler” atayın. Sorguları yürütmeden önce toplam maliyeti hesaplayın ve önceden tanımlanmış bir eşiği aşarsa reddedin.
- Zaman aşımları: Uzun süredir devam eden sorguların süresiz olarak işgal edilen sunucu kaynaklarını önlemek için sorgu yürütülmesine zorlanan zaman aşımlarını ayarlayın.
- Miktar Sınırlama (Sayfa): Her zaman bir listeden döndürülebilecek kayıt sayısını sınırlayın. Müşterilerin sınırsız ürün istemelerine asla izin vermeyin.

Yetkilendirme Kusurları

Sorun: Graphql çözücüler belirli alanlar için verileri getirir. İzin kontrolleri her bir nesne için çözücü düzeyinde gerçekleştirilmezse, saldırganlar görme iznine sahip olmamaları gereken verilere erişebilir. Bu klasik bir güvensiz doğrudan nesne referansı (Idor) güvenlik açığı yoludur.
Azaltma: İlgili her bir çözümleyici veya ara katman katmanları olarak izin kontrolleri uygulayın. Talep edilen her veri parçası için, uygulama şu anda kimlik doğrulamalı kullanıcının bu verileri görüntüleme veya değiştirme iznine sahip olduğunu doğrulamalıdır. Kimlik doğrulamayı yalnızca uç nokta düzeyinde kontrol etmek yeterli değildir.

const resolvers = {
  Query: {
    user: (parent, { id }, context) => {
      // Permission check: Does the logged-in user have rights to view this profile?
      if (context.user.id !== id && !context.user.isAdmin) {
        throw new Error('You do not have permission to view this user');
      }
      return db.users.find({ id: id });
    }
  }
};

Yetersiz hata işleme

Sorun: Yığın izleri veya veritabanı hataları gibi ayrıntılı hata mesajları, arka uç altyapınız, kullanılan kütüphaneler ve veritabanı şeması hakkında hassas bilgileri sızdırabilir.
Azaltma: Tüm istisnaları yakalayan küresel hata işleyicilerini uygulayın. Dahili hata ayıklama amacıyla ayrıntılı hataları kaydedin, ancak sterilize edilmiş, jenerik hata mesajlarını istemcilere döndürün. Gibi kütüphaneler graphql-errors bu süreci resmileştirmeye yardımcı olabilir.

Kimlik doğrulama

Sorun: GraphQL, taşıma tabakası bağımsızdır ve belirli bir kimlik doğrulama mekanizmasını zorlamamaktadır. Bunu doğru bir şekilde uygulamak geliştiricilere kalmış.
Azaltma: GraphQL uç noktalarını diğer hassas API uç noktaları gibi ele alın. OAuth 2.0 veya JWTS gibi standart kimlik doğrulama mekanizmalarını uygulayın. Tokenler Authorization HTTP başlığı ve sorgular işlenmeden önce bir ara katman yazılımı katmanında doğrulandı. Doğrulanmış kullanıcı bilgileri GraphQL’de saklanmalıdır context Çözücüler için nesne.

Çözüm

GraphQL API’lerinin güvencesi, geleneksel uç nokta tabanlı güvenlik modellerinden düşünmede bir değişim gerektirir. GraphQL’in esnek doğası, güvenliğin temel uygulama mantığının ayrılmaz bir parçası olması gerektiği anlamına gelir.

Üretim ortamlarında içgözlemi devre dışı bırakarak, kaynak tükenme saldırılarına karşı güçlü kontroller uygulayarak, çözümleyiciler içinde nesne düzeyinde yetkilendirmeyi uygulayarak ve hata yanıtlarını dikkatlice yöneterek, geliştiriciler sağlam ve güvenli grafik uygulamaları oluşturabilir. Güvenlik, sonunda eklenecek bir özellik değil, geliştirme yaşam döngüsü boyunca dikkate almak için temel bir gerekliliktir.

Source link

Graphql nasıl güvence altına alınır | Hahwul