OWASP Vakfı’nın İlk On listesi, savunucuların çabalarını belirli teknolojilere odaklamalarına yardımcı oldu ve OWASP API (Uygulama Programlama Arayüzü) Güvenliği İlk 10 2023 de bir istisna değildir. İlk olarak beş yıl önce hazırlanan ve bu yıl güncellenen bu belge, saldırı yöntemlerindeki değişiklikleri ele almayı amaçlıyor.
Ancak OWASP API Güvenlik Projesi liderlerinin, tehditleri nasıl gruplandırıp önceliklendireceklerine karar verirken işleri yarım kaldı. Liste, sektör girdilerine dayalı olarak hazırlanmıştır ve uyumlulukla ilgili endişeleri yansıtmalıdır; dolayısıyla tüm insanları hiçbir zaman tam olarak tatmin etmeyecektir. Soru şu: API geliştirme ve savunma söz konusu olduğunda bu işin içinde olanlar için değer yaratacak kadar ileri gidiyor mu?
Neler değişti, neler aynı kaldı?
Eski ve yeni listeyi karşılaştırdığımızda, en önemli iki tehdidin (API1 Bozuk Nesne Düzeyinde Yetkilendirme (BOLA) ve API2 Bozuk Kullanıcı Kimlik Doğrulaması) değişmeden kaldığını görebiliriz. API1, API’ye bir istek dahilinde gönderilen bir nesnenin kimliğinin manipülasyonunu belirtirken API2, unutulan/geri kalan parola işlevleri de dahil olmak üzere kimlik bilgisi doldurma gibi saldırılar yoluyla kimlik doğrulama mekanizmalarının kötüye kullanılmasını işaretler. Saldırganlara en hızlı galibiyeti sağlıyorlar ve bunların neden listenin başında yer aldığını anlamak kolay.
API3, Aşırı Veri Açığının yerini Bozuk Nesne Özelliği Düzeyinde Yetkilendirmeyle değiştirdi. Bu, hassas verilerin açığa çıkması sorununu çözdüğümüz anlamına mı geliyor? Ne yazık ki hayır, büyük bir sorun olmaya devam ediyor. Bu değişiklik, bir saldırganın hassas verileri açığa çıkarırken izleyeceği bir sonraki aşamayı, yani mülk düzeyindeki yetkilendirmeyi aşmayı ifade ediyor. Peki Proje neden değişiklik yapmaya karar verdi? Muhtemelen konuyu açıklığa kavuşturmak adına, çünkü hassas verilerin açığa çıkması listenin geri kalanını kapsayan bir sorundur. Ancak ben de dahil olmak üzere bazıları, bunun konuyu sunmanın doğru yolu olmadığını, çünkü bu çok ciddi bir meselenin gizliliğini bozduğunu savunuyor.
Benzer şekilde API6, 2019’da Toplu Atama idi ve artık Hassas İş Akışlarına Kısıtlamasız Erişimdir. Farklılar mı? Tam olarak değil. Her ikisi de uygulama akışı içinde nesnelerden ve onların özelliklerinden yararlanmaktan bahsediyor; proje sayfasında listelenen örnekler, işlevsellikten arka uçta yararlanılan bir yolculuk paylaşımı uygulamasına atıfta bulunuyor. Bununla birlikte, isimlendirmede 2023 versiyonunun belirsiz ve kafa karıştırıcı olmaktan ziyade düzeltilmesi gereken bir şey gibi görünmesini sağlayan ince bir şey var; bu bakımdan bu bir gelişme.
Botları karışıma dahil edin
API6 aynı zamanda düzgün çalışmayan bir API’nin nasıl hızlı bir şekilde kendisine karşı bot saldırıları şeklinde saldırı otomasyonunun kullanılmasına yol açabileceğini de gösteriyor. Bu önemlidir, çünkü API ve bot saldırıları arasında her zaman yapay bir ayrım yapılmıştır; güvenlik sektörü her biri için farklı çözümler sunarken gerçekte otomatik saldırılar API’lere karşı başlatılabilir ve başlatılabilir. Dolayısıyla API saldırılarını ve bot saldırılarını ayrı ayrı izlemek artık mantıklı değil: bot azaltmanın API güvenliğinin bir parçası olması gerekiyor. Bu durum, 2022’nin son çeyreği boyunca trafik analizinde otomatik saldırıların diğer TTP’leri gölgede bıraktığını ortaya koyan son raporumuzda açıkça görülüyor.
Genel olarak yeni liste, daha kapsayıcı olma amacıyla önceki taktiklerin, tekniklerin ve prosedürlerin (TTP’ler) çoğunu büyük ölçüde yeniden tanımlıyor. Örneğin API4, Kaynak Eksikliği ve Hız Sınırlaması’ndan Sınırsız Kaynak Tüketimi’ne geçti; bu da hız sınırlamasının ağ kapasitesi sorununun ötesine geçtiği gerçeğini yansıtıyor. Sınırlar belirlenmediği takdirde kötüye kullanılabilecek diğer kaynaklar arasında CPU, bellek ve depolama yer alır; ancak daha da önemlisi, hizmet sağlayıcılar API istekleriyle maksimuma çıkarılan hizmet kaynaklarını bulabilirler. E-postalar, mesajlar veya telefon görüşmeleri sağlayabilirler ve tekrarlanan bir API isteği, servis sağlayıcının büyük hizmet maliyetlerine neden olduğunu görebilir.
Ancak sonlara doğru sıralamada bazı değişiklikler ve yeni konseptler var. API7 Güvenlik Yanlış Yapılandırması, bu alanda ilerleme kaydedildiği için yerini API8’e bırakıyor.
API7 artık Sunucu Tarafı İstek Sahteciliği (SSRF) olarak adlandırılıyor. API’ler, bir uygulamadan giden trafiği rutin olarak kanalize ettikleri için SSRF saldırılarının ana hedefidir. Geliştiriciler genellikle web kancaları, URL’lerden dosya getirme veya özel SSO ve URL önizlemeleri (Projede belirtiliyor) gibi harici kaynaklara erişir veya bulut veya konteyner sağlayıcıları, yönetim ve kontrol kanallarını HTTP yoluyla tehlikeye atmaya maruz bırakır. Peki ya eski API8, Enjeksiyon saldırıları? Bu artık ayrı olarak kategorize edilmiş bir tehdit değil çünkü genellikle diğer saldırı türlerinin çoğunda da benimseniyor.
Önemli değişiklikler
API9, ifadelerde başka bir ince ama önemli değişiklik daha görüyor: Uygunsuz Varlık Yönetiminden Uygunsuz Envanter Yönetimine. Bu, bir kez konuşlandırıldıktan sonra artık izlenmeyen ve güvenlik ekibinin radarından etkili bir şekilde düşen gölge API’lerin artan sayısını yansıtıyor. Yönetilmeyen, bilinmeyen ve korumasız olan bu API’ler, artık onları aktif olarak arayan saldırganlar için birer ördek görevi görüyor. Aslında, ilk altı aydaki beş milyara kıyasla, 2022’nin ikinci yarısında gölge API’ler için 45 milyar arama girişiminde bulunulduğunu tespit ettik. Bu nedenle, üretim API’lerini sürekli olarak izleyen bir çalışma zamanı API envanteri, yayına giren tüm API’lerin korunmasını sağlamak için hayati öneme sahiptir, ancak günümüzün organizasyonlarındaki en önemli başarısızlıklardan biridir.
Son olarak API10, artık büyük ölçüde API9 tarafından kapsanan Yetersiz Günlüğe Kaydetme ve İzleme’den API’lerin Güvenli Olmayan Tüketimi’ne dönüştü. Bu, API yazılım zincirinde gördüğümüz uzantıyı yansıtıyor; API’ler artık sıklıkla diğer API’lerle entegre ediliyor. Ortaya çıkan sorun, geliştiricilerin, kusurlu olmalarına ve/veya veri sızdırıyor olmalarına rağmen, özellikle tanınmış şirketlerden gelen bu harici API’lerle olan etkileşimlere doğası gereği güvenme eğiliminde olmalarıdır.
Saldırganların şu anda kullanmakta olduğu TTP’leri daha doğru bir şekilde ele almak için OWASP API Top Ten’in ayarlanması konusunda çok fazla düşünüldüğü açıktır. Sonuç olarak listede hem küçük hem de bazı büyük değişiklikler görülüyor ve bunların hepsi haklı. Aslında sorunlu olan tanımlayıcılar değil listenin kendisidir. Bu, API güvenliğinin profiline dikkat çekmek ve profilini yükseltmek için tasarlanmış keyfi bir kavramdır, ancak bu saldırılara karşı savunma şeklimizi ilerletmek için herhangi bir şey yapar mı?
Bir saldırı senaryosunda nasıl dayanır?
İhlal analizini kullanırsak, konseptin nasıl bir araya geldiğini görmek için tipik bir ihlali listedeki kategorilerle karşılaştırabiliriz. Çoğu ihlal, mağdur kuruluşun sahip olduğunun farkında olmadığı bir API ile başlar (2023 listesindeki API9). Bu API’nin daha sonra saldırgan olmayan bir kullanıcı hakkında bir tür veri döndürdüğü bulunur (API1). Şimdi saldırgan, bundan olabildiğince hızlı ve eksiksiz (API6) yararlanmaya çalışmak için bir bot kullanarak saldırı otomasyonu oluşturacak, saldırı zincirini tamamlayacak ve saldırganın kurban kuruluşun sistemlerinde gizli olan verilere erişmesini sağlayacak.
Böyle bir saldırının saldırı kategorilerinden en az üçünü kapsayacağı açıktır, dolayısıyla bunlara öncelik verilmesi önemsiz hale gelir. Aslında bu tür üçlü saldırılar, 2022’nin ilk yarısında tespit edilen 100 milyon saldırıyla ivme kazanıyor.
Dahası, saldırganların bir saldırı sırasında dönüp bilinen TTP’leri kullandıklarını görmenin yanı sıra, API’yi bozmaya çalışmak için benzersiz TTP’ler bulduklarını da görüyoruz. Bunlar Haziran ve Kasım ayları arasında beş kattan fazla arttı (2.000’den 11.000’e). Bu saldırıların çoğu, hesap ele geçirmeyi (ATO), keşif yapmak veya veri sızdırmak için kazıma yapmayı ve dolandırıcılık yapmak için API içindeki iş mantığı kusurlarını avlamayı amaçlıyordu.
Bu kadar çeşitli saldırılara ayak uydurabilmek, güvenlik ekibinin yalnızca savunmaya değil, tespit ve hafifletme yöntemlerine de odaklanmasını gerektiriyor. API’lerin nerede olduğunu bilmek, bunları kusurlara karşı test etmek veya bilinmeyen akışlara saldıran botları durdurmak olsun, API güvenliğinin daha kapsamlı hale gelmesi, API’yi tüm yaşam döngüsü boyunca izlemesi ve koruması gerekiyor.
TTP’lerin sağlam bir özeti
Yeni OWASP API Top 10 mükemmel olmayabilir ancak temelleri kapsıyor ve konuyu ele almak için harika bir başlangıç noktası sağlıyor. Artık hassas veriler ve açığa çıkarma ve enjeksiyon saldırıları gibi bazı saldırı yöntemlerinin birden fazla TTP’ye yayıldığını ve bu nedenle ayrı bir kategori gerektirmediğini kabul ediyor. Ayrıca, API güvenliğinin bir parçası olarak botların azaltılması ihtiyacını ve bunların birbirleriyle entegre olduğunu gören API ekosistemlerinin karmaşık yapısını da güçlendiriyor.
Ancak yapısı, bu saldırıların doğada nasıl kullanıldığını göstermeye elverişli değil. Tehdit aktörleri çok daha çok yönlü hale gelip bunları birleştirirken, hâlâ bu saldırıları bölümlere ayırıyor.
Gerçekçi olmak gerekirse, hızla gelişen bu tehdit ortamına ayak uydurmanın tek yolu bu API’leri izlemek ve yönetmektir. Çalışma zamanı envanteri oluşturmak, API tehdit yüzey değerlendirmeleri yürütmek, spesifikasyon anormallik tespitini gerçekleştirmek ve gerçek zamanlı otomatik bot tespiti ve hafifletme işlemlerini uygulamaya koymak artık işletmenin API ayak izini korumak için hayati önem taşıyor.