API Sızma / Penetrasyon Testi

Api Nedir?

API, iki uygulamanın birbiriyle haberleşmesine izin veren bir yazılım aracı olan Application Programming Interface kelimesinin kısaltmasıdır. Örneğin Facebook gibi bir uygulamayı her kullandığınızda, bir anlık mesaj gönderdiğinizde veya telefonunuzdaki hava durumunu her kontrol ettiğinizde bir API kullanıyorsunuz demektir.

API 

Saldırganın uygulamaya veya sunucuya daha fazla erişim elde etmek için kullanabileceği favori saldırı yüzeylerinden biridir. API Sızma testi , web uygulama sızma testi metodolojisiyle aynıdır . Bu tip test yöntemlerinin, saldırıdaki bazı küçük değişikliklerle diğer web uygulamalarına benzer olduğu durumlarda, OWASP Açık Web Uygulaması Güvenlik Projesinde olduğu gibi enjeksiyon, erişim kontrolü, bilgi ifşası gibi web uygulaması için taradığımız bazı standart güvenlik açıklarını aramamız gerekir.

API Kimlik Doğrulaması ve Oturum Yönetimi

Geliştiriciler genel olarak HTTP temel, Özet Kimlik Doğrulaması ve JSON Web Simgesi Girişini kullanırlar. Günümüzde oAuth, yetkilendirme ve kimlik doğrulama veya oturum yönetimini uygulamanın kolay bir yoludur. oAuth size süresi dolabilir taşıyıcı belirteci sağlar ve bu aynı zamanda saldırganın kimlik doğrulama modülünde güvenlik sorununu bulmasını zorlaştırır. API’de ki kimlik doğrulama jetonlarını nasıl tanımlayabilirsiniz? Cevap aşağıdaki resimde:

API’nin Tasarımı veya Yapısı

Modern bir uygulama, mikro hizmetleri çağırmak veya eylemleri gerçekleştirmek veya kullanıcının davranışlarını izlemek için API kullanır. API’nin tasarımı veya yapısı müşterilere veya uygulama kullanıcısına sunulur. API’nin bu yapısı nedeniyle, saldırgan API’nin yapısını anlayabilir ve bu bilgi saldırısı API’sini daha fazla kullanabilir.

REST API, GET, POST, PUT, DELETE, HEAD ve PATCH eylemleri gibi farklı işleme isteklerini kullanır. Saldırgan, API’yi anlamak için istek başlıklarını değiştirebilir ve bu anlayışı tamamen çalışan bir saldırı istismarı oluşturmak için kullanabilir. İşleme talebi değiştirilebilir. İşleme talebinin en iyi uygulaması olarak tahrif edilmemeli veya değiştirilmemelidir. Aşağıda bir işleme isteği örneği verilmiştir ve ayrıca yapılan istekler için sunucu yanıtlarını takip edin:

API’de güvenlik açıkları nasıl bulunur?

Müşteri tarafından sağlanan belgeleri kullanarak saldırı yüzeyi öğrenilir. Bir geliştirici kılavuzu bize API’nin içiyle ilgili daha fazla ayrıntı verebilir. Çalışan bir sunucuda dokümantasyon sağlanmadıysa veya API dağıtıldıysa, tüm API isteklerini proxy kullanarak yakalamak gerekir. Her API isteğinde POST / GET veya diğer yöntemler tanımlanır. Anlama aşaması tamamlandıktan sonra, olası güvenlik testi durumlarını yazılır. Aşağıda, güvenlik açıkları için temel test durumları verilmiştir.

OWASP 2017 Test durumları :

1. Her API modülündeki her parametreyi gözlemlenir, verilerin kaynaktan hedefe Parametrelere bakılarak nasıl aktarıldığını anlaşılır.
2. API’nin yetkili olması durumunda herhangi bir yetkilendirme jetonu olup olmadığını belirleyip ardından bu yetkilendirme jetonunu kaldırılır ve uygulama yanıtına bakılır. Bazı durumlarda, yetkilendirme doğru bir şekilde uygulanmazsa, API size uygulamanın yasaklanmış varlıklarına erişim imkanı sağlayabilir.
3. Her modülü farklı bir kullanıcı erişim düzeyiyle (ör: yönetici, moderatör, normal kullanıcı) analiz edip kontrol edilir.
4. Yönetici modüllerine kısıtlı kullanıcı aracılığıyla erişilip erişilemeyeceğini kontrol edilir.
5. İd = 1234 gibi IDOR ( Insecure Direct Object Reference) tipi güvenlik açıklarına karşı savunmasız olabilecek parametreleri belirleyin ve ayrıca ID’leri işlemek için tanımlama bilgilerine bakılır.
6. Bir istekte tüm parametrelere özel karakterler ekleyerek enjeksiyon açıklarını kontrol edilip sunucudan gelen yanıtı kontrol edilir. Herhangi bir iz bulunursa, bu bilgiler daha fazla yararlanma için kullanılır.
7. Tüm parametrelere (<,>) değerinden daha büyük, daha az karakter ekleyip uygulamanın bunları > ve < olarak kodlanıp kodlanmadığına bakılır. Bir uygulama herhangi bir özel karakterden kaçamazsa, uygulama XSS (siteler arası komut dosyası oluşturma) gibi istemci tarafı saldırılarına açık olabilir.
8. XML harici varlık saldırısını (entity injection attack) anlamak için içerik türü sunucu başlığını değiştirilir. Örnek: Content Application / JSON öğesini application / XML olarak değiştirip XML varlık enjeksiyonunu olup olmadığı kontrol edilir.