Uygulamalarımızın çoğuna erişim sağlayan yapı taşları olan uygulama programlama arabirimlerine (API’ler) yönelik saldırılar söz konusu olduğunda, OWASP API İlk On’u kesin ve haklı olarak görülmektedir. 2019 yılında bir OWASP çalışma grubu tarafından yürütülen bir risk analizinin yanı sıra güvenlik uygulayıcılarının saha içi deneyimlerine dayanarak derlenen liste, hem geliştiriciler hem de güvenlik uzmanları için bir İncil görevi görüyor. Ancak, saldırı türlerinin her birini çok net bir şekilde tanımlar. Bugün gördüğümüz şey, saldırı araçlarının, tekniklerinin ve prosedürlerinin (TTP’ler) artık bu kesin tanımları takip etmemesi. Bunun yerine, birden çok varyantı birleştiriyorlar.
2022’nin ilk yarısında, OWASP listesinden üç TTP kullanan ilk üçlü saldırının ortaya çıktığını gördük. Bunlar, Kırık Kullanıcı Kimlik Doğrulamasını (API2) Aşırı Veri Açığa Çıkarma (API3) ve Uygunsuz Varlık Yönetimi (API9) ile birleştirdi. İzlememiz, bu saldırıların izlenen saldırıların yalnızca küçük bir bölümünü (100 milyon) temsil ettiğini ortaya çıkarsa da, üçlü saldırıların oranı yıl boyunca tutarlıydı ve bu, bir teknik olarak işe yaraması gerektiğini gösteriyor.
Üçlü serseri
Trinity saldırıları güçlüdür çünkü saldırganın saldırıların her birini birlikte kullanmasına izin verir ve bu da tamamlayıcı uzlaşma biçimleri sağlar. Saldırganların, kullanıcı oturumlarını elde etmek için kimlik doğrulama mekanizmalarını hedef aldığı bir kimlik bilgisi doldurma, genellikle Bozuk Kullanıcı Kimlik Doğrulaması (API2) ile ilişkilendirilirken, Aşırı Veri Açığa Çıkarma (API3) genellikle API’lerin çok fazla kişisel veri açığa çıkardığını görür. Tipik olarak, başarılı bir kimlik bilgisi doldurma saldırısı, oturum açtıktan hemen sonra çalınabilen hassas müşteri verileri için kullanıcı bilgileri API’lerini kontrol etmek üzere bir denetleyici işlevi kullanır ve bu denetleyici API’si gereğinden fazla veri döndürürse, saldırgan büyük ikramiyeyi etkili bir şekilde vurur.
Uygun Olmayan Varlık Yönetimi (API9) söz konusu olduğunda, buna iyi bir örnek, Gölge API’dir – bir API’dir. . Bu tür API’ler, güvenlik ekibinin radarında olmadıkları için genellikle savunmasızdır. Saldırgan, bir kimlik bilgisi doldurma saldırısı başlatmadan veya API’nin aşırı miktarda veri sızdırmasına neden olmadan önce bunları bilinen API modellerini kullanarak kolayca keşfedebilir.
Üçlü saldırıları tespit etmek birçok işletme için sorunludur çünkü API’lerini envanterleyemedikleri ve bunu güncel tutamadıkları için saldırı yüzeyini göremezler. Ayrıca meşru talepler yapıyormuş gibi görünen ancak büyük hacimlerde olan saldırıları izlemezler. API aracılığıyla yapılan istek geçerli görünüyorsa, API güvenlik sistemleri genellikle davranış tabanlı analiz kullanarak izleme yapmadığından bir uyarı tetiklemez.
İş için doğru çözüm?
Birçok kuruluş, API altyapılarının zaman içinde organik olarak büyüdüğünü gördü ve bu nedenle web uygulaması güvenlik duvarları (WAF’ler) gibi web uygulamalarını izlemek ve tespit etmek için tasarlanmış güvenlik çözümleriyle yola çıktılar ve bu çözümlere güvenmeye devam ediyorlar. Bu çözümler, imza tabanlı bir uyarı mekanizması kullanır ve bu nedenle bırakın üçlü saldırılara karşı savunmayı tespit edip engelleyemezler. Diğerleri bot araçlarına güvenebilir, ancak bunlar bir saldırıyı belirlemek ve engellemek için JavaScript kullanır. RESTful API’ler, JavaScript değil, JSON veya XML kullanır; bu, bot yazılımı tarafından izlenemeyecekleri anlamına gelir.
Daha önce de değindiğimiz gibi, üçlü saldırılarda genellikle bir bot unsuru bulunur. Altyapı genelinde hızlı bir şekilde numaralandırılırlar, bu nedenle genellikle botlar tarafından otomatikleştirilirler. Ancak, WAF’lerin API’den meşru isteklerde bulunan yüksek hacimli saldırılara karşı kör olduğu ve bot çözümlerinin API yüklerini okuyamadığı göz önüne alındığında, bu saldırılar onları hem tespit edilmeden hem de karşı çıkılmadan atlar. Bot güvenliği ve API güvenliği arasındaki ilişkinin bu şekilde anlaşılmaması, güvenlik satıcıları tarafından genellikle ayrı sorunlar olarak ele alınan iki sorunla birlikte devam ediyor.
Bu, doğrudan saldırganların işine gelen yapay bir ayrımdır; bu nedenle, API korumasına bot tespiti ve azaltmanın yanı sıra keşif, tespit ve savunma yoluyla API güvenliğinin yönetimini gerektiren bir sorun olarak bakmak daha mantıklıdır. Peki iş nereden başlamalı?
Birleşik bir API koruma stratejisi
Başlangıçta, kaç tane API’ye sahip olduğunuzu ve bunların ne işe yaradığını belirleyerek API’lerinizin üstesinden gelmeniz ve bir çalışma zamanı envanteri kullanarak değişiklikleri sürekli olarak belgeleyebilmek için hazırlıklar yapmanız zorunludur. Şaşırtıcı bir şekilde, API ekosistemlerinden sorumlu olanlar genellikle kaç taneye sahip olduklarını nadiren bilirler ve rutin olarak sayıları hafife alırlar, bunun sonucunda bu keşif gerçekleştirildiğinde bunalmak kolay olabilir. Ancak, API’lerin ortaya koyduğu riskler farklı olacağından, bunlara öncelik vermek görece daha kolaydır.
Bazı API’ler tamamen bilgilendirme amaçlı olurken, diğerleri kişisel olarak tanımlanabilir bilgiler veya kredi kartı verileri gibi hassas verileri açığa çıkarabilir. Bazıları düzgün bir şekilde doğrulanamayabilirken, diğerleri hesap devralma veya kazıma gibi iş mantığı saldırılarına eğilimli olabilir.
Bu nedenle, API’leri değerlendiren risk, işletmenin envantere öncelik vermesine izin verir, ancak bir API’nin oluşturduğu riskin zaman içinde değişebileceğini unutmayın. Saldırganlar, API’lerde zayıflık olup olmadığını araştırabilir ve araştırmaya devam edecektir ve yapılandırmayla ilgili bir sorun veya daha az güvenli bir sisteme bağlantı, yeni güvenlik açıklarına neden olabilir.
Envanter hazır olduğunda, hangi çalışma zamanı korumasının devreye alınacağını düşünebilirsiniz. Bu, OWASP İlk On tarafından kapsanan iş mantığı suistimallerini, veri sızıntılarını ve diğer yaygın saldırı türlerini taramalıdır, ancak aynı zamanda tehdit tabanlı ve davranışsal saldırılar gerçekleştirmek için makine öğrenimi teknolojisinden yararlanarak saldırı ortamındaki değişikliklerle başa çıkabilmelidir. analiz. Bu, işlemlerin amacını (botlar veya bireyler tarafından gerçekleştirilen) belirleyebilir ve tespit edilmekten kaçınmak için yeniden düzenlenirken karmaşık API saldırılarını sürekli olarak izleyebilir. Ardından, saldırıyı engellemek veya saptırmak için temel blok ve hız sınırlamasından HTTP başlığı ekleme ve aldatmaya kadar eylem gerçekleştirilebilir.
Ezber bozan
İşletme, yalnızca API yaşam döngüsünün tamamına bakarak API’lerini hem mevcut hem de gelişmekte olan saldırı türlerinden korumayı umabilir. Geliştirme aşamasındaki güvenlik testinden, bir çalışma zamanı envanteri kullanılarak izlenen ve yönetilen bir ekosistemin parçası olarak API’nin yönetilmesine ve saldırı kalıplarını arayan aktif savunmaya kadar, beşikten mezara bir yaklaşım olması gerekir.
Üçlü saldırı, saldırganların her bir API’nin nasıl çalıştığını, diğerleriyle nasıl etkileşime girdiğini analiz etmede ve belirli bir işlemin sonucunu tahmin etmede çok daha ustalaştığını gösterir. Bu, API güvenlik risklerinde önemli bir artış ve şu anda, bu saldırıların çoğu tespit edilmiyor ve karşı çıkılmıyor çünkü kuruluşlar bunların çok geç olana kadar olduğunu bilmiyorlar. Bu nedenle, gelişen saldırılara ayak uydurmak istiyorsak, API güvenliğini nasıl gerçekleştirdiğimiz değişmelidir.