API Attacks 104: Rate Limit Yoksa, API Kötüye Kullanılabilir

Bir API endpoint'i doğru çalışıyor olabilir, kullanıcı giriş yapıyor olabilir, yetki kontrolü de belirli ölçüde uygulanıyor olabilir, response içinde fazla veri de dönmüyor olabilir. Ama bu yine de API'nin güvenli olduğu anlamına gelmez.

Çünkü API güvenliğinde sadece "kim neye erişebilir?" sorusu yoktur.

Bir kullanıcı bu işlemi ne kadar yapabilir?

İşte burada karşımıza Unrestricted Resource Consumption çıkar.

Unrestricted Resource Consumption Nedir?

Unrestricted Resource Consumption, bir API'nin kullanıcıların tüketebileceği kaynakları yeterince sınırlamamasıdır.

Bu kaynaklar farklı şeyler olabilir:

İstek sayısı
CPU kullanımı
Bellek kullanımı
Dosya yükleme boyutu
SMS veya e-posta gönderimi
Veritabanı sorgu maliyeti
Rapor oluşturma işlemleri
Üçüncü parti servis çağrıları

Eğer API bu kaynakları kontrol etmiyorsa saldırgan sistemi yorabilir, maliyet oluşturabilir veya iş süreçlerini manipüle edebilir.

Basit bir örnek düşünelim:

POST /api/v1/products/purchase

POST /api/v1/products/purchase

Bu endpoint ürün satın alma işlemini gerçekleştiriyor olsun.

Eğer kullanıcı kısa sürede sınırsız sayıda satın alma isteği gönderebiliyorsa, stoklar tüketilebilir, sistem yavaşlatılabilir veya indirim dönemleri kötüye kullanılabilir.

Rate Limit Neden Önemli?

Rate limit, belirli bir kullanıcının veya IP adresinin belirli süre içinde kaç istek yapabileceğini sınırlar.

Örneğin:

Bir kullanıcı dakikada en fazla 10 login denemesi yapabilir.
Bir IP adresi dakikada en fazla 100 API isteği gönderebilir.
Bir kullanıcı günde en fazla 5 rapor oluşturabilir.

Bir kullanıcı dakikada en fazla 10 login denemesi yapabilir.
Bir IP adresi dakikada en fazla 100 API isteği gönderebilir.
Bir kullanıcı günde en fazla 5 rapor oluşturabilir.

Bu sınırlamalar sadece performans için değildir. Aynı zamanda güvenlik kontrolüdür.

Rate limit yoksa saldırgan şu işlemleri deneyebilir:

Parola brute-force saldırısı
Stok tüketme
Toplu veri çekme
Kupon veya indirim kötüye kullanımı
E-posta/SMS gönderim maliyeti oluşturma
Ağır sorgularla sistemi yavaşlatma
Dosya yükleme endpoint'lerini kötüye kullanma

Yani rate limit eksikliği yalnızca teknik bir performans problemi değildir. Doğrudan güvenlik ve iş riski üretir.

Sadece Login Endpoint'i Değil

Rate limit denince çoğu kişinin aklına sadece login endpoint'i gelir.

Evet, login endpoint'lerinde rate limit kritik önemdedir. Çünkü brute-force saldırılarını zorlaştırır.

Ama rate limit sadece login için düşünülmemelidir.

Şu endpoint'ler de kontrol edilmelidir:

Arama endpoint'leri
Rapor oluşturma endpoint'leri
Dosya yükleme endpoint'leri
Satın alma endpoint'leri
Şifre sıfırlama endpoint'leri
E-posta veya SMS gönderen endpoint'ler
Sepet, kupon ve indirim işlemleri
Toplu listeleme veya export endpoint'leri

Çünkü saldırgan her zaman sisteme girmeye çalışmaz. Bazen zaten erişebildiği bir endpoint'i aşırı kullanarak zarar verir.

İş Mantığı Suistimali

Unrestricted Resource Consumption çoğu zaman iş mantığı problemleriyle birleşir.

Örneğin bir API ürün indirim bilgilerini döndürüyor olsun:

GET /api/v1/products/discounts

GET /api/v1/products/discounts

Bu endpoint herkese açık veya yanlış yetkilendirilmişse kullanıcılar gelecekte hangi ürünlerin ne zaman indirime gireceğini öğrenebilir.

Bu tek başına veri sızıntısı gibi görünebilir.

Ama iş etkisi daha büyüktür.

Bir saldırgan indirim başlayacağı anda otomasyonla çok sayıda satın alma isteği gönderebilir. Eğer satın alma endpoint'inde rate limit, stok kontrolü veya iş kuralı koruması yoksa ürünleri tüketip daha sonra daha yüksek fiyata satabilir.

Burada teknik açık doğrudan ticari zarara dönüşür.

Bu yüzden API güvenliğinde iş mantığı mutlaka hesaba katılmalıdır.

Broken Function Level Authorization

Bu noktada başka bir önemli risk daha devreye girer:

Broken Function Level Authorization, kısaca BFLA.

BFLA, kullanıcının erişmemesi gereken bir fonksiyona veya endpoint'e erişebilmesidir.

BOLA'da kullanıcı yanlış nesneye erişiyordu. BFLA'da ise kullanıcı yanlış fonksiyonu çalıştırabiliyor.

Örneğin normal bir kullanıcının şu endpoint'e erişememesi gerekir:

GET /api/v1/products/discounts

GET /api/v1/products/discounts

Eğer bu endpoint sadece belirli role sahip kullanıcılar için tasarlandıysa ama backend tarafında rol kontrolü uygulanmadıysa BFLA oluşur.

Frontend'de butonun görünmemesi yeterli değildir. Saldırgan endpoint'i doğrudan çağırabilir.

BOLA ile BFLA Arasındaki Fark

Bu ayrımı netleştirmek önemli.

BOLA: Kullanıcı erişmemesi gereken bir kaynağa erişir. Örneğin başka bir kullanıcının siparişini görür.

BFLA: Kullanıcı erişmemesi gereken bir işlemi çalıştırır. Örneğin admin veya özel rol gerektiren bir endpoint'i çağırır.

İkisi de authorization problemidir ama farklı seviyelerde ortaya çıkar.

BOLA nesne seviyesindedir. BFLA fonksiyon seviyesindedir.

Güvenli bir API'de ikisi de kontrol edilmelidir.

Nasıl Önlenir?

Bu riskleri azaltmak için API tasarımında birkaç temel prensip uygulanmalıdır.

Her endpoint için rol ve yetki kontrolü backend tarafında yapılmalıdır. Endpoint'in frontend'de gizlenmesi güvenlik sağlamaz.

Rate limit sadece IP bazlı değil, kullanıcı, endpoint ve işlem türüne göre de tasarlanmalıdır.

Ağır işlemler için kota uygulanmalıdır. Örneğin rapor oluşturma, export alma veya dosya yükleme gibi işlemler sınırsız bırakılmamalıdır.

Satın alma, indirim, kupon ve stok gibi iş süreçlerinde sadece teknik kontrol değil, iş kuralı kontrolü de yapılmalıdır.

Örneğin:

Kullanıcı başına satın alma limiti
Dakika başına işlem limiti
Stok doğrulaması
Kupon kullanım sınırı
Şüpheli işlem izleme
Kritik endpoint'lerde rol kontrolü
Başarısız denemelerde gecikme veya bloklama

API güvenliğinde önemli olan sadece isteği almak değil, isteğin etkisini de kontrol etmektir.

Kapanış

Unrestricted Resource Consumption bize şunu gösterir:

Bir API endpoint'inin çalışması yeterli değildir. O endpoint'in ne kadar, kim tarafından ve hangi koşullarda kullanılabileceği de kontrol edilmelidir.

BFLA ise bize başka bir kritik noktayı hatırlatır:

Frontend'de görünmeyen bir buton, backend'de korunmayan bir endpoint'i güvenli yapmaz.

API güvenliği backend'de uygulanır. Her endpoint kendi yetki kontrolüne, kaynak sınırına ve iş mantığı korumasına sahip olmalıdır.

Serinin bir sonraki yazısında daha teknik ve etkisi yüksek bir saldırı tipine geçeceğiz:

SSRF, yani API'nin sunucu tarafında istenmeyen kaynaklara istek göndermeye zorlanması.