Müşterilere bir API sunmak gelirinizi artırır ancak aynı zamanda saldırı yüzeyinizi de genişletir. İşletmeler, geliştirmeyi kolaylaştırmak için üçüncü taraf uygulamalara yerleştirilebilecek bir API sunabilir. Örneğin, sosyal medyayı bir uygulamaya dahil etmek, geliştirme ekibinize büyük bir yük getirmeden müşterilerin bir ürünü tartışmasına olanak tanır. Sosyal medya şirketi trafik ve görünürlük kazanır, müşteri ise uygulamasına özellikler eklerken geliştirme kolaylığı kazanır.
API, pazarlama ve gelir açısından iyi olsa da API'ler ve uç noktalar eklemek, saldırı yüzeyinizi genişletir. Bir API'ye sahip olmak, yönetilebilecek ek bir risktir ancak tüm uç noktaların sıkı bir şekilde izlenmesi ve güvenliğinin sağlanması gerekir. Çoğu yönetici, API'lerin izlenmesi gerektiği konusunda hemfikirdir ancak çok sayıda güncelleme ve dağıtımla hızlı tempolu bir iş ortamı, kendisini API'lerin izini kaybederken ve bilmeden "zombi API'leri" adı verilen bir siber güvenlik riski eklerken bulabilir.
Zombi API (temel anlamda) kullanıma hazır olan, unutulmuş ve gözden kaçırılan bir altyapıdır, ancak kuruluşlar bunun varlığından habersizdir. Zombi API'leri küçük veya büyük ortamlarda oluşturulabilir, ancak genellikle BT kaynaklarının katı provizyon ve belgeleme prosedürleri uygulanmadan oluşturulduğu ortamlarda oluşturulurlar. Değişiklik kontrolü, zombi API durumlarının önlenmesine yardımcı olur, ancak belirli bir kritik hatayı düzeltmek için gerçekleştirilen acil durum dağıtımları veya yapılandırmaları da gerçekleşebilir.
Otomatikleştirilmiş bir ortamda bulut kaynakları genellikle uygulama koduyla birlikte dağıtılır. Bunun avantajı, geliştiricilerin ve operasyon personelinin artık donanımı dağıtmayı ve manuel olarak yapılandırmayı hatırlamalarına gerek kalmamasıdır. Yazılım dağıtımındaki otomasyon, yanlış yapılandırmalardan kaynaklanan olayları azaltır veya geliştiricilerin, uygulamalarını desteklemek için kaynak sağlama isteklerini eklemeyi unuttukları sorunları önler.
Bazı ortamlarda geliştiricilere kendi test sunucularına erişim izni verilir. Bu sunuculara, geliştiricilerin yeni kodu test edebilmesi için halka açık internet üzerinden erişilebilir olabilir. Bir API test sunucusu genel internet erişimine açık olabilir ve geliştiriciler bunun yayınlanmadan tespit edilmeyeceğini düşünebilir.
Zombi API'leri, en katı değişiklik kontrol prosedürleriyle bile, kendi uç durumlarıyla çeşitli şekillerde oluşturulabilir. İster hatalardan ister yanlış yönlendirmeden kaynaklansın, zombi API'leri bir tür
Duruma göre bir zombi API'si oluşturmanın sayısız yolu gibi, aynı şey bir zombi API'si bulmak için de söylenebilir. Bilgisayar korsanları kodu tersine mühendislik yaparak, açık kaynak depolarını inceleyerek veya "fuzzing" adı verilen bir kavram aracılığıyla bir uç nokta bulabilirler. Fuzzing, ortak API uç noktası adlarına karşı istekte bulunmak için komut dosyalarının yazıldığı bir keşif türüdür. Örneğin, kimlik doğrulama için kullanılan bir API uç noktasının "/login" veya "/authenticate" veya benzeri bir adla adlandırılan bir uç noktaya sahip olması yaygındır. Uç noktaların keşfedilmesi için altyapınıza karşı farklı ortak uç nokta adlarına istekte bulunulur.
Açık kaynak depolarından keşif yaygındır. Açık kaynak depoları aynı zamanda sırların ifşa edilmesine karşı da savunmasızdır; bu da geliştiricilerin özel anahtarlara, kimlik doğrulama bilgilerine ve diğer özel verilere yapılan referansları kaldırmayı unutabileceği anlamına gelir. API uç noktalarına yapılan referanslar da keşfedilmeye hazırdır ve herhangi bir güvenlik açığı olup olmadığı araştırılacaktır. Kuruluşunuz kodda başvurulan uç noktaların farkında değilse, bu durumda herhangi bir azaltma veya oran sınırlaması olmaksızın incelenebilir.
Bir zombi API'si her zaman hata istismarlarına karşı savunmasız değildir. Örneğin, SQL enjeksiyon güvenlik açıklarından yararlanmak, hassas bilgilerin verilerin ifşa edilmesine neden olabilir, ancak bazı uç noktalar, tehditlere karşı dayanıklılıkla uygun şekilde kodlanmıştır. Zombi API durumunda, API normal şekilde çalışabilir ancak herhangi bir sınırlama olmaksızın veri toplamak için kullanılabilir. Uç noktanın istismar edilebilecek bir iş mantığı hatasına sahip olması mümkündür, ancak izleme yapılmazsa herhangi bir şüpheli etkinlik tespit edilemeyebilir.
Normal şekilde çalışan ancak verileri sessizce numaralandırmak için kullanılan bir API'ye iyi bir örnek,
Bir güvenlik araştırmacısının zombi API'sini tespit etmesinden sonra JustDial, olayı düzelttiğini iddia etti ancak aynı sorun 2020'de tekrar tespit edildi. Güvenlik araştırmacısı dışında herhangi bir üçüncü tarafın olup olmadığı belli değil, ancak uç nokta ortak internete açık olduğu için herhangi bir izleme mevcut olmadığından JustDial, veri sızıntısının boyutunu değerlendiremez.
Başka bir örnek, piyasadaki en iyi geliştiricilerden bazılarıyla tanınan büyük San Francisco teknoloji şirketlerinden biri olan Facebook'tur. Facebook'ta birkaç zombi API örneği vardı. 2016 yılında geliştiriciler, şifre sıfırlama işlevlerini test etmek için bir alt alan adı (mbasic.beta.facebook.com) dağıttı. API'nin üretim sürümünde hız sınırlamaları vardı, bu nedenle saldırganlar, şifrelerini sıfırlamak için kullanıcılara gönderilen altı haneli şifreyi kaba kuvvetle kullanamadı. Beta sürümünde bu sınırlama yoktu; dolayısıyla altı basamaklı bir parola, yalnızca internet bağlantısı, bant genişliği ve API uç noktalarının arka uç işlem hızıyla sınırlı olarak saniyeler içinde kaba kuvvetle zorlanabilirdi.
2018'de Facebook başka bir sorunla karşılaştı
2022'de Travis CI'nın uç noktasıyla daha küçük ancak zombi API'sinden önemli miktarda veri ihlali meydana gelen bir şirket. Travis CI, altyapı ve kodu dağıtmak için kullanılan bir otomasyon sağlayıcısıdır. Travis CI'nın API uç noktalarından biri kimlik doğrulama gerektirmedi ve müşteri günlüğü olaylarını alma isteklerine izin verdi. Daha da kötüsü, günlükler düz metin olarak saklanıyordu, böylece erişim anahtarları da dahil olmak üzere kullanıcı günlük verileri herhangi bir sınırlama olmaksızın alınabiliyordu. Sorun bildirildiğinde Travis CI, erişim belirteçleri, anahtarlar ve bulut kimlik bilgileri de dahil olmak üzere 770 milyon kullanıcı günlüğü kaydının çalındığını tahmin ediyordu.
İdeal olarak, yazılım geliştiricileri altyapıdaki değişiklikleri belgeleyerek değişiklik kontrolünün yeni API uç noktalarını içermesini sağlar. Operasyon personeli daha sonra izleme aracılarına uç noktalar ekleyebilir ve bu aracılar, siber güvenlik ve analiz monitörlerinin şüpheli etkinlik tespit edildiğinde yöneticilere bilgi verebilmesi için veri toplar. Uç noktalar belgelenmediğinde zombi API oluşur, dolayısıyla izleme aracıları uç noktalardan habersizdir. İzleme olmadan, herhangi bir analiz ve yönetici uyarısı olmadan sunuculara herhangi bir istek gönderilebilir.
Potansiyel zombi API'leriyle başa çıkmak için yöneticiler genellikle trafiği tespit etmek üzere ağa aracılar yükler. Aracılar trafik verilerini toplar ve sunucular ve diğer ağ altyapısı üzerindeki açık bağlantıları tespit eder. Bu stratejiyle ilgili sorun, zombi API'lerinin genellikle keşfedilene kadar hiçbir trafik veya istek olmadan hareketsiz kalmasıdır. Geliştiriciler, operasyonlar veya internetteki üçüncü taraflar tarafından keşfedilebilirler. Yalnızca üçüncü taraf uç noktayı bulduktan sonra trafik günlüğe kaydedilir, ancak bu, isteklerin uyarıları tetikleyeceği anlamına gelmez. Bir zombi API, herhangi bir "hackleme" veya hatalı biçimlendirilmiş sorgu olmadan standart isteklere izin verecektir. Zombi API'lerini veri ifşası açısından bu kadar tehlikeli kılan da budur.
Zombi API'lerini reaktif olarak tespit etmek için aracılara güvenmek yerine, yapay zekayla çalışmak ve kodunuz üzerinde tarama yapmak daha iyi bir çözümdür. Bu stratejinin iki aşaması vardır: dahili API'lere referanslar için depo kodunuzu taramak ve API'nin herhangi bir istek alıp almadığını belirlemek için olay günlüklerini kullanmak.
İlk adım, API'lere yapılan referanslar için kodu taramaktır. Bu API'ler harici veya dahili olabilir ancak bu altyapı kendi verilerinizi etkilediğinden dahili API'lere odaklanmak istersiniz. Referanslar hem aktif hem de kullanımdan kaldırılmış çok sayıda depoda olabilir. Referansların kodunuzda olduğunun farkında bile olmayabilirsiniz, ancak kodu taradığınızda bunları keşfedecek ve böylece yapay zekaya (AI) bir liste gönderilebilecektir.
Sonraki, olay günlüklerini almak ve analiz etmek için kullanılan büyük bir dil modelidir (LLM). Olay günlükleri potansiyel olarak gigabaytlarca veya terabaytlarca satır satır veri olabilir. Olay günlükleri, siber güvenlik ve altyapıdaki kullanımın izlenmesi açısından kritik önem taşıdığından, API'leri barındıran sunucular için ayarlanmalıdır. Kodda bir API uç noktasına başvuruluyorsa ancak çok az trafik olayı varsa veya hiç trafik olayı yoksa, o zaman bir zombi API'niz olabilir. Referanslara ve çok sayıda olay günlüğüne sahip API'ler, zombi API olarak değerlendirilmemeleri için kullanılıyor ve izleniyor.
Her API uç noktası referansında analitiği işlemek için LLM'leri kullanmak zaman alır, ancak sonuçlar, ortamlarındaki aktif API'lerden habersiz yöneticileri şaşırtabilir. Örnek olarak, bir
Cevap Evet!" Zombie API'leri müşteri verilerinizi, dahili verilerinizi veya diğer kritik bilgilerinizi ifşa edilmeye açık bırakabilir. Uyumlu bir ortamda, bu gözetim milyonlarca dolara mal olabilir. Dava, marka hasarı, gelir etkisi ve diğer bazı olumsuz sonuçlar, veri ihlaline yol açan izlenmeyen altyapıyla ilişkilidir.
Bir kuruluşun ortamının daha iyi görülebilmesi, siber güvenlik ve olaylara daha hızlı yanıt verilmesi açısından kritik öneme sahiptir. Daha fazla kuruluş altyapıyı bulutta dağıttıkça, zombi API'leri de dahil olmak üzere yarım kalmış işlerle karşılaşmadığınızdan emin olmak her zamankinden daha önemli hale geldi. Altyapınızı belgelemek harika bir ilk adımdır ancak bazı API'lerin gözden kaçması da mümkündür. Kodunuzu sürekli olarak taramak, zombi API'lerin belirlenmesine yardımcı olur; bunlar daha sonra devre dışı bırakılabilir veya izleme aracılarına eklenebilir. Altyapınızda daha iyi görünürlük, hassas verilerin açığa çıkması riskini azaltır ve saldırı yüzeyinizi azaltır.