Modern dijital hizmetleri ve uygulamaları destekleyen uygulama programlama arayüzlerindeki (API’ler) güvenlik açıkları, kurumsal sistemler ve veriler için büyük bir tehdit olarak ortaya çıktı.
A Wallarm’ın son raporu bu yılın ikinci ve üçüncü çeyreği arasında API ile ilgili kusurlarda %21’lik bir artış olduğunu gösteriyor. Neredeyse üçte biri (%32) bulut altyapısı ve bulutta yerel uygulamalar ve hizmetlerle ilişkilendirildi. Artan hacmin yanı sıra, Wallarm’ın incelediği güvenlik açıklarının büyük bir kısmının ciddiyet puanı 7,5 veya daha yüksekti; bu da kuruluşlar için API kullanımından kaynaklanan riskin arttığını gösteriyor.
Wallarm’ın kurucusu ve CEO’su Ivan Novikov, “3. çeyrekte kimlik doğrulama ve yetkilendirme sorunları, sızdırılan API verileri ve klasik enjeksiyon saldırılarından kaynaklanan API ihlallerini gördük” diyor.
Novikov, OWASP’nin En İyi 10 API güvenlik açığı listesindeki güvenlik açıklarının çoğunun sunucu odaklı olmasına rağmen, Wallarm’ın verilerinin, OAuth yanlış yapılandırması ve siteler arası sorunlar gibi istemci tarafı kusurlarında bir artış gösterdiğini söylüyor.
“Bu endişe verici çünkü savunmacıların kaynakları kısıtlı ve en önemli saldırı türlerine odaklanmaları gerekiyor” diyor.
Kurumsal olarak güvenlikten ziyade API entegrasyonu ve işlevselliğine verilen önem, sorunu daha da kötüleştiriyor. tarafından yapılan bir araştırmaya göre, kuruluşların yalnızca %37’si güvenlik testlerini API yaşam döngüsü yönetimi uygulamalarına resmi olarak dahil etti. Postacı bu yılın başında bulundu.
Raporda, “API’ler artık kötü niyetli aktörler için bir numaralı hedef haline geldi ve güvenlik ve gözlemlenebilirlik kritik hale geldi” ifadesine yer verildi.
API güvenlik risklerine katkıda bulunan başlıca faktörler nelerdir? Peki kuruluşlar bunları azaltmak için ne yapmalı?
Yanlış yapılandırılmış API’ler
Son yıllardaki çoğu API güvenlik sorunu, nispeten kolayca önlenebilir yanlış yapılandırmalardan kaynaklanmıştır. Yaygın örnekler arasında yetersiz kimlik doğrulama ve yetkilendirme, giriş doğrulama eksikliği, uygunsuz hız sınırlaması, yetersiz günlük kaydı ve izleme ve hata mesajları yoluyla hassas verilerin açığa çıkması yer alır. Bu tür yanlış yapılandırmaların ciddi sonuçları olabilir.
Postman’ın kurucu ortağı ve CTO’su Ankit Sobti, örneğin, bir API’nin kaynaklara kullanıcı erişimini doğru şekilde doğrulamaması durumunda Bozuk Nesne Düzeyinde Yetkilendirmenin, saldırganların yetkisiz verilere erişmek için nesne kimliklerini değiştirmesine izin verebileceğini söylüyor. Benzer şekilde, bir API’nin uygun kimlik doğrulamayı zorunlu kılmada başarısız olduğu Bozuk Kullanıcı Kimlik Doğrulaması güvenlik açıkları genellikle saldırganların kimlik doğrulama kontrollerini atlamasına ve uç noktalara yetkisiz erişim elde etmesine olanak tanır.
Kuruluşlar, katı yetkilendirme kontrolleri, rol tabanlı erişim kontrolü, çok faktörlü kimlik doğrulama, sunucu tarafı veri filtreleme ve gereksiz veriler için API yanıtlarını gözden geçirme gibi en iyi güvenlik uygulamalarını uygulayarak bu sorunları azaltabilir.
Sobti, “Uygun hız sınırlaması olmadığında, API’ler kaba kuvvet saldırıları veya hizmet reddi saldırıları gibi teknikler aracılığıyla kötüye kullanıma karşı savunmasız hale gelir ve bu da hizmeti olumsuz etkileyebilir,” diye vurguluyor Sobti.
Salt Security’nin saha CTO’su Nick Rago, son birkaç yıldaki API ile ilgili ihlallerin büyük çoğunluğunun zayıf duruş yönetiminden kaynaklandığını söylüyor. Çoğu durumda, “ihlalin önündeki engel oldukça düşüktü ve saldırganın, yanlış yapılandırılmış bir API’den yararlanmak için herhangi bir devasa çabaya ihtiyacı yoktu.”
Rago, sorunu API geliştirme ve yönetimi konusunda uygun gözetim eksikliğine bağlıyor.
Kendisi, kurumsal duruş standardının oluşturulması etrafında bir yönetişim çerçevesi oluşturmanın önemli bir ilk adım olduğunu söylüyor. Rago, riskleri azaltmak için kuruluşların API varlıklarını keşfetmeye, güvenlik durumlarını değerlendirmeye ve uyumsuzlukları gerektiği gibi gidermeye yönelik yetenekleri uygulaması gerektiğini ekliyor.
Kötü Tasarlanmış API’ler
Kötü tasarlanmış API’ler, API güvenlik olaylarının bir başka önemli nedenidir; Rago, bu API’lerin, düşmanın yararlanabileceği bir yöntem dışında yapmaları gereken her şeyi yaptığını söylüyor.
“Bir uygulamanın ihtiyaç duyduğundan daha fazla bilgi döndüren API’leri veya zaman içinde bilgi için alıntılanabilecek API’leri düşünün” diye açıklıyor.
Diğer örnekler arasında doğrulanmamış SQL girişleri kullanan, uygulama ayrıntılarını açığa çıkaran, çok karmaşık ve şişirilmiş, hataları güvenli olmayan bir şekilde işleyen veya tutarsız adlandırma ve yapıya sahip API’ler yer alır.
Ayrıca Rago, kötü tasarlanmış bir API’nin bazen iş mantığı tutarsızlıklarını göz ardı edebileceğini söylüyor. Örnekler arasında, kullanıcıların fiyatları değiştirmesine veya hesaplara ve işlemlere aşırı izin veren erişime olanak tanıyan değişiklikler yapmasına olanak tanıyan e-ticaret API’leri yer alır. Imperva’nın “API Güvenliğinin Durumu 2024” raporu, iş mantığının kötüye kullanımını geçen yılın API’lere yönelik en büyük saldırı olarak tanımladı. Bu saldırılar, 2023’te API ile ilgili tüm saldırıların %27’sini oluşturdu; bu da önceki yıla göre yaklaşık %10’luk bir artış anlamına geliyor.
Rago, “Kötü tasarlanmış API’lerin kötüye kullanılması ya da iş mantığındaki bir güvenlik açığına karşı kullanılan saldırılar, yalnızca anormal kullanımı deşifre etmekle kalmayıp aynı zamanda bir API tüketicisinin ardındaki kötü niyetli niyeti de tespit edebilen özel davranışsal tehdit korumasından yararlanılarak ele alınabilir,” diye belirtiyor Rago.
Imperva’nın API güvenliğinden sorumlu başkan yardımcısı olarak Lebin Cheng bir köşe yazısında yazdı Bu yılın başlarında, yetersiz şekilde alınan API tasarımı kararları, kuruluşlar ve müşterileri üzerinde kalıcı bir etkiye sahip olabilir. Örneğin API’ler, geliştiricilerin bunları tasarlarken ölçeklenebilirlik gereksinimlerini dikkate almaması durumunda ciddi performans darboğazlarına neden olabilir. Cheng, benzer şekilde geliştiricilerin çoğunlukla iş ihtiyaçlarına odaklanarak tasarım süresi boyunca arabellek taşması hataları gibi yaygın güvenlik sorunlarını sıklıkla gözden kaçırabileceğini yazdı.
“Kötü API tasarımı sorunu, API’lerin nasıl tasarlanması gerektiğine dair katı standartların bulunmaması gerçeğiyle daha da karmaşıklaşıyor” dedi. “Bu, API’leri uygulamanın ve geliştirmenin en iyi yolunu belirleme işini bireysel geliştiricilere bırakıyor; bu da kötü tasarım kararlarının kolaylıkla gözden kaçabileceği anlamına geliyor.”
Görünürlük Eksikliği
API’ler şu şekilde ortaya çıktı: üst saldırı vektörü neredeyse her yerde kullanımları nedeniyle tehdit aktörleri için. Imperva’nın araştırması, kuruluşların hesap başına ortalama 613 API uç noktasına sahip olduğunu gösterdi. Güvenlik sağlayıcısı, API trafiğinin 2023 yılında tüm Web trafiğinin %71’ini oluşturduğunu ve ortalama bir işletmenin yılda 1,5 milyar API çağrısı yaptığını tespit etti.
Rağmen yaygınlaşan kullanım ve ilgili risklere maruz kalma nedeniyle birçok kuruluş, API’leri üzerinde yeterli görünürlüğe sahip değildir.
Black Duck çözüm yöneticisi Kimm Yeo, “API’leri keşfetmek ve test etmek için yeni yöntemler gerekiyor” diyor.
Yeo, kuruluşların API güvenliği hakkında daha proaktif bir şekilde düşünmeye başlaması gerektiğini savunuyor. Bunun, API’leri yazılım geliştirme yaşam döngüsünün başlarında keşfetmeye ve incelemeye yönelik yetenekleri uygulamaya koymak anlamına geldiğini söylüyor. Amaç, API’lerin ve uygulamaların üretime geçmeden önce sürekli olarak test edilmesini sağlamak olmalıdır.
“Günümüzün API güvenlik çözümleri büyük ölçüde üretim sırasında API keşfini uygulamaya odaklanıyor, [where] Üretilen herhangi bir kritik uyarının koda kadar takip edilmesi zordur” diyor. Yeo, bunun geliştiricilerin belirlenen sorunları düzeltmesini imkansız hale getirebileceğini ekliyor.
Zimperium ürün stratejisinden sorumlu başkan yardımcısı Krishna Vishnubhotla, çoğu kuruluş için acil sorunun, dışarıya yönelik tüm API’lerin envanterinin bulunmaması olduğunu söylüyor.
“Kötü aktörler bu boşluktan yararlanırken hızlı hareket etmek kritik önem taşıyor” diyor. “İlk adım, tüm bu genel API’leri acilen keşfedip envanterini çıkarmak ve ardından bunları güvence altına almak için acil önlemler almaktır.
Yetersiz Güvenlik Testi
Pek çok kuruluş, API güvenliğine yeterince öncelik vermekte başarısız oluyor ve çoğu zaman API’lerin oluşturduğu benzersiz riskleri hafife alıyor. Postman’ın araştırması, kuruluşların yalnızca %37’sinin şu anda geliştirme yaşam döngüsünün başlarında API açıklarını yakalamaya çalışmak için otomatik tarama ve düzenli sızma testleri yaptığını ortaya çıkardı. Nispeten az sayıda şirket, API geliştirme süreçlerinde entegre güvenlik testlerine ve kontrollerine veya merkezi API izleme yeteneklerine sahiptir.
Salt Security’den Rago, API öncelikli stratejileri benimseyen (yazılım planlama, tasarım, mimari ve geliştirme sürecinde API’lerin öncelikli odak noktası olduğu) kuruluşların API güvenliği cephesinde daha iyi başarı elde ettiğini söylüyor.
“Bu kuruluşlar genellikle ‘önce spesifik geliştirmeyi’ zorunlu kılıyor, bu da bir API’nin Swagger veya OAS ile ‘planlanması’ ve bir kod satırı yazılmadan önce onaylanması gerektiği anlamına geliyor” diyor. “Hastaları içeri almadan önce ilk önce hastanenin planını hazırlamanız ve inşaatını plana göre doğrulamanız gerekiyor. Açık görünüyor, ancak çoğu kuruluşta bu hala işleyiş şekli değil.”
Wallarm’dan Novikov, API risklerinin iki büyük kategoriye ayrıldığını söylüyor: erişim ve kullanılabilirlik. Saldırganlar ya erişmemeleri gereken bir şeye erişim kazanırlar ya da bir API’nin kullanılabilirliğini etkileyerek çevrimdışına alabilirler.
Novikov, “Bu hedeflere nasıl ulaşabilecekleri konusunda pek çok teknik ayrıntı var, ancak hepsi bu iki sonuca varıyor” diyor.
Yüksek düzeyde, bu risklere karşı temel korumanın tüm API uç noktalarında güçlü kimlik doğrulama ve yetkilendirme olduğunu söylüyor.
“Bu, kimlik doğrulaması gerektiren sahip olduğunuz tüm API’leri bilmek, sunucu tarafındaki yetkilendirmeyi sıkı bir şekilde kontrol etmek ve saldırganları yavaşlatmak için gelişmiş hız sınırlaması uygulamak anlamına geliyor” diye tavsiyede bulunuyor. “Bu azaltımlar en iyi uygulamalardır ancak bu onların yaygın uygulamalar olduğu anlamına gelmez.”