API'ler internetteki en cazip DDoS hedefleri arasındadır ve sebep ekonomidir. Bir HTML sayfası önbelleklenip bir uçtan neredeyse bedava sunulabilir; bir API çağrısı tam tersidir — nadiren önbelleklenebilir, genelde bir iki veritabanı sorgusu çalıştırır ve uçları çoğu zaman herkese açık belgelendiği için bir saldırgan hangilerinin pahalı olduğunu tam olarak bilir. Sonuç kötü bir asimetridir: saniyede birkaç yüz ucuz istek, arka ucunuzu %100 CPU'da sabitleyebilirken pazarlama siteniz 200 OK dönmeye devam eder, böylece kesinti, müşteriler uygulamanın çalışmadığından şikâyet edene kadar görünmezdir.
Bir API'yi savunmak dolayısıyla ham trafik hacminden çok, her isteğin maliyetiyle ilgilidir. Amaç, suistimalci bir isteğin saldırgana bir şeye mal olmasını ve pahalı bir ucun meşru, kimliği doğrulanmış bir çağıran olmayan her şeyi reddetmesini sağlamaktır.
REST API'leri Neden Vurulur?
- Uç sayımı: kendi belgeleriniz her pahalı işlemi açığa çıkarır, böylece saldırganlar keşfi atlar ve doğrudan arama, dışa aktarma ve rapor yollarına gider.
- Durumsuz kimlik doğrulama: JWT'ler, bir botun saldırgana hiçbir sunucu-tarafı oturum maliyeti olmadan binlerce paralel 'kimliği doğrulanmış' oturum tutmasını önemsizleştirir.
- Önbelleklenmemiş yanıtlar: statik bir sayfanın aksine, çoğu API yanıtı dinamiktir, dolayısıyla her tek istek veritabanınıza ulaşır.
- Webhook ve geri-çağrı selleri: gelen POST'ları kabul eden herhangi bir uç (ödeme geri çağrıları, entegrasyonlar), çağıran bir makine olduğu için sınanamayan bir hedeftir.
GraphQL Neden Daha Kötüdür?
GraphQL, tüm bu riskleri esnek olmak üzere tasarlanmış tek bir ucun arkasında yoğunlaştırır — ki bir saldırganın sömürdüğü tam olarak budur.
- İç gözlem (introspection) suistimali: tek bir sorgu tüm şemanızı döndürür, saldırgana her pahalı alanın haritasını verir.
- Sorgu-derinliği saldırıları: derinlemesine iç içe bir sorgu, tek bir küçük istekten veritabanında üstel birleştirmeler (join) zorlayabilir.
- Toplu (batched) sorgular: tek bir HTTP isteğine yüzlerce ya da binlerce işlem paketlenebilir, böylece istek-başına hız sınırlama onu tek sayar.
- Takma adlı (aliased) alanlar: aynı pahalı alan, tek bir sorguda farklı takma adlar altında binlerce kez istenebilir.
Bir API Nasıl Sertleştirilir?
- Yalnızca IP başına değil, API anahtarı ya da belirteç başına hız sınırlayın — bir saldırgan IP'leri döndürür ama kimlik bilgisi (ya da yokluğu) gerçek kimliktir.
- Uç-başına limitler ayarlayın: /search ya da /export, /health ya da /product'tan çok daha sıkı limitleri hak eder.
- Üretimde GraphQL iç gözlemini devre dışı bırakın ve sorgu derinliği ile karmaşıklık limitleri dayatın.
- Sunulması pahalı 'genel' uçlarda bile kimlik doğrulama isteyin, böylece anonim seller uçta ucuza reddedilsin.
- Önbelleklenebilir olan her şeyi, kısa süreliğine bile, önbellekleyin — sıcak bir okumada 10 saniyelik bir önbellek, bir seli birkaç sunucu vuruşuna indirger.
Maliyet asimetrisi işin tamamıdır
İyi bir API savunması ekonomiyi tersine çevirir: saldırganın isteğini pahalı (bir sınama, reddedilen bir belirteç, bir hız-limiti) ve sizin yanıtınızı ucuz (önbelleklenmiş ya da reddedilmiş bir cevap) yapın. Saldırganı ölçekte yenmeye çalışmıyorsunuz; saldırıyı çalıştırmaya değmez hâle getirmeye çalışıyorsunuz.
Akarguard Nereye Uyar?
Akarguard API'nizin önünde bir Layer 7 ters vekili olarak oturur, böylece her istek sunucunuza ulaşmadan incelenir ve sunucu IP'niz gizli kalır ki doğrudan saldırılamasın. Panelden alan-başına ve uç-başına hız ve bağlantı limitleri ayarlar, bozuk ya da kötü niyetli yükleri engellemek için WAF kuralları uygular ve bir sel tespit edildiğinde otomatik azaltmanın korumayı yükseltmesine izin verirsiniz. Ödeme geri çağrıları ve API tüketicileri gibi tarayıcı olmayan istemciler, asla çözemeyecekleri bir ara sınama yerine hız sınırlama ve filtrelemeyle ele alınır. İyi API tasarımının yerini almaz — derinlik limitleri, kimlik doğrulama ve önbellekleme hâlâ sizin ayarlamanızdır — ama onları uygulamak için uygulamanın önünde bir dayatma noktası verir.