OWASP API Güvenliği Top 10
Herkese Selam :)
API güvenliği tarafında en çok görülen 10 güvenlik zafiyetinin neler olduğunu ve bu zafiyetlerden korunmak için yapılması gerekenlerden kısaca bahsedelim.
OWASP tarafından yayınlanan, 2019 yılına ait “API Security Top 10” güvenlik zafiyetleri referans alınarak, hazırlanmıştır.
A1: Broken Object Level Authorization
İlk sırayı, Insecure Direct Object Reference (IDOR) olarak bilinen ve yetkilendirme kontrolünü eksikliği sebebiyle meydana gelen güvenlik açığı alıyor.
Resimdeki örnek üzerinden gidecek olursak:
- Kullanıcı, erişmek istediği dokümanı sunucudan talep ediyor.
- Sunucu, gelen istekteki değere bakıyor. Bu değere referans eden nesneyi veri tabanından sorgulayıp, kullanıcıya cevap dönüyor.
Buraya kadar her şey normal gibi :) Peki, kullanıcı kendi sahipliği dışındaki bir dokümanı görüntülemek istediğinde? İşte sorun burada başlıyor.
Eğer sunucu tarafında, kullanıcının erişmek istediği nesneye erişim yetkisinin olup, olmadığı kontrol edilmiyorsa bu güvenlik açığına karşı savunmasız durumda olacaktır. Kullanıcı, “1000” id değerine karşılık gelen doküman yerine, normalde erişim sağlayamaması beklenilen diğer kullanıcılara ait olan dokümanlara erişim sağlayabilir.
Doküman sahiplik bilgilerinin aşağıdaki gibi olduğunu varsayalım;
User1 kullanıcısı ile oturum açtıktan sonra yetki kontrolünün uygun bir şekilde yapılmaması sebebiyle id değeri “1002” olan ve User2 kullanıcısına ait doküman görüntülenebilir.
Örnek istekler:
https://example.com/previewDocument?Id=1000
https://example.com/previewDocument?Id=1002
Korunma Yöntemleri:
- Sunucu tarafında, kullanıcının yapacağı her işlem için yetki kontrolü sağlanmalıdır. İsteği yapan kullanıcının, erişmek isteğini nesneye erişim yetkisinin olup, olmadığı kontrol edilmelidir.
A2: Broken Authentication
Kimlik doğrulama mekanizması ve bileşenleriyle ilgili problemler bu başlık altında yer almaktadır.
Örnek olarak bu maddeler aşağıdaki gibidir:
- Korumasız API’ler
- Zayıf kimlik doğrulama mekanizmaları
- Zayıf imzalama/şifreleme algoritmalarının veya basit/varsayılan parolaların kullanımı
- Captcha veya hesap kitleme mekanizmaların eksikliği sebebiyle kaba kuvvet saldırılarına maruz kalınması
- URL’de bulunan hassas bilgiler (token ve kimlik bilgileri gibi)
- Token problemleri (validasyon ve geçerlilik süreleri gibi)
Örnekler arttırılabilir, genel olarak bu gibi maddeler Broken Authentication başlığı altında yer almaktadır.
Korunma Yöntemleri:
- Kimlik doğrulama, token oluşturma ve saklama gibi işlemlerde standartların kullanılması önerilmektedir.
- Parola sıfırlama gibi tek kullanımlık oluşturulan bağlantılara özellikle dikkat edilmelidir.
- Kısa ömürlük token’ların kullanılması önerilmektedir.
- Sunucu tarafında, token’ın validasyonu uygun bir şekilde sağlanmalıdır.
- Multi faktör kimlik doğrulama (MFA) kullanılması önerilmektedir.
- Kaba kuvvet saldırılarına karşı istek sınırlaması, hesap kitleme veya captcha gibi mekanizmaların kullanılması önerilmektedir.
A3: Excessive Data Exposure
Kullanıcılar, çağırdıkları API’ler üzerinden çeşitli bilgiler edinebilir. Yapılan hatalardan birisi, kullanıcıya detaylı bir şekilde bilgi verilmesidir. Genellikle tercih edilen yöntem, sunucudan toplu bir şekilde veriyi döndürüp, kullanıcı tarafında filtreleme yapılması ve sadece istenilen bilgilerin kullanıcıya gösterilmesidir. Ancak, kullanıcı tarafında filtreleme yapıldığı için bu yöntem doğru bir yaklaşım değildir. Proxy ile araya girilerek, trafik incelendiğinde, sunucudan dönen cevaptaki tüm bilgiler açığa çıkacaktır.
Korunma Yöntemleri:
- Kullanıcı tarafında yapılan filtrelemelere asla güvenilmemelidir.
- Uygulamadan veri dönen noktalar incelenmeli, gereksinimi belirleyerek en az miktarda veri döndürülmelidir.
A4: Lack of Resource & Rate Limiting
API çağrıları yapılırken, istek sınırlaması olmaması sunucunun kaynaklarını gereksiz yere tüketerek, servis dışı kalmasına sebep olabilir.
Örneğin:
- Uygulama üzerinde, dosya yükleme fonksiyonu olduğunu düşünelim. Eğer yüklenen dosyanın boyutu, sunucu tarafında sınırlandırılmadıysa, yüksek boyutlu dosyalar yüklenerek sunucunun disk alanını doldurabilir, hizmet dışı kalmasına sebep olabilir.
- Bir diğer örnek, uygulama üzerinde giriş yapılırken OTP kontrolü olduğunu düşünelim. Kullanıcı adı ve parola girişi sonrasında telefonumuza gelen OTP kodunu göndererek, giriş yapıyoruz. Eğer, OTP kodunu talep etmek için çağırdığımız API üzerinde istek sınırlaması yoksa, OTP kodu sürekli talep edilerek, servis gereksiz yere meşgul edilebilir ve normal kullanıcılardan gelen OTP kodu taleplerine cevap veremez hale gelebilir.
Korunma Yöntemleri:
- Yapılan istekler için boyut sınırlaması belirlenerek, sunucu tarafında kontrol edilmelidir.
- Cevapta döndürülecek kayıt sayısı kontrol edilmelidir.
- Belirli bir süre içerisinde API’nin ne sıklıkla çağırılabileceğine sınırlama getirilmelidir.
A5: Broken Function Level Authorization
Büyük ölçekli uygulamalarda, farklı kullanıcı hiyerarşileri, farklı roller ve gruplar bulunmaktadır. Bu durumda, rollerin ve grupların yapabileceği işlemler ve yetkiler birbirinden farklıdır. Yetkilendirmenin uygun bir şekilde kontrol edilmediği durumlarda bu zafiyet ortaya çıkabilir. Örneğin, yönetici rolüne sahip bir kullanıcının yapabileceği bir işlemin, daha düşük bir role sahip kullanıcı tarafından yapılabilmesine neden olabilir.
Örneğin:
- /api/users/user/myinfo # Kayıtlı kullanıcılar tarafından çağırılabilen ve kullanıcı bilgilerini döndüren endpoint.
- /api/admins/users/all # Yönetici rolüne sahip kullanıcılar tarafından çağırılması beklenilen ve tüm kullanıcıların bilgilerini döndüren endpoint.
Ancak, uygulama üzerinde yetki kontrollerinin uygun bir şekilde yapılmaması nedeniyle, normalde yönetici rolüne sahip kullanıcının çağırarak tüm kullanıcı bilgilerinin döndürüldüğü endpoint, yetkisiz bir kullanıcı tarafından çağırabilir.
Korunma Yöntemleri:
- Farklı rolleri ve grupları göz önünde bulundurarak, yetkilendirme kontrollerinin uygun bir şekilde sağlanması gerekmektedir.
- Uygulama mekanizmaları varsayılan olarak tüm erişimleri reddetmeli, sadece uygun olan role yönelik işlemlere izin verilmelidir.
A6: Mass Assignment
Modern uygulamalardaki nesneler birçok özellik barındırabilir. Bu özelliklerin bazıları direkt olarak kullanıcı tarafından değiştirilebilirken (Örneğin, isim ve adres bilgileri gibi) bazı özellikler değiştirilemez. Bu noktada, kullanıcıdan gelen veriler, doğrudan nesnelere dönüştürülüyorsa yani herhangi bir filtreleme yapılmadan işleme alınıyorsa bu duruma karşı savunmasız olacaktır.
Örneğin:
Kullanıcıdan gelen veriyi, doğrudan nesnelere bağlayan kod örneği verilmiştir.
Node JS: var user = new User(req.body); user.save();
/api/users endpoint’i ile kullanıcı bilgilerinin güncellenebildiğini varsayalım. Yapılan istek aşağıdaki gibidir. Yönetici rolü için ise, backend tarafında “isAdmin” olarak bir nesnenin tanımlandığını düşünelim. Kontrol eksikliği sebebi ile isteğe eklenecek olan “isAdmin”=True parametresi ile kullanıcımızın rolünü, yönetici yetkilerine yükseltebiliriz.
POST /api/users
..
{“username”:”haktan”,”email”:”test@test.com”,”password”:”***″,”comment”:null, “isAdmin”=True}
Korunma Yöntemleri:
- Gelen verileri ve dahili nesneleri otomatik olarak bağlanmaması gerekmektedir.
- Kullanıcı tarafından değiştirilebilecek tüm özellikler, beyaz liste yaklaşımı ile kontrol edilmelidir.
- Hiçbir zaman değiştirilemeyecek olan özellikler, nesne şemalarında belirtilmelidir.
A7: Security Misconfiguration
Hatalı ve eksik yapılandırma kaynaklı güvenlik problemleri bu başlık altında yer almaktadır.
Örnek olarak bu maddeler aşağıdaki gibidir:
- Güncel olmayan sistemler
- Korumasız dosya ve dizinler
- SSL/TLS problemleri
- Hatalı CORS yapılandırması ve eksik güvenlik başlıkları
- Hata mesajları (Stack trace)
- Gereksiz özelliklerin etkin olması
Örnekler arttırılabilir, genel olarak bu gibi maddeler Security Misconfiguration başlığı altında yer almaktadır.
Korunma Yöntemleri:
- Yamalar takip edilmeli ve sıkılaştırma yöntemleri uygulanmalıdır.
- Hata mesajları ele alınarak, kontrolleri hata mesajları gösterilmelidir.
- Gereksiz özelliklerin devre dışı bırakılması önerilmektedir.
- Sadece izin verilen HTTP metotlarının kullanılması sağlanmalıdır.
- Güvenlik başlıklarının eklenmesi ve CORS tanımının sadece güvenilir kaynaklara izin verilecek şekilde tanımlanması önerilmektedir.
A8: Injection
Injection, temel olarak bir saldırganın sisteme zararlı bir girdi göndermesi ve bu girdiğinin yapıya bağlı olarak interpreter tarafından yorumlanarak sorgunun bir parçası olarak işleme alınmasıyla meydana gelen bir güvenlik açığıdır. Injection saldırıları çok geniş bir kapsama sahiptir. (Örnek olarak: SQL, LDAP, NoSQL, OS Command gibi durumlar ile injection atakları yapılabilir.)
Injection saldırısı, kullanıcıdan alınan verinin herhangi bir kontrolden geçirilmeden, işlenmesiyle ortaya çıkmaktadır. Etkisi de, gelen verinin nerede işlenmesiyle ilgilidir. Saldırganlar, yorumlayıcıya uygun özel karakterler kullanarak gönderdikleri veriler ile sorgulara müdahale etmeye çalışırlar. Örneğin, kullanıcıdan alınan verinin, direkt olarak SQL sorgularına dahil edilmesiyle birlikte SQL injection zafiyeti meydana gelmektedir.
Korunma Yöntemleri:
- Kullanıcıdan gelen verilere asla güvenilmemelidir.
- Gelen tüm veriler, beyaz liste yaklaşımı ile (sadece istenilen karakterlere izin verilmesi) kontrol edilmelidir.
- Encoding tekniği uygulanmalıdır.
- Veri sızıntılarını önlemek için, API çıktılarının sınırlanması önerilmektedir.
A9: Improper Assets Management
Saldırganlar, tespit ettikleri test ortamları ve API eski sürümleri üzerinden saldırılar gerçekleştirebilir. Bu ortamların, PROD ortamlar gibi iyi korunmadığı bilinen bir gerçektedir. Bu nedenle, test ortamlarına erişimin kısıtlanması ve API eski sürümlerinin kullanımdan kaldırılması büyük önem taşımaktadır.
Bu başlık ile ilgili, geçtiğimiz senelerde yaşanan dünyaca ünlü bir şirketin, unutulan bir API üzerinden 100 milyondan fazla kullanıcı verisinin ifşa edilmesi örnek olarak gösterilebilir.
Korunma Yöntemleri:
- Envanter sürekli güncellenmeli ve takip edilmelidir.
- API’lerin eski sürümlerinin kullanımdan kaldırılması önerilmektedir.
- Yalnızca geçerli PROD ortam için değil, kullanımda olan tüm sürümler için harici koruma önlemleri uygulanmalıdır.
- Test ortamlarına erişimin kısıtlanması ve bu ortamların ayrılması önerilir.
- API dokümantasyonlarının sadece yetkili kişiler tarafından erişilmesi sağlanmalıdır.
A10: Insufficient Logging & Monitoring
Saldırganlar, kayıt ve izleme eksikliklerinden faydalanarak, uzun süre fark edilmeden hedefledikleri işlemleri gerçekleştirebilir.
Korunma Yöntemleri:
- Başarısız kimlik doğrulamaları, reddedilen erişimleri ve girdi doğrulama hataları gibi durumlar kayıt edilmelidir.
- Günlükler, hassas veri olarak ele alınmalı ve bütünlüğü garanti edilmelidir.
- Günlükler, SIEM gibi ürünler ile entegre edilmelidir.
Kaynaklar:
