Bu 3 API Güvenlik İhlalinden Ne Öğrendik?


“Tecrübe en iyi öğretmendir” derler. Öyle olması gerektiğini hiç söylemediler senin deneyim. Yakından bakarsak, herhangi bir kuruluşun API'lerini daha iyi güvence altına almasına yardımcı olabilecek bu beş ölümcül API saldırısından öğrenilecek dersler var.

İşte buradalar.

  1. Zendesk 2017

Senaryo: Yardım masası biletleme platformu Zendesk, GraphQL uç noktasındaki SQL enjeksiyon güvenlik açığı nedeniyle saldırganlara maruz kaldı. İkinci bir kusur, saldırganların “SQLi gerektirmeden hedef Zendesk hesabının RDS'sindeki herhangi bir tablodan veri çalmasına” olanak tanıyor. Güvenlik platformu Varonis, hataları Zendesk'e bildirdi ve şirket, hasarı bir hafta içinde onarabildi. Hiçbir hassas veri ifşa edilmedi ancak güvenlik açığı kötü niyetli aktörler tarafından keşfedilip istismar edilmiş olsaydı, müşteri yorumları, konuşmalar, e-posta adresleri ve destek biletleri ele geçirilebilirdi.

Çözüm: GraphQL çeşitli nedenlerden dolayı enjeksiyon saldırılarına karşı hassastır. Her biri bir saldırı vektörü olarak kullanılabilecek yeni işleme adımlarını (ayrıştırıcı, ağ geçidi ve alt grafik çözümleyicileri) sunar. Ayrıca birden fazla API çağrısını tek bir çağrıya dönüştürür, böylece tek bir vuruşla daha fazla SQL enjeksiyon hasarı yapılabilir. Buna karşı korumalar temeldir; Veritabanı girişlerinizi sterilize edin, kod olarak yorumlanamayan depolanmış argümanları veya hazırlanmış ifadeleri kullanın ve tüm veritabanı istemcilerine en az ayrıcalık ilkesini uygulayın.

  1. DropBox 2022

Senaryo: Bu dikkate değer API saldırısı, bir kimlik avı dolandırıcılığı olarak başladı. Ekim 2022'de Dropbox, GitHub kaynak kodu depolarına yasadışı bir şekilde erişim sağlayan ve “Dropbox çalışanlarına, mevcut ve geçmiş müşterilere, satış liderlerine ve satıcılara ait birkaç bin isim ve e-posta adresine” erişen kötü niyetli bir aktör tarafından vuruldu. Bu makalede dikkat edilmesi gereken nokta, ganimetin ayrıca Dropbox geliştiricileri tarafından kullanılan ve içinde saklanan çeşitli API anahtarlarını da içermesidir.

Çözüm: Temel MFA önlemlerinden başlayarak birkaç şey bunu önleyebilirdi. İkinci olarak, korsan, geliştiricinin sahte bir “CircleCI” e-postasındaki kötü amaçlı bir bağlantıya tıklamasını ve ardından sahte bir CircleCI sitesinde kimlik doğrulamasını sağlayarak erişim sağladığından, kimlik avına karşı farkındalık eğitimi iyi durumda olurdu. Ancak hepsinden önemlisi API anahtarlarının nihai olarak depolanma şekliydi. Tam da bu nedenle, API anahtarlarını ve diğer kimlik bilgilerini doğrudan kaynak koduna kodlamamak en iyi uygulamadır. Kaynak kodunuzda bunun örneklerini tespit etmek için kod analiz araçlarını kullanarak bunları ortaya çıkarın.

  1. Twitter 2022

Senaryo: Bu API saldırısı, milyonlarca Twitter kullanıcısının kişisel bilgilerinin çevrimiçi olarak ihlal edilmesine ve satılmasına yol açtı. Geçtiğimiz birkaç yılın en büyük API soygunlarından birinde, tehdit aktörleri Twitter'daki bir API güvenlik açığından yararlanarak, yalnızca bir e-posta ve telefon numarasıyla bir kullanıcının Twitter kimliğine erişmek için “keşfedilebilirlik” işlevini değiştirmelerine olanak sağladı. Sonuçta 5,4 milyon kaydın ihlal edilmesiyle sonuçlanan bu sıfır gün saldırısını, bir başkası (aynı güvenlik açığından yararlanarak) takip etti. farklı API), toplam sayıyı yaklaşık 7 milyon kayda getiriyor. Twitter, ilk güvenlik açığını keşfedildikten altı ay sonra yamaladı.

Çözüm: Sistemik API sorunlarını çözmek için sistematik çözümlere ihtiyaç vardır. Kuruluşların, açık kaynaklı ve halka açık olanlar da dahil olmak üzere savunmasız API'leri gerçek zamanlı olarak düzenli olarak tarayan bir API güvenlik programına ihtiyacı vardır. Sadece etraflarına bir güvenlik duvarı inşa etmek yerine, bir sonraki adım bu API'leri çalışma zamanında sürekli olarak test etmek, doğrulamak ve önceliklendirmek olacaktır; böylece şirket, bunların piyasaya sürülmesinin güvenliğinden emin olacaktır.

API Güvenliğinin Geleceği

API'ler büyümeye, gelişmeye ve yayılmaya devam ettikçe API saldırıları da artıyor. 2017 Zendesk SQL saldırısının basit “bir ve bir” yöntemleri, yerini daha uzun vadeli, “düşük ve yavaş” saldırılara bırakıyor. Geleneksel kural tabanlı ve imza tabanlı teknolojiler, ince kötü niyetli davranışlarla çalışan ve aylarca tespit edilemeyen zayıf noktaları araştıran saldırıları yakalamakta yetersiz kalıyor. Saldırganların boş zamanları vardır ve Büyük Oyun'u beklemeye hazırdırlar.

Çözüm? Yukarıda listelenenler gibi en iyi uygulamaları sürdürmenin yanı sıra, sonraki düzey API güvenliğinin aşağıdaki gibi çalışma zamanı korumalarına da sahip olması gerekir:

  • Tüyler ürpertici güvenlik açığı olan kodu tanımlamak için.
  • Günlüğe kaydetme ve izleme Temel çizgileri oluşturmak ve anormallikleri belirlemek.
  • Arabuluculuk API'leri Görünürlüğü artırmak için API ağ geçitleri ile.
  • Şifreleme Çok katmanlı savunma için API'ler tarafından gönderilen veriler.
  • Erişim kontrollerini haricileştirin ve kimlik depoları – kimlik doğrulaması için asla API anahtarlarını kullanmayın.

İşletmeler API altın hücumundan hızla para kazandı ancak benimsenme hızı API güvenliğini geride bıraktı. Basit saldırılardan daha gelişmiş keşif taktiklerine kadar saldırganlar bu boşlukları doldurmaktan çekinmediler. Geçmişteki API hatalarından ders alarak ve geleceğin saldırılarını öngörerek, API güvenliğini büyümenin taleplerine uyacak şekilde ölçeklendirebiliriz.



Source link