OWASP Nedir? ASP.NET Core Web API’ler için Güvenlik Önlemleri
OWASP (Açık Web Uygulaması Güvenlik Projesi anlamına gelir), web uygulama güvenliği, dokümantasyon, çeşitli araçlar ve teknolojiler konusunda makaleler yayınlayan çevrimiçi bir topluluktur.
OWASP Web uygulamaları için 3–4 yılda bir ve en son 2017 de yayınladığı OWASP Top 10 listesini günümüzde popüler hale gelen API ler için de yapmıştır.
2019 yılı itibariyle OWASP API Security Top 10 listesinde yer alan açıklıklar aşağıda yer almaktadır.
- API1:2019 Broken Object Level Authentication
- API2:2019 Broken User Authentication
- API3:2019 Excessive Data Exposure
- API4:2019 Lack of Resources & Rate Limiting
- API5:2019 Broken Function Level Authorization
- API6:2019 Mass Assignment
- API7:2019 Security Misconfiguration
- API8:2019 Injection
- API9:2019 Improper Assets Management
- API10:2019 Insufficient Logging & Monitoring
API1:2019 Broken Object Level Authentication
Listenin ilk sırasında ödül avcılığı programlarında da sıklıkla karşılaşılan, güvenlik araştırmacılarının yakından bildiği ve incelediği IDOR yer almaktadır. IDOR en temel bağlamda açıklamak gerekirse doğrulanmamış obje erişimidir. Yani ziyaretçi erişmek istediği objeyi görmeye yetkili veya o objenin sahibi olduğunun doğrulanmaması işlemidir.
Örnek Saldırı Senaryoları
- X kullanıcısına ait bir finansal bilgisinin, Y kullanıcısı tarafından görülebilmesi yada tam tersi
- Y kullanıcısına ait olan id2 numaralı finansal numarasının, X kullanıcısı tarafından görüntülenebilmesi
- target/accounts/id1/financial_info -> X kullanıcısına ait olan finansal numarası
- target/accounts/id2/financial_info -> Y kullanıcısına ait olan finansal numarası
Yukarıdaki istekler değerlendirildiğinde GET metodu ile alınan id ile başlayan parametre, veritabanında sorgulanarak isteği gerçekleştiren kişi doğrulanmadan ekrana sonuçlar yazdırılır.
Nasıl Önlenir?
- Ziyaretçi veya kullanıcı tarafından, yukarıda verdiğimiz saldırı isteklerine benzer bir istek alındığında, burada yer alan ID nesnesinin hangi kullanıcıya aitse, o kullanıcı tarafından aktif bir oturumun olup, olmadığı sorgulanmalıdır. Eğer ki oturum, ilgili nesnenin sahibine ait değilse giriş sayfasına yönlendirilmelidir.
- İstemciden gönderilen kimliklere güvenmeyin. Bunun yerine oturum nesnesinde (JWT) depolanan kimlikleri kullanın.
- Rastgele tahmin edilemeyen kimlikler (UUID’ler) kullanın.
- Kullanıcı politikalarına ve hiyerarşisine dayanan uygun bir yetkilendirme mekanizması uygulayın.
API2:2019 Broken Authentication
Bu zafiyette genel olarak kimlik doğrulama gibi oturum yönetimi gibi bununla ilgili olan fonksiyonların yanlış kullanılıp uygulanması sonucu ortaya çıkıyor. Kötü niyetli olan saldırganlar parolaları, session tokenları ele geçiriyorlar. Bu saldırganlar genellikle Brute Force (kaba kuvvet saldırısı) yaparak sistemdeki kayıtlı kullanıcıların kullanıcı adı, parolalarını çalabilir. Bazı kullanıcılar kullanıcı adı ve parolalarını ilk oluşturdukları şekilde default parolaları kullanabiliyor. Saldırganlar bu şekilde olan kullanıcılara çok daha kolay sızabiliyor.
Nasıl Önlenir?
- Brute Force(Kaba Kuvvet) saldırılarını ve parola tahminini önlemek için uygulamanın güçlü bir parola politikası uyguladığından emin olun.
- Brute Force (kaba kuvvet saldırıları) bu saldırılardan korunmak için yanlış parola giriş denemelerine sınır koyulmalıdır ve yanlış parola denemelerinin log kaydı alınması gereklidir.
- Client tarafında Captcha kontrolü ile girişlerde robot kontrolü yapılabilir.
- 2FA (Two factor authentication) kullanılması
- Oturum kimlikleri URL’de olmamalı, güvenli bir şekilde saklanmalı ve kısa önürlü olmalıdır. Bunun için güçlü bir şekilde imzalanmış JWT (Json Web Token) kullanabilirsiniz.
- Parola kurtarma anahtarlarının süreli veya belirli istek sayısıyla kısıtlanması
- Parola saklamalarında tuzlama ve Argon2, PBKDF2, Scrypt ve Bcrypt gibi algoritmalarını kullanın.
API3:2019 Excessive Data Exposure
API endpointlerinin vermiş olduğu response paketleri (yanıtlar) içerisinde bir çok veri yer alabilir. UI tarafında bu bilgilerin filtreleneceği düşünülür. Fakat her zaman durum böyle olmaz. Kullanıcı bilgilerinin olduğu (Users) bir model düşünün. Bu model içerisinde ad, soyad, kullanıcı adı ve parola gibi alanlar bulunur. Eğer ki bu alanların tümü yanıt paketleri içerisinde yer verilirse, bu kategoriye ilişkin açıklığa sebebiyet verilmiş olur.
Nasıl Önlenir?
- UI (Client) tarafına sadece ihtiyaç duyulan ve gerekli verileri mapleyerek yaparak DTO larla sağlayın.
- Kazara veri sızıntılarını veya istisnaları önlemek için yanıt kontrollerini uygulayın.
- Deployment ve Production ortamlarının iyi kurgulanması, hata mesajlarının Production ortamında yer almaması
API4:2019 Lack of Resources and Rate Limiting
Rate Limiting olmaması API sunucularının performansını etkileyebilir ve saldırganların DDoS saldırıları başlatmasına izin verebilir. Tek bir istemci veya birden çok istemci aynı anda çok fazla istekte bulunduğunda, bu istemcilerden gelen istekler sunucunun istekleri işleme becerisini zorlayabilir ve dolayısıyla hizmeti yavaşlatabilir veya diğer kullanıcılar için kullanılamaz hale getirebilir.
Diğer bir sorun, Rate Limiting eksikliğinin, kimlik doğrulama endpointlerinde brute force (kaba kuvvet) saldırılarına yol açabilmesidir. Örneğin, bir kullanıcının kaç kez oturum açma isteği gönderebileceğine ilişkin bir sınır yoksa, kötü niyetli saldırganlar, başarılı olana kadar farklı parolalarla oturum açmaya çalışarak kullanıcıların parolalarını kaba kuvvetle zorlayabilir.
Nasıl Önlenir?
- Uygun şekilde hız sınırlaması tanımlanması, örneğin saniyede 100 ziyaretçi vb. gibi
https://github.com/stefanprodan/AspNetCoreRateLimit - Dosya yükleme limitlerinin tanımlanması.
- Client ve server tarafında, istek gövdesinin (request body) ve yanıtının (response) çok büyük olmadığını doğrulamamız gerekiyor. Bu, özellikle client tarafından belirtilen miktarda kayıt döndüren endpointler için geçerlidir. Client, bir seferde çok fazla kayıt talep ederse, request miktarını değiştirebilir ve ciddi bir sorun oluşmasına neden olabilir.
API5:2019 Broken Function Level Authorization
API noktalarına karşılık gelen hizmetlere erişirken belirli roller için farklı yollar belirlenebilir. İstemciler için client path’i kullanılırken, yöneticiler için admin pathi kullanılabilir. Bu doğrultuda tahmini çok da zor olmayan bu pathlere erişim sağlanması sonrasında rol değişimi gerçekleştirilebilir. 1.madde de benzer önlemler bu madde içinde geçerlidir.
Örnek Saldırı Senaryoları
- Ayrıcalıklı kullanıcıların istek göndermiş olduğu serviste yetki kontrolü bulunmaması
- target/users/v1/user/myinfo -> Sıradan kullanıcılara sunulan API hizmeti
- target/admins/v1/user/myinfo -> Ayrıcalıklı kullanıcılara sunulan API hizmeti
Nasıl Önlenir?
- Varsayılan olarak tüm erişimleri reddedin.
- Rol bazlı kimlik doğrulama kullanarak hizmeti kullanan kullanıcının rolünü teyit edin. Aksi durumlarda uyarı oluşturacak mekanizmaları tasarlayın.
- Yanlış erişimlerin log kaydı tutulması ve yöneticilere bu log kayıtları devamlı raporlanmalıdır.
API6:2019 Mass Assignment
API, istemciden aldığı verileri ilgili modelin alanlarına kontrolsüz olarak yazması olayı sonrasında ortaya çıkan güvenlik problemidir.
Örnek senaryo ile açıklayacak olursak; Kullanıcı bir ürün güncelleme ile alakalı bir request attığında eğer bu request içinde Stok bilgisi ile alakalı veriler varsa ve bu backend tarafında kontrol edilmiyorsa bu durumda Stok bilgisini değiştirebilecektir.
Nasıl Önlenir?
- Kullanıcıdan alınan verileri doğrudan nesnenin alanlarına bağlamayın. Örneğin; kullanıcı hiçbir zaman product.Title dosyasını düzenleyememelidir, ancak kullanıcı önyüzden title parametresi gönderdiğinde bizim bunu product.Title e API tarafında eşlememiz gerekir.
- API’ler tarafından alınabilecek fakat güncellenmesini istemediğiniz tüm alanlar için readonly özelliğini kullanın.
API7:2019 Security Misconfiguration
API sunucularının zayıf yapılandırması, saldırganların bunlardan yararlanmasına olanak tanır.
Aşağıdaki maddeler zayıf yapılandırmaya örnektir.
- Yamasız sistemler
- Korumasız dosyalar ve dizinler
- Sıkılaştırılmamış image dosyaları
- Eksik, güncel olmayan veya yanlış yapılandırılmış TLS
- Herkese açık depolama veya sunucu yönetim panelleri
- Eksik CORS ilkesi veya güvenlik başlıkları (Security Headers)
- Hata mesajlarının güvenli yapılandırılmaması
- Gereksiz özelliklerin aktif edilmesi
Nasıl Önlenir?
- Kullanılan tüm teknoloji yığınını göz önünde bulundurarak API’mizin yapılandırma dosyalarını düzenli olarak gözden geçirmeliyiz.
- Asla güvenli olmayan iletişim kanalları kullanmayın ve özellikle Hibrit bulut ortamlarında tüm iletişimleri göz önünde bulundurarak bunu değerlendirdiğinizden emin olun. (En az TLS 1.2 kullanın.)
- Güvenli CORS ilkesi uygulayın.
https://devnot.com/2019/cors-nedir/ - Güvenlik başlıklarını aktif bir şekilde kullanın.
https://medium.com/devopsturkiye/asp-net-core-uygulamalar%C4%B1nda-http-security-headers-ile-g%C3%BCvenli%C4%9Fi-art%C4%B1rmak-bfbd48bcd4e7 - Sunucu ve sistem tarafında gereksiz özellikleri kapatın.
API8:2019 Injection
Injection zafiyetleri olarak bilinen zafiyetler genel olarak kullanıcıdan alınan ve kontrol edilmeyen verilerden kaynaklıdır. Önlem alınmayan verilerde komut olarak çalıştırılıp ya da sorguya dahil edilmesi yöntemiyle oluşur.
Saldırganlar sistemlerin beklediğinden daha farklı veriler göndererek sistemlerde komutları çalıştırabilir ve erişme yetkisi olmayan verilere izinsiz erişebilirler. Saldırganlar bu işlemden sonra yetki yükseltme zafiyetlerini kullanarak sistemdeki yetkilerini daha fazla arttırabilirler. Bu şekilde tüm organizasyonların içine sızabilir. Injection zafiyetleri bu yüzden risk tablosu sıralamasında en üstte yer alıyor.
Injection saldırılarının en yaygın olarak kullanılan iki çeşidi vardır. SQL Injection ve Command Injection olarak ikiye ayrılır.
a. SQL Injection
SQL Injection saldırıları, kullanıcılardan gelen verilerin direk SQL sorgularına dahil edilerek web sitesine sızma işlemidir. Örnek vermek gerekirse:
http://ornekwebsite.com/news.php?read=145
Bu web site adresindeki read parametresindeki değeri bir SQL sorgusu ile veri tabanındaki kayıtlı haberler listesinin arasından bularak kullanıcılara gösteriyor. Bu zafiyete önlem alınmazsa yukarıdaki web sitesini ziyaret ettiğimizde aşağıdaki gibi bir SQL sorgusu çalışır.
SELECT * FROM news WHERE id = 145
Buraya kadar her şey normal işleyişinde ilerlemektedir. Ama saldırganlar read parametresine beklenmedik bir veri girince zafiyet başlıyor. Örnek olarak aşağıdaki gibi bir parametre:
http://ornekwebsite.com/news.php?read=**145; DROP ALL TABLES,
Bu URL çalıştığı zaman sistemin arka tarafında;
SELECT * FROM news WHERE id = 145; DROP ALL TABLES,
Şeklinde bir SQL sorgusu çalışır ve veri tabanındaki tüm tablolar silinir. Tabiki SQL Injection saldırısı ile sadece bu tür saldırma işlemleri yapılmaz, aynı zamanda tablolardaki tüm verileri de görebilir ve herhangi bir komut çalıştırılabilir. SQL Injection saldırısıyla kullanıcıların tablosunun tutulduğu bir veri tabanına saldıran kişi yönetici hesabını ele geçirebilir ve bu şekilde de saldırılan sistemi komple ele geçirmiş olur.
b. Command Injection
Bir web sitesi üzerinden örnek verilirse, aldığı parametrelerin isminde sistemde dosya oluşturur.
http://ornekwebsite.com/admin/command.php?*command*=**deneme.txt**
Bu sitede command ismindeki parametreye verilen değer isminde bir dosyayı sistemde oluşturuyor. Kaynak kodları aşağıdaki gibidir;
<?php
…
$file=$_GET[‘command’];
system (“touch $file”);
…
?>Normal kullanıcılar dosya.txt adında yeni bir dosya oluşturmak istedikleri zaman “touch dosya.txt” komutu çalışıyor. Buraya kadar her şey normal bir şekilde ilerliyor. Ama saldırganlar burada devreye giriyor ve aşağıdaki gibi bir değer veriyorlar;
http://ornekwebsite.com/admin/command.php?command=**dosya.txt; reboot**
Bu şekilde sistemde “touch dosya.txt; reboot” komutu çalışıyor. Dosya oluşturma işlemi başarılı şekilde gerçekleşiyor ama ardından sistem yeniden başlatılıyor. Bu zafiyet ile saldırganlar her türlü komutu çalıştırabilir. Bundan sonra hangi komutu çalıştıracağı saldırganın hayal gücüne kalıyor.
Nasıl Önlenir?
- Kullanıcıdan alınan girdileri doğrulayın, filtreleyin, temizleyin. (FluentValidation, HtmlSanitizer)
- Düz SQL sorguları yerine store procedureler, parametreli sorgular, yada Entity Framework gibi bir ORM toolu kullanılması tercih edilmelidir.
- Command Injection dan korunmak için, interpreter’a özgü kaçış syntaxını kullanarak özel karakterlerden kendinizi koruyun.
API9:2019 — Improper assets management
Bir çok organizasyon uygulama yönetimlerinde ortam ayrılığına gitmiştir. Bu doğrultuda en temel olarak development (geliştirme), production (üretiim) ortamlar ile karşılaşılır. Yukarıda da ifade edildiği üzere üretim ortamı ve geliştirici ortamı arasında farklılıklar olabilir. Bir ortamda hata mesajları açıkken, diğer ortamda kapalı tutulması gibi. Saldırganlar tarafından tespit edilen test ortamlarında güvenliğin prod ortama nispeten daha zayıf olduğu düşünülerek bu ortam hedef alınır.
Örnek Saldırı Senaryoları
- Eski ve güncel olmayan API’lerin daha güvensiz olduğu düşünülerek bu ortamlar hedef alınır.
- Geliştirme ortamından, üretim ortamına yayılım gerçekleştirilebilir.
Nasıl Önlenir?
- API envanteri tutun.
- Geliştirme ortamına erişimleri sınırlayın. Bu ortamdaki verileri karmaşıklaştırarak kullanın.
- API güvenlik duvarları gibi ek harici denetimler uygulayın.
- API’lerin eski sürümlerini uygun şekilde kullanımdan kaldırın veya bunlara yönelik güvenlik düzeltmelerini destekleyin.
API10:2019 Insufficient Logging and Monitoring
Yeterli loglama yapılmadığı için eksik veya etkisiz yapılandırmalar ile birlikte, saldırganların sisteme daha fazla saldırmasına, sistemdeki kalma süresini arttırma, sistemdeki verileri kurcalayıp istediği gibi değiştirmesine veya yok etmesine imkân verir.
Nasıl Önlenir?
- Başarısız girişimleri, erişim ve girdi hatalarını kayıt altına alın.
- Kayıt altına alınan logların biçimlendirilmesi farklı formatları desteklemelidir.
- Logların güvenli saklanması ve bütünlüğünün bozulmaması sağlanmalıdır.
- Loglarda hassas veriler yer almamalıdır.
- Gerçek zamanlı raporlama ve görselleştirme araçlarıyla entegre bir SIEM (Security information and event management) aracı gibi tüm günlüklerin tek bir yerde toplandığı merkezi bir günlük yönetim sistemine sahip olun.
- Zamanı senkronize et. (UTC)
- Loglar yakından izlenmelidir ve Loglar silinmemeli veya değiştirilmemelidir.
