diff --git a/editions/2019/mkdocs.yml b/editions/2019/mkdocs.yml index 5216b4969..143fb9a11 100644 --- a/editions/2019/mkdocs.yml +++ b/editions/2019/mkdocs.yml @@ -23,3 +23,5 @@ extra: lang: pt-pt - name: Russian lang: ru + - name: Türkçe + lang: tr diff --git a/editions/2019/tr/0x00-header.md b/editions/2019/tr/0x00-header.md new file mode 100644 index 000000000..b703ff4be --- /dev/null +++ b/editions/2019/tr/0x00-header.md @@ -0,0 +1,20 @@ +--- +title: '' +--- + +![OWASP LOGO](./images/owasp-logo.png) + +# OWASP API Security Top 10 2019 + +En Kritik 10 API Güvenliği Riski + +29 Mayıs 2019 + +![WASP Logo URL TBA](./images/front-wasp.png) + +| | | | +| - | - | - | +| https://owasp.org | Bu çalışma [Creative Commons Attribution-ShareAlike 4.0 International License][1] ile lisanslanmıştır | ![Creative Commons License Logo](images/front-cc.png) | + +[1]: http://creativecommons.org/licenses/by-sa/4.0/ + diff --git a/editions/2019/tr/0x00-notice.md b/editions/2019/tr/0x00-notice.md new file mode 100644 index 000000000..f420b1b4c --- /dev/null +++ b/editions/2019/tr/0x00-notice.md @@ -0,0 +1,14 @@ +# Bilgilendirme + +Bu metin, OWASP API Security Top 10 dokümanının metin sürümüdür ve Portable +Document Format (PDF) olarak dağıtılan resmî sürüm için kaynak olarak +kullanılır. + +Yorum, düzeltme veya çeviri gibi projeye yapılacak katkılar burada +yapılmalıdır. [Nasıl Katkıda Bulunulur][1] hakkında ayrıntılı bilgi için +[CONTRIBUTING.md][1] dosyasını inceleyebilirsiniz. + +* Erez Yallon +* Inon Shkedy + +[1]: ../../../CONTRIBUTING.md diff --git a/editions/2019/tr/0x00-toc.md b/editions/2019/tr/0x00-toc.md new file mode 100644 index 000000000..0c5eeaa23 --- /dev/null +++ b/editions/2019/tr/0x00-toc.md @@ -0,0 +1,23 @@ +# İçindekiler + +* [İçindekiler](0x00-toc.md) +* [OWASP Hakkında](0x01-about-owasp.md) +* [Ön Söz](0x02-foreword.md) +* [Giriş](0x03-introduction.md) +* [Sürüm Notları](0x04-release-notes.md) +* [API Güvenliği Riskleri](0x10-api-security-risks.md) +* [OWASP En Kritik 10 API Güvenliği Riski – 2019](0x11-t10.md) +* [API1:2019 Nesne Düzeyinde Yetkilendirme Eksikliği](0xa1-broken-object-level-authorization.md) +* [API2:2019 Kullanıcı Kimlik Doğrulama Eksikliği](0xa2-broken-user-authentication.md) +* [API3:2019 Aşırı Veri İfşası](0xa3-excessive-data-exposure.md) +* [API4:2019 Kaynak ve Hız Sınırlaması Eksikliği](0xa4-lack-of-resources-and-rate-limiting.md) +* [API5:2019 Fonksiyon Düzeyinde Yetkilendirme Eksikliği](0xa5-broken-function-level-authorization.md) +* [API6:2019 Toplu Atama](0xa6-mass-assignment.md) +* [API7:2019 Hatalı Güvenlik Yapılandırması](0xa7-security-misconfiguration.md) +* [API8:2019 Enjeksiyon](0xa8-injection.md) +* [API9:2019 Hatalı Varlık Yönetimi](0xa9-improper-assets-management.md) +* [API10:2019 Yetersiz Loglama ve İzleme](0xaa-insufficient-logging-monitoring.md) +* [Geliştiricileri Neler Bekliyor?](0xb0-next-devs.md) +* [DevSecOps'u Neler Bekliyor?](0xb1-next-devsecops.md) +* [Metodoloji ve Veriler](0xd0-about-data.md) +* [Teşekkürler](0xd1-acknowledgments.md) diff --git a/editions/2019/tr/0x01-about-owasp.md b/editions/2019/tr/0x01-about-owasp.md new file mode 100644 index 000000000..2819253ef --- /dev/null +++ b/editions/2019/tr/0x01-about-owasp.md @@ -0,0 +1,63 @@ +# OWASP Hakkında + +Open Worldwide Application Security Project (OWASP), kurumların güvenilir +uygulamalar ve API'ler geliştirmesine, satın almasına ve bunların bakımını +yapmasına yardımcı olmayı amaçlayan açık bir topluluktur. + +OWASP bünyesinde aşağıdaki kaynaklara ücretsiz ve açık bir şekilde +erişebilirsiniz: + +* Uygulama güvenliği araçları ve standartları. +* Uygulama güvenliği testleri, güvenli kod geliştirme ve güvenli kod inceleme + konularını kapsamlı biçimde ele alan kitaplar. +* Sunumlar ve [videolar][1]. +* Birçok yaygın konu hakkında [hızlı başvuru rehberleri][2]. +* Standart güvenlik kontrolleri ve kütüphaneleri. +* Dünya genelindeki [yerel OWASP toplulukları][3]. +* Öncü araştırmalar. +* Dünya çapında düzenlenen kapsamlı [konferanslar][4]. +* [E-posta listeleri][5]. + +Daha fazla bilgi için: [https://www.owasp.org][6]. + +OWASP'ın tüm araçları, dokümanları, videoları, sunumları ve yerel toplulukları; +uygulama güvenliğini geliştirmek isteyen herkesin ücretsiz ve açık erişimine +sunulmaktadır. + +Uygulama güvenliğinin insan, süreç ve teknoloji boyutlarıyla birlikte ele +alınması gerektiğini savunuyoruz. Çünkü uygulama güvenliğinde en etkili +sonuçlar, bu alanların tümünde iyileştirme yapılmasıyla elde edilir. + +OWASP, yeni bir organizasyon modelini temsil eder. Ticari baskılardan bağımsız +olmamız, uygulama güvenliği konusunda tarafsız, uygulanabilir ve uygun +maliyetli bilgiler sunmamızı sağlar. + +OWASP'ın herhangi bir teknoloji şirketiyle bağlantısı yoktur. Bununla +birlikte, ticari güvenlik teknolojilerinin bilinçli bir şekilde kullanılmasını +destekleriz. OWASP bünyesindeki içerik ve kaynaklar; iş birliğine dayalı, +şeffaf ve açık bir süreçle hazırlanır. + +OWASP Foundation, projenin uzun vadeli başarısını güvence altına alan kâr +amacı gütmeyen bir kuruluştur. OWASP yönetim kurulu üyeleri, yerel topluluk +liderleri, proje liderleri ve proje üyeleri dâhil olmak üzere OWASP +bünyesinde görev alan kişilerin neredeyse tamamı gönüllüdür. Yenilikçi +güvenlik araştırmalarını fon ve altyapı desteğiyle destekliyoruz. + +Siz de bize katılın! + +## Telif Hakkı ve Lisans + +![license](images/license.png) + +Copyright © 2003-2019 The OWASP Foundation. Bu belge, [Creative Commons +Attribution Share-Alike 4.0 lisansı][7] kapsamında yayınlanmıştır. Bu +çalışmayı yeniden kullanırken veya dağıtırken, lisans koşullarını açıkça +belirtmeniz gerekir. + +[1]: https://www.youtube.com/user/OWASPGLOBAL +[2]: https://www.owasp.org/index.php/OWASP_Cheat_Sheet_Series +[3]: https://www.owasp.org/index.php/OWASP_Chapter +[4]: https://www.owasp.org/index.php/Category:OWASP_AppSec_Conference +[5]: https://lists.owasp.org/mailman/listinfo +[6]: https://www.owasp.org +[7]: http://creativecommons.org/licenses/by-sa/4.0/ diff --git a/editions/2019/tr/0x02-foreword.md b/editions/2019/tr/0x02-foreword.md new file mode 100644 index 000000000..1a8c7370f --- /dev/null +++ b/editions/2019/tr/0x02-foreword.md @@ -0,0 +1,44 @@ +# Ön Söz + +Günümüzün uygulama odaklı dünyasında inovasyonun temel yapı taşlarından biri +Uygulama Programlama Arayüzüdür (API). Bankacılıktan perakende ve ulaşıma, +IoT'den otonom araçlara ve akıllı şehirlere kadar API'ler; modern mobil, SaaS +ve web uygulamalarının kritik bir parçasıdır ve müşteriye yönelik, iş +ortağına yönelik ile kurum içi uygulamalarda karşımıza çıkar. + +API'ler, doğaları gereği uygulama mantığını ve Kişisel Olarak Tanımlanabilir +Bilgiler (PII) gibi hassas verileri dışarıya açar; bu nedenle saldırganların +giderek daha fazla hedefi hâline gelmiştir. Güvenli API'ler olmadan hızlı +inovasyon mümkün değildir. + +Web uygulamalarına yönelik daha kapsamlı bir Top 10 güvenlik riskleri +listesinin hâlâ gerekli olmasına karşın, API'lerin kendine özgü yapısı +nedeniyle API'lere özel bir güvenlik riskleri listesine de ihtiyaç vardır. +API güvenliği; API'lere özgü zafiyetleri ve güvenlik risklerini anlamaya ve +azaltmaya yönelik strateji ve çözümlere odaklanır. + +[OWASP Top 10 Projesi][1]'ne aşinaysanız, iki belge arasındaki benzerlikleri +fark edeceksiniz: her ikisi de okunabilirlik ve uygulanabilirlik göz önünde +bulundurularak hazırlanmıştır. OWASP Top 10 serisinde yeniyseniz, doğrudan +Top 10 listesine geçmeden önce [API Güvenliği Riskleri][2] ve [Metodoloji ve +Veriler][3] bölümlerini okumanız daha faydalı olabilir. + +OWASP API Security Top 10 ile ilgili soru, yorum ve fikirlerinizi GitHub +proje deposu üzerinden paylaşarak katkıda bulunabilirsiniz: + +* https://github.com/OWASP/API-Security/issues +* https://github.com/OWASP/API-Security/blob/master/CONTRIBUTING.md + +OWASP API Security Top 10'a aşağıdaki adreslerden ulaşabilirsiniz: + +* https://www.owasp.org/index.php/OWASP_API_Security_Project +* https://github.com/OWASP/API-Security + +Emekleri ve katkılarıyla bu projenin hayata geçirilmesini sağlayan tüm +katkıda bulunanlara teşekkür ederiz. Katkıda bulunanların tamamını +[Teşekkürler bölümünde][4] bulabilirsiniz. Teşekkürler! + +[1]: https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project +[2]: ./0x10-api-security-risks.md +[3]: ./0xd0-about-data.md +[4]: ./0xd1-acknowledgments.md diff --git a/editions/2019/tr/0x03-introduction.md b/editions/2019/tr/0x03-introduction.md new file mode 100644 index 000000000..b89e61e04 --- /dev/null +++ b/editions/2019/tr/0x03-introduction.md @@ -0,0 +1,28 @@ +# Giriş + +## OWASP API Security Top 10 - 2019'a Hoş Geldiniz! + +OWASP API Security Top 10'un ilk sürümüne hoş geldiniz. OWASP Top 10 +serisine aşinaysanız benzerlikleri fark edeceksiniz: her ikisi de +okunabilirlik ve uygulanabilirlik göz önünde bulundurularak hazırlanmıştır. +Değilseniz, en kritik API güvenliği risklerini incelemeden önce [OWASP API +Security Project wiki sayfasını][1] ziyaret etmenizi öneririz. + +API'ler modern uygulama mimarilerinde çok önemli bir role sahiptir. Güvenlik +farkındalığı oluşturma ile inovasyon farklı hızlarda ilerlediğinden, yaygın +API güvenlik zafiyetlerine odaklanmak önem taşır. + +OWASP API Security Top 10'un temel amacı; geliştiriciler, tasarımcılar, +mimarlar, yöneticiler veya kuruluşlar gibi API geliştirme ve bakım sürecinde +yer alan herkesi bilgilendirmek ve eğitmektir. + +Bu ilk sürümün nasıl hazırlandığı hakkında daha fazla bilgiyi [Metodoloji ve +Veriler][2] bölümünde bulabilirsiniz. Sonraki sürümlerde, herkese açık bir +veri çağrısıyla güvenlik sektörünü bu sürece dahil etmek istiyoruz. Şimdilik +herkesi [GitHub repository'miz][3] veya [e-posta listemiz][4] üzerinden +soru, yorum ve fikirleriyle katkıda bulunmaya davet ediyoruz. + +[1]: https://www.owasp.org/index.php/OWASP_API_Security_Project +[2]: ./0xd0-about-data.md +[3]: https://github.com/OWASP/API-Security +[4]: https://groups.google.com/a/owasp.org/forum/#!forum/api-security-project diff --git a/editions/2019/tr/0x04-release-notes.md b/editions/2019/tr/0x04-release-notes.md new file mode 100644 index 000000000..9eafebfde --- /dev/null +++ b/editions/2019/tr/0x04-release-notes.md @@ -0,0 +1,24 @@ +# Sürüm Notları + +Bu, OWASP API Security Top 10'un üç veya dört yılda bir periyodik olarak +güncellemeyi planladığımız ilk sürümüdür. + +Bu sürümden farklı olarak, sonraki sürümlerde güvenlik sektörünü bu çabaya +dahil edecek şekilde herkese açık bir veri çağrısı yapmak istiyoruz. Bu +sürümün nasıl oluşturulduğuyla ilgili daha fazla ayrıntıyı [Metodoloji ve +Veriler][1] bölümünde bulabilirsiniz. Güvenlik riskleri hakkında daha fazla +bilgi için lütfen [API Güvenliği Riskleri][2] bölümüne bakın. + +Son birkaç yılda uygulama mimarisinin önemli ölçüde değiştiğini belirtmekte +fayda var. Günümüzde API'ler; mikroservisler, Tek Sayfa Uygulamaları (SPA), +mobil uygulamalar, IoT vb. gibi bu yeni mimaride çok önemli bir rol +oynamaktadır. + +OWASP API Security Top 10, modern API güvenliği sorunları hakkında +farkındalık oluşturmak için gerekli bir çalışmaydı. Bu, [Teşekkürler][3] +bölümünde listelenen çok sayıda gönüllünün büyük emeği sayesinde mümkün +olabilmiştir. Teşekkürler! + +[1]: ./0xd0-about-data.md +[2]: ./0x10-api-security-risks.md +[3]: ./0xd1-acknowledgments.md diff --git a/editions/2019/tr/0x10-api-security-risks.md b/editions/2019/tr/0x10-api-security-risks.md new file mode 100644 index 000000000..40043db9b --- /dev/null +++ b/editions/2019/tr/0x10-api-security-risks.md @@ -0,0 +1,47 @@ +# API Güvenliği Riskleri + +Risk analizi yapılırken [OWASP Risk Değerlendirme Metodolojisi][1] kullanılmıştır. + +Aşağıdaki tabloda risk skoruyla ilişkili terminoloji özetlenmiştir. + +| Tehdit Aktörleri | İstismar Edilebilirlik | Zayıflığın Yaygınlığı | Zayıflığın Tespit Edilebilirliği | Teknik Etki | İş Etkileri | +| :-: | :-: | :-: | :-: | :-: | :-: | +| API'ye Özgü | Kolay: **3** | Çok yaygın **3** | Kolay **3** | Ciddi **3** | Kuruluşa özgü | +| API'ye Özgü | Orta: **2** | Yaygın **2** | Orta **2** | Orta **2** | Kuruluşa özgü | +| API'ye Özgü | Zor: **1** | Nadir **1** | Zor **1** | Düşük **1** | Kuruluşa özgü | + +**Not**: Bu yaklaşım, tehdit aktörünün saldırıyı gerçekleştirme olasılığını +dikkate almaz. Ayrıca uygulamanıza özgü teknik ayrıntıları da hesaba katmaz. +Bu unsurlardan herhangi biri, bir saldırganın belirli bir zafiyeti bulma ve +istismar etme olasılığını önemli ölçüde etkileyebilir. Bu derecelendirme, +kuruluşunuzun maruz kalacağı gerçek iş etkisini de değerlendirmez. +Kuruluşunuz; kurum kültürü, faaliyet gösterdiği sektör ve tabi olduğu +düzenleyici ortamı göz önünde bulundurarak uygulamalardan ve API'lerden +kaynaklanan güvenlik risklerinin ne kadarını kabul edebileceğine kendisi +karar vermelidir. OWASP API Security Top 10'un amacı, bu risk analizini +kuruluşunuz adına yapmak değildir. + +## Kaynaklar + +### OWASP + +* [OWASP Risk Değerlendirme Metodolojisi][1] +* [Tehdit/Risk Modellemesi Hakkında Makale][2] + +### Harici Kaynaklar + +* [ISO 31000: Risk Yönetimi Standardı][3] +* [ISO 27001: BGYS][4] +* [NIST Siber Güvenlik Çerçevesi (ABD)][5] +* [ASD Stratejik Azaltım Önlemleri (AU)][6] +* [NIST CVSS 3.0][7] +* [Microsoft Tehdit Modelleme Aracı][8] + +[1]: https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology +[2]: https://www.owasp.org/index.php/Threat_Risk_Modeling +[3]: https://www.iso.org/iso-31000-risk-management.html +[4]: https://www.iso.org/isoiec-27001-information-security.html +[5]: https://www.nist.gov/cyberframework +[6]: https://www.asd.gov.au/infosec/mitigationstrategies.htm +[7]: https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator +[8]: https://www.microsoft.com/en-us/download/details.aspx?id=49168 diff --git a/editions/2019/tr/0x11-t10.md b/editions/2019/tr/0x11-t10.md new file mode 100644 index 000000000..65fb88815 --- /dev/null +++ b/editions/2019/tr/0x11-t10.md @@ -0,0 +1,14 @@ +# OWASP En Kritik 10 API Güvenliği Riski – 2019 + +| Risk | Açıklama | +| ---- | ----------- | +| API1:2019 - Nesne Düzeyinde Yetkilendirme Eksikliği | API'ler genellikle nesne tanımlayıcılarını işleyen uç noktaları dışarıya açar. Bu durum, nesne düzeyinde erişim kontrolü açısından geniş bir saldırı yüzeyi oluşturur. Kullanıcıdan alınan bir girdiyle veri kaynağına erişen her fonksiyonda nesne düzeyinde yetkilendirme kontrolleri değerlendirilmelidir. | +| API2:2019 - Kullanıcı Kimlik Doğrulama Eksikliği | Kimlik doğrulama mekanizmaları sıklıkla hatalı biçimde uygulanır. Bu durum, saldırganların kimlik doğrulama belirteçlerini ele geçirmesine veya uygulamadaki kusurları istismar ederek geçici ya da kalıcı biçimde başka kullanıcıların kimliğine bürünmesine olanak tanır. Bir sistemin istemciyi veya kullanıcıyı doğru biçimde tanımlama yeteneğinin tehlikeye atılması, API güvenliğinin tamamını olumsuz etkiler. | +| API3:2019 - Aşırı Veri İfşası | Geliştiriciler, genel amaçlı (generic) uygulamalar hedeflerken nesnelerin tüm özelliklerini, her birinin hassasiyet düzeyini ayrı ayrı değerlendirmeden dışarıya açma eğilimindedir. Verinin kullanıcıya gösterilmeden önce filtrelenmesini ise istemci tarafına bırakırlar. | +| API4:2019 - Kaynak ve Hız Sınırlaması Eksikliği | API'ler çoğu zaman istemci veya kullanıcı tarafından talep edilebilecek kaynakların boyutuna veya sayısına herhangi bir sınırlama getirmez. Bu durum yalnızca API sunucusunun performansını etkileyip Hizmet Reddine (DoS) yol açmakla kalmaz, aynı zamanda kaba kuvvet (brute force) gibi kimlik doğrulama zafiyetlerine de kapı aralar. | +| API5:2019 - Fonksiyon Düzeyinde Yetkilendirme Eksikliği | Farklı hiyerarşi, grup ve rollere sahip karmaşık erişim kontrolü politikaları ile yönetimsel ve standart fonksiyonlar arasındaki sınırların net olmaması, yetkilendirme açıklarına yol açabilir. Saldırganlar bu açıkları istismar ederek diğer kullanıcıların kaynaklarına ve/veya yönetimsel fonksiyonlara erişebilir. | +| API6:2019 - Toplu Atama | İstemciden gelen verilerin (örn. JSON), izin verilenler listesine (whitelist) dayalı uygun bir özellik filtrelemesi yapılmadan doğrudan veri modellerine bağlanması genellikle Toplu Atamaya (Mass Assignment) yol açar. Saldırganlar; nesne özelliklerini tahmin ederek, diğer API uç noktalarını inceleyerek, dokümantasyonu okuyarak veya istek gövdesine ek nesne özellikleri ekleyerek, erişmemesi gereken nesne özelliklerini değiştirebilir. | +| API7:2019 - Hatalı Güvenlik Yapılandırması | Hatalı güvenlik yapılandırması genellikle güvensiz varsayılan ayarlardan, eksik veya duruma özel (ad-hoc) yapılandırmalardan, açık durumdaki bulut depolama alanlarından, hatalı yapılandırılmış HTTP başlıklarından, gereksiz HTTP metotlarından, aşırı izin verici Cross-Origin Resource Sharing (CORS) ayarlarından ve hassas bilgiler içeren ayrıntılı hata mesajlarından kaynaklanır. | +| API8:2019 - Enjeksiyon | SQL, NoSQL, Komut Enjeksiyonu gibi enjeksiyon açıkları; güvenilmeyen verinin bir komut veya sorgunun parçası olarak bir yorumlayıcıya (interpreter) gönderilmesi durumunda ortaya çıkar. Saldırganın kötü amaçlı verisi, yorumlayıcıyı amaçlanmayan komutları çalıştırmaya veya yetkisiz biçimde veriye erişmeye yönlendirebilir. | +| API9:2019 - Hatalı Varlık Yönetimi | API'ler, geleneksel web uygulamalarına kıyasla daha fazla uç noktayı dışarıya açma eğilimindedir. Bu nedenle doğru ve güncel dokümantasyon büyük önem taşır. Kullanımdan kaldırılmış API sürümleri ve dışarıya açık hata ayıklama uç noktaları gibi riskleri azaltmak için sunucuların ve yayındaki API sürümlerinin eksiksiz biçimde envantere alınması gerekir. | +| API10:2019 - Yetersiz Loglama ve İzleme | Yetersiz loglama ve izleme, olay müdahalesiyle eksik veya etkisiz bir entegrasyonla birleştiğinde saldırganların sistemlere daha fazla saldırmasına, kalıcılık sağlamasına ve verileri değiştirmek, sızdırmak veya yok etmek amacıyla başka sistemlere sıçramasına olanak tanır. Çoğu ihlal araştırması, bir ihlalin tespit edilme süresinin 200 günün üzerinde olduğunu ve genellikle iç süreçler veya izleme mekanizmaları yerine dış taraflarca tespit edildiğini göstermektedir. | diff --git a/editions/2019/tr/0xa1-broken-object-level-authorization.md b/editions/2019/tr/0xa1-broken-object-level-authorization.md new file mode 100644 index 000000000..f0c352a56 --- /dev/null +++ b/editions/2019/tr/0xa1-broken-object-level-authorization.md @@ -0,0 +1,70 @@ +# API1:2019 Nesne Düzeyinde Yetkilendirme Eksikliği + +| Tehdit aktörleri / Saldırı vektörleri | Güvenlik Zayıflığı | Etkiler | +| - | - | - | +| API'ye Özgü : İstismar Edilebilirlik **3** | Yaygınlık **3** : Tespit Edilebilirlik **2** | Teknik **3** : Kuruluşa özgü | +| Saldırganlar, istekte gönderilen bir nesnenin ID'sini değiştirerek nesne düzeyinde yetkilendirmeye karşı savunmasız API uç noktalarını istismar edebilir. Bu durum, hassas verilere yetkisiz erişime yol açabilir. Bu sorun API tabanlı uygulamalarda son derece yaygındır çünkü sunucu bileşeni genellikle istemcinin durumunu tam olarak takip etmez; bunun yerine, hangi nesnelere erişileceğine karar vermek için istemciden gönderilen nesne ID'leri gibi parametrelere daha çok güvenir. | Bu, API'lere yönelik en yaygın ve en etkili saldırı türü olmuştur. Modern uygulamalardaki yetkilendirme ve erişim kontrolü mekanizmaları karmaşık ve yaygındır. Uygulama, yetkilendirme kontrolleri için uygun bir altyapı uygulasa bile geliştiriciler, hassas bir nesneye erişmeden önce bu kontrolleri kullanmayı unutabilir. Erişim kontrolü eksikliklerinin tespiti, genellikle otomatik statik veya dinamik testlere uygun değildir. | Yetkisiz erişim; verilerin yetkisiz taraflara açıklanmasına, kaybolmasına veya değiştirilmesine yol açabilir. Nesnelere yetkisiz erişim, bir hesabın tamamen ele geçirilmesiyle de sonuçlanabilir. | + +## API Bu Zafiyete Açık mı? + +Nesne düzeyinde yetkilendirme, bir kullanıcının yalnızca erişim izni olması +gereken nesnelere erişebildiğini doğrulamak amacıyla genellikle kod +düzeyinde uygulanan bir erişim kontrolü mekanizmasıdır. + +Bir nesnenin ID'sini alan ve bu nesne üzerinde herhangi bir işlem +gerçekleştiren her API uç noktası, nesne düzeyinde yetkilendirme kontrolleri +uygulamalıdır. Bu kontroller, oturum açmış kullanıcının istenen nesne +üzerinde talep edilen işlemi gerçekleştirme yetkisine sahip olduğunu +doğrulamalıdır. + +Bu mekanizmadaki eksiklikler genellikle tüm verilerin yetkisiz biçimde +açıklanmasına, değiştirilmesine veya yok edilmesine yol açar. + +## Örnek Saldırı Senaryoları + +### Senaryo #1 + +Çevrimiçi mağazalara hizmet veren bir e-ticaret platformu, barındırdığı +mağazaların gelir grafiklerini gösteren bir listeleme sayfası sunar. +Tarayıcı isteklerini inceleyen bir saldırgan, bu grafiklerin veri kaynağı +olarak kullanılan API uç noktalarını ve bunların +`/shops/{shopName}/revenue_data.json` kalıbını tespit edebilir. Saldırgan, +başka bir API uç noktasını kullanarak barındırılan tüm mağazaların adlarının +listesini elde edebilir. Listedeki adları kullanarak URL'deki `{shopName}` +değerini değiştiren basit bir betikle saldırgan, binlerce e-ticaret +mağazasının satış verilerine erişim sağlar. + +### Senaryo #2 + +Giyilebilir bir cihazın ağ trafiği izlenirken, bir saldırganın dikkatini bir +HTTP `PATCH` isteği çeker; çünkü istekte özel bir `X-User-Id: 54796` başlığı +yer almaktadır. Saldırgan, `X-User-Id` değerini `54795` ile değiştirdiğinde +başarılı bir HTTP yanıtı alır ve böylece başka kullanıcıların hesap +verilerini değiştirebilir. + +## Nasıl Önlenir? + +* Kullanıcı politikalarına ve hiyerarşisine dayanan uygun bir yetkilendirme + mekanizması uygulayın. +* İstemciden alınan bir girdiyle veritabanındaki bir kayda erişen her + fonksiyonda, oturum açmış kullanıcının istenen işlemi söz konusu kayıt + üzerinde gerçekleştirme yetkisine sahip olup olmadığını kontrol eden bir + yetkilendirme mekanizması kullanın. +* Kayıtların ID'leri için rastgele ve tahmin edilmesi zor değerler olan + GUID'leri tercih edin. +* Yetkilendirme mekanizmasındaki zafiyetleri tespit edecek testler yazın. + Bu testlerin başarısız olmasına neden olan değişiklikleri canlı ortama + dağıtmayın. + +## Kaynaklar + +### Harici Kaynaklar + +* [CWE-284: Hatalı Erişim Kontrolü][1] +* [CWE-285: Hatalı Yetkilendirme][2] +* [CWE-639: Kullanıcı Tarafından Denetlenen Anahtar Aracılığıyla + Yetkilendirmeyi Aşma][3] + +[1]: https://cwe.mitre.org/data/definitions/284.html +[2]: https://cwe.mitre.org/data/definitions/285.html +[3]: https://cwe.mitre.org/data/definitions/639.html diff --git a/editions/2019/tr/0xa2-broken-user-authentication.md b/editions/2019/tr/0xa2-broken-user-authentication.md new file mode 100644 index 000000000..6d1c357fc --- /dev/null +++ b/editions/2019/tr/0xa2-broken-user-authentication.md @@ -0,0 +1,94 @@ +# API2:2019 Kullanıcı Kimlik Doğrulama Eksikliği + +| Tehdit aktörleri / Saldırı vektörleri | Güvenlik Zayıflığı | Etkiler | +| - | - | - | +| API'ye Özgü : İstismar Edilebilirlik **3** | Yaygınlık **2** : Tespit Edilebilirlik **2** | Teknik **3** : Kuruluşa özgü | +| API'lerde kimlik doğrulama karmaşık ve kafa karıştırıcı bir mekanizmadır. Yazılım ve güvenlik mühendisleri, kimlik doğrulamanın sınırlarının ne olduğu ve nasıl doğru uygulanacağı konusunda yanlış varsayımlara sahip olabilir. Ayrıca kimlik doğrulama mekanizması herkese açık olduğu için saldırganlar açısından kolay bir hedeftir. Bu iki unsur, kimlik doğrulama bileşenini birçok istismara potansiyel olarak açık hâle getirir. | İki alt sorun vardır: 1. Koruma mekanizmalarının eksikliği: kimlik doğrulamadan sorumlu API uç noktaları normal uç noktalardan farklı ele alınmalı ve ek koruma katmanları uygulamalıdır. 2. Mekanizmanın hatalı uygulanması: mekanizma, saldırı vektörleri göz önünde bulundurulmadan kullanılır/uygulanır ya da yanlış kullanım senaryosuna sahiptir (örn. IoT istemcileri için tasarlanmış bir kimlik doğrulama mekanizması, web uygulamaları için doğru seçim olmayabilir). | Saldırganlar, sistemdeki diğer kullanıcıların hesaplarının kontrolünü ele geçirebilir, kişisel verilerini okuyabilir ve para transferi ya da kişisel mesaj gönderme gibi hassas işlemleri onlar adına gerçekleştirebilir. | + +## API Bu Zafiyete Açık mı? + +Kimlik doğrulama uç noktaları ve akışları korunması gereken varlıklardır. +"Şifremi unuttum / şifre sıfırlama" işlevi de kimlik doğrulama +mekanizmalarıyla aynı şekilde ele alınmalıdır. + +Bir API aşağıdaki durumlarda zafiyete açıktır: + +* Saldırganın geçerli kullanıcı adı ve şifre listesine sahip olduğu + [kimlik bilgisi doldurma (credential stuffing)][1] saldırılarına izin + veriyorsa. +* Captcha/hesap kilitleme mekanizması sunmadan aynı kullanıcı hesabına + yönelik kaba kuvvet saldırılarına izin veriyorsa. +* Zayıf şifrelere izin veriyorsa. +* Kimlik doğrulama belirteçleri ve şifreler gibi hassas kimlik doğrulama + bilgilerini URL üzerinden gönderiyorsa. +* Belirteçlerin özgünlüğünü doğrulamıyorsa. +* İmzasız veya zayıf imzalanmış JWT belirteçlerini (`"alg":"none"`) kabul + ediyorsa/son kullanma tarihlerini doğrulamıyorsa. +* Düz metin, şifrelenmemiş veya zayıf biçimde hash'lenmiş şifreler + kullanıyorsa. +* Zayıf şifreleme anahtarları kullanıyorsa. + +## Örnek Saldırı Senaryoları + +### Senaryo #1 + +[Kimlik bilgisi doldurma][1] ([bilinen kullanıcı adı/şifre listeleri][2] +kullanılarak) yaygın bir saldırı türüdür. Bir uygulama otomatik tehdit +tespiti veya kimlik bilgisi doldurma koruması uygulamıyorsa, uygulama; +kimlik bilgilerinin geçerli olup olmadığını belirlemek için bir şifre +kâhini (oracle) olarak kullanılabilir. + +### Senaryo #2 + +Bir saldırgan, `/api/system/verification-codes` adresine bir POST isteği +gönderip istek gövdesinde kullanıcı adını belirterek şifre kurtarma +sürecini başlatır. Ardından kurbanın telefonuna 6 haneli bir SMS belirteci +gönderilir. API bir istek sınırlandırma politikası uygulamadığından, +saldırgan `/api/system/verification-codes/{smsToken}` uç noktasına karşı +çok iş parçacıklı (multi-threaded) bir betikle tüm olası kombinasyonları +deneyerek doğru belirteci birkaç dakika içinde bulabilir. + +## Nasıl Önlenir? + +* API'ye kimlik doğrulamanın tüm olası akışlarını bildiğinizden emin olun + (mobil/web/tek tıkla kimlik doğrulama uygulayan derin bağlantılar vb.). +* Mühendislerinize hangi akışları gözden kaçırdığınızı sorun. +* Kimlik doğrulama mekanizmalarınız hakkında bilgi edinin. Bunların ne + olduğunu ve nasıl kullanıldığını anladığınızdan emin olun. OAuth bir + kimlik doğrulama yöntemi değildir; API anahtarları da değildir. +* Kimlik doğrulama, belirteç üretimi veya şifre saklama konusunda + tekerleği yeniden icat etmeyin. Standartları kullanın. +* Kimlik bilgisi kurtarma/şifremi unuttum uç noktaları; kaba kuvvet, istek + sınırlandırma ve kilitleme korumaları açısından giriş uç noktalarıyla + aynı şekilde ele alınmalıdır. +* [OWASP Kimlik Doğrulama Hızlı Başvuru Rehberi'ni][3] kullanın. +* Mümkün olduğunda çok faktörlü kimlik doğrulama uygulayın. +* Kimlik doğrulama uç noktalarınıza yönelik kimlik bilgisi doldurma, + sözlük saldırıları ve kaba kuvvet saldırılarını azaltmak için kaba + kuvvet karşıtı mekanizmalar uygulayın. Bu mekanizma, API'nizdeki olağan + istek sınırlandırma mekanizmasından daha sıkı olmalıdır. +* Belirli kullanıcılara yönelik kaba kuvvet saldırılarını önlemek için + [hesap kilitleme][4]/captcha mekanizması uygulayın. Zayıf şifre + kontrolleri uygulayın. +* API anahtarları kullanıcı kimlik doğrulaması için değil, [istemci + uygulaması/proje kimlik doğrulaması][5] için kullanılmalıdır. + +## Kaynaklar + +### OWASP + +* [OWASP Anahtar Yönetimi Hızlı Başvuru Rehberi][6] +* [OWASP Kimlik Doğrulama Hızlı Başvuru Rehberi][3] +* [Kimlik Bilgisi Doldurma (Credential Stuffing)][1] + +### Harici Kaynaklar + +* [CWE-798: Sabit Kodlanmış Kimlik Bilgilerinin Kullanımı][7] + +[1]: https://www.owasp.org/index.php/Credential_stuffing +[2]: https://github.com/danielmiessler/SecLists +[3]: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html +[4]: https://www.owasp.org/index.php/Testing_for_Weak_lock_out_mechanism_(OTG-AUTHN-003) +[5]: https://cloud.google.com/endpoints/docs/openapi/when-why-api-key +[6]: https://www.owasp.org/index.php/Key_Management_Cheat_Sheet +[7]: https://cwe.mitre.org/data/definitions/798.html diff --git a/editions/2019/tr/0xa3-excessive-data-exposure.md b/editions/2019/tr/0xa3-excessive-data-exposure.md new file mode 100644 index 000000000..8277109ee --- /dev/null +++ b/editions/2019/tr/0xa3-excessive-data-exposure.md @@ -0,0 +1,63 @@ +# API3:2019 Aşırı Veri İfşası + +| Tehdit aktörleri / Saldırı vektörleri | Güvenlik Zayıflığı | Etkiler | +| - | - | - | +| API'ye Özgü : İstismar Edilebilirlik **3** | Yaygınlık **2** : Tespit Edilebilirlik **2** | Teknik **2** : Kuruluşa özgü | +| Aşırı Veri İfşasının istismarı basittir; genellikle trafiği dinleyip API yanıtlarını analiz ederek kullanıcıya döndürülmemesi gereken hassas veri ifşalarını aramak yoluyla gerçekleştirilir. | API'ler, veri filtrelemeyi istemcilerin yapmasına güvenir. API'ler veri kaynağı olarak kullanıldığından, geliştiriciler bazen dışarıya açılan verinin hassasiyetini düşünmeden onları genel (generic) bir biçimde uygulamaya çalışır. Otomatik araçlar genellikle bu tür bir zafiyeti tespit edemez; çünkü API'den dönen meşru veriyle döndürülmemesi gereken hassas veriyi ayırt etmek, uygulamanın derinlemesine anlaşılmasını gerektirir. | Aşırı Veri İfşası genellikle hassas verilerin ifşa olmasına yol açar. | + +## API Bu Zafiyete Açık mı? + +API, tasarımı gereği istemciye hassas veri döndürür. Bu veri genellikle +kullanıcıya sunulmadan önce istemci tarafında filtrelenir. Bir saldırgan, +trafiği kolayca dinleyerek bu hassas veriyi görebilir. + +## Örnek Saldırı Senaryoları + +### Senaryo #1 + +Mobil ekip, yorum meta verilerini görüntülemek için makaleler görünümünde +`/api/articles/{articleId}/comments/{commentId}` uç noktasını kullanır. +Mobil uygulama trafiğini dinleyen bir saldırgan, yorumun yazarına ait başka +hassas verilerin de döndürüldüğünü keşfeder. Uç nokta, nesneyi +serileştirmek için PII içeren `User` modeli üzerinde genel bir `toJSON()` +metodu kullanmaktadır. + +### Senaryo #2 + +IoT tabanlı bir gözetim sistemi, yöneticilerin farklı izinlere sahip +kullanıcılar oluşturmasına olanak tanır. Bir yönetici, sahadaki yalnızca +belirli binalara erişimi olması gereken yeni bir güvenlik görevlisi için +bir kullanıcı hesabı oluşturur. Güvenlik görevlisi mobil uygulamasını +kullandığında, mevcut kameralar hakkında veri almak ve bunları panoda +göstermek için `/api/sites/111/cameras` adresine bir API çağrısı +tetiklenir. Yanıt, kameralar hakkındaki ayrıntıları şu formatta içeren bir +liste döndürür: `{"id":"xxx","live_access_token":"xxxx-bbbbb","building_id":"yyy"}`. +İstemci arayüzü yalnızca güvenlik görevlisinin erişimi olması gereken +kameraları gösterirken, gerçek API yanıtı sahadaki tüm kameraların tam +listesini içerir. + +## Nasıl Önlenir? + +* Hassas veriyi filtrelemek için asla istemci tarafına güvenmeyin. +* API'den dönen yanıtları, yalnızca meşru veri içerdiklerinden emin olmak + için gözden geçirin. +* Backend mühendisleri, yeni bir API uç noktasını dışarıya açmadan önce + her zaman "verinin tüketicisi kim?" diye sormalıdır. +* `to_json()` ve `to_string()` gibi genel metotları kullanmaktan kaçının. + Bunun yerine, gerçekten döndürmek istediğiniz belirli özellikleri tek + tek seçin. +* Uygulamanızın sakladığı ve işlediği hassas ve kişisel olarak + tanımlanabilir bilgileri (PII) sınıflandırın; bu tür bilgileri döndüren + tüm API çağrılarını, bir güvenlik sorunu oluşturup oluşturmadığını + görmek için gözden geçirin. +* Ek bir güvenlik katmanı olarak şemaya dayalı bir yanıt doğrulama + mekanizması uygulayın. Bu mekanizmanın bir parçası olarak, hatalar dâhil + tüm API metotlarının döndürdüğü veriyi tanımlayın ve zorunlu kılın. + +## Kaynaklar + +### Harici Kaynaklar + +* [CWE-213: Kasıtlı Bilgi İfşası][1] + +[1]: https://cwe.mitre.org/data/definitions/213.html diff --git a/editions/2019/tr/0xa4-lack-of-resources-and-rate-limiting.md b/editions/2019/tr/0xa4-lack-of-resources-and-rate-limiting.md new file mode 100644 index 000000000..3148af535 --- /dev/null +++ b/editions/2019/tr/0xa4-lack-of-resources-and-rate-limiting.md @@ -0,0 +1,89 @@ +# API4:2019 Kaynak ve Hız Sınırlaması Eksikliği + +| Tehdit aktörleri / Saldırı vektörleri | Güvenlik Zayıflığı | Etkiler | +| - | - | - | +| API'ye Özgü : İstismar Edilebilirlik **2** | Yaygınlık **3** : Tespit Edilebilirlik **3** | Teknik **2** : Kuruluşa özgü | +| İstismar için basit API istekleri yeterlidir. Kimlik doğrulamaya gerek yoktur. Tek bir yerel bilgisayardan veya bulut bilişim kaynakları kullanılarak birden fazla eşzamanlı istek gönderilebilir. | İstek sınırlandırması uygulamayan veya sınırların doğru ayarlanmadığı API'lere sıkça rastlanır. | İstismar, API'yi yanıt vermez hâle getiren hatta tamamen kullanılamaz kılan bir Hizmet Reddine (DoS) yol açabilir. | + +## API Bu Zafiyete Açık mı? + +API istekleri; ağ, CPU, bellek ve depolama gibi kaynakları tüketir. Bir +isteği karşılamak için gereken kaynak miktarı büyük ölçüde kullanıcı +girdisine ve uç noktanın iş mantığına bağlıdır. Ayrıca, birden fazla API +istemcisinden gelen isteklerin kaynaklar için birbiriyle yarıştığını da +göz önünde bulundurun. Aşağıdaki sınırlardan en az birinin eksik olması +veya uygunsuz biçimde ayarlanması (örn. çok düşük/yüksek) durumunda API +zafiyete açıktır: + +* Yürütme zaman aşımları (execution timeouts) +* Tahsis edilebilecek maksimum bellek +* Dosya tanımlayıcısı (file descriptor) sayısı +* İşlem (process) sayısı +* İstek gövdesi boyutu (örn. dosya yüklemeleri) +* İstemci/kaynak başına istek sayısı +* Tek bir istek yanıtında döndürülecek kayıt sayısı + +## Örnek Saldırı Senaryoları + +### Senaryo #1 + +Bir saldırgan, `/api/v1/images` adresine bir POST isteği göndererek büyük +boyutlu bir görsel yükler. Yükleme tamamlandığında API, farklı boyutlarda +birden fazla küçük resim (thumbnail) oluşturur. Yüklenen görselin boyutu +nedeniyle, küçük resimlerin oluşturulması sırasında kullanılabilir bellek +tükenir ve API yanıt vermez hâle gelir. + +### Senaryo #2 + +Bir uygulamada, kullanıcı listesini sayfa başına `200` kullanıcıyla +sınırlayan bir arayüz bulunmaktadır. Kullanıcı listesi sunucudan şu +sorguyla alınır: `/api/users?page=1&size=200`. Bir saldırgan, `size` +parametresini `200000` olarak değiştirerek veritabanında performans +sorunlarına yol açar. Bu esnada API yanıt vermez hâle gelir ve bu +istemciden veya başka herhangi bir istemciden gelen istekleri +işleyemez hâle gelir (yani DoS). + +Aynı senaryo, Integer Overflow veya Buffer Overflow hatalarını tetiklemek +için de kullanılabilir. + +## Nasıl Önlenir? + +* Docker; [bellek][1], [CPU][2], [yeniden başlatma sayısı][3] ve [dosya + tanımlayıcıları ile işlem sayısını][4] sınırlamayı kolaylaştırır. +* İstemcinin API'yi belirli bir zaman aralığında ne sıklıkla + çağırabileceğine dair bir sınır uygulayın. +* Sınır aşıldığında istemciye, sınır sayısını ve sınırın ne zaman + sıfırlanacağını bildirerek bilgi verin. +* Sorgu dizesi ve istek gövdesi parametreleri için, özellikle yanıtta + döndürülecek kayıt sayısını kontrol eden parametre için uygun sunucu + taraflı doğrulama ekleyin. +* Dizelerin maksimum uzunluğu ve dizilerdeki maksimum eleman sayısı gibi, + tüm gelen parametreler ve veri yükleri için maksimum veri boyutunu + tanımlayın ve zorunlu kılın. + +## Kaynaklar + +### OWASP + +* [Kaba Kuvvet Saldırılarını Engelleme][5] +* [Docker Hızlı Başvuru Rehberi - Kaynakları Sınırlama (bellek, CPU, + dosya tanımlayıcıları, işlemler, yeniden başlatmalar)][6] +* [REST Değerlendirme Hızlı Başvuru Rehberi][7] + +### Harici Kaynaklar + +* [CWE-307: Aşırı Kimlik Doğrulama Denemelerinin Yetersiz Kısıtlanması][8] +* [CWE-770: Sınır veya Kısıtlama Olmadan Kaynak Tahsisi][9] +* "_Rate Limiting (Throttling)_" - [Mikroservis Tabanlı Uygulama + Sistemleri için Güvenlik Stratejileri][10], NIST + +[1]: https://docs.docker.com/config/containers/resource_constraints/#memory +[2]: https://docs.docker.com/config/containers/resource_constraints/#cpu +[3]: https://docs.docker.com/engine/reference/commandline/run/#restart-policies---restart +[4]: https://docs.docker.com/engine/reference/commandline/run/#set-ulimits-in-container---ulimit +[5]: https://www.owasp.org/index.php/Blocking_Brute_Force_Attacks +[6]: https://github.com/OWASP/CheatSheetSeries/blob/3a8134d792528a775142471b1cb14433b4fda3fb/cheatsheets/Docker_Security_Cheat_Sheet.md#rule-7---limit-resources-memory-cpu-file-descriptors-processes-restarts +[7]: https://github.com/OWASP/CheatSheetSeries/blob/3a8134d792528a775142471b1cb14433b4fda3fb/cheatsheets/REST_Assessment_Cheat_Sheet.md +[8]: https://cwe.mitre.org/data/definitions/307.html +[9]: https://cwe.mitre.org/data/definitions/770.html +[10]: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-204-draft.pdf diff --git a/editions/2019/tr/0xa5-broken-function-level-authorization.md b/editions/2019/tr/0xa5-broken-function-level-authorization.md new file mode 100644 index 000000000..3946d4101 --- /dev/null +++ b/editions/2019/tr/0xa5-broken-function-level-authorization.md @@ -0,0 +1,99 @@ +# API5:2019 Fonksiyon Düzeyinde Yetkilendirme Eksikliği + +| Tehdit aktörleri / Saldırı vektörleri | Güvenlik Zayıflığı | Etkiler | +| - | - | - | +| API'ye Özgü : İstismar Edilebilirlik **3** | Yaygınlık **2** : Tespit Edilebilirlik **1** | Teknik **2** : Kuruluşa özgü | +| İstismar için saldırganın, erişim yetkisi olmaması gereken bir API uç noktasına meşru API çağrıları göndermesi yeterlidir. Bu uç noktalar anonim kullanıcılara veya ayrıcalıksız normal kullanıcılara açık olabilir. API'ler daha yapılandırılmış olduğundan ve belirli fonksiyonlara erişim yöntemi daha öngörülebilir olduğundan (örn. HTTP yöntemini `GET`'ten `PUT`'a değiştirmek veya URL'deki "users" ifadesini "admins" ile değiştirmek), bu tür açıkları API'lerde tespit etmek daha kolaydır. | Bir fonksiyon veya kaynak için yetkilendirme kontrolleri genellikle yapılandırma üzerinden, bazen de kod düzeyinde yönetilir. Modern uygulamalar birçok rol veya grup türü ve karmaşık kullanıcı hiyerarşisi (örn. alt kullanıcılar, birden fazla role sahip kullanıcılar) içerebildiğinden, uygun kontrollerin uygulanması kafa karıştırıcı bir görev olabilir. | Bu tür açıklar, saldırganların yetkisiz işlevlere erişmesine olanak tanır. Yönetimsel fonksiyonlar bu tür saldırılar için başlıca hedeflerdir. | + +## API Bu Zafiyete Açık mı? + +Fonksiyon düzeyinde yetkilendirme eksikliği sorunlarını bulmanın en iyi +yolu, uygulamadaki kullanıcı hiyerarşisini, farklı rolleri veya grupları +göz önünde bulundurarak yetkilendirme mekanizmasının derinlemesine +analizini yapmak ve şu soruları sormaktır: + +* Normal bir kullanıcı yönetimsel uç noktalara erişebiliyor mu? +* Bir kullanıcı, yalnızca HTTP yöntemini değiştirerek (örn. `GET`'ten + `DELETE`'e) erişim yetkisi olmaması gereken hassas işlemleri (örn. + oluşturma, değiştirme veya silme) gerçekleştirebiliyor mu? +* X grubundaki bir kullanıcı, yalnızca uç nokta URL'sini ve + parametrelerini tahmin ederek (örn. `/api/v1/users/export_all`) + yalnızca Y grubundaki kullanıcılara açık olması gereken bir fonksiyona + erişebiliyor mu? + +Bir API uç noktasının yalnızca URL yoluna bakarak normal mi yoksa +yönetimsel mi olduğunu varsaymayın. + +Geliştiriciler yönetimsel uç noktaların çoğunu `api/admins` gibi belirli +bir göreli yol altında açığa çıkarmayı tercih etse de, bu yönetimsel uç +noktaların `api/users` gibi normal uç noktalarla birlikte başka göreli +yollar altında bulunması da oldukça yaygındır. + +## Örnek Saldırı Senaryoları + +### Senaryo #1 + +Yalnızca davet edilen kullanıcıların katılabildiği bir uygulamanın kayıt +süreci sırasında, mobil uygulama `GET /api/invites/{invite_guid}` şeklinde +bir API çağrısı tetikler. Yanıt, davetin ayrıntılarını, kullanıcının +rolünü ve kullanıcının e-postasını içeren bir JSON içerir. + +Bir saldırgan isteği kopyalar ve HTTP yöntemi ile uç noktayı `POST +/api/invites/new` olarak değiştirir. Bu uç noktaya yalnızca yöneticiler +tarafından yönetici konsolu üzerinden erişilmelidir; ancak uç nokta +fonksiyon düzeyinde yetkilendirme kontrolleri uygulamamaktadır. + +Saldırgan bu açığı istismar ederek kendisine yönetici hesabı oluşturacak +bir davet gönderir: + +``` +POST /api/invites/new + +{"email":"hugo@malicious.com","role":"admin"} +``` + +### Senaryo #2 + +Bir API, yalnızca yöneticilere açık olması gereken bir uç nokta içerir: +`GET /api/admin/v1/users/all`. Bu uç nokta, uygulamanın tüm +kullanıcılarının bilgilerini döndürür ve fonksiyon düzeyinde +yetkilendirme kontrolleri uygulamaz. API yapısını öğrenen bir saldırgan, +bilinçli bir tahminde bulunarak bu uç noktaya erişmeyi başarır ve bu da +uygulama kullanıcılarının hassas bilgilerinin ifşa olmasına yol açar. + +## Nasıl Önlenir? + +Uygulamanız, tüm iş fonksiyonlarınızdan çağrılan tutarlı ve analiz +edilmesi kolay bir yetkilendirme modülüne sahip olmalıdır. Bu tür bir +koruma çoğunlukla, uygulama kodunun dışındaki bir veya daha fazla bileşen +tarafından sağlanır. + +* Uygulama mekanizması(ları), varsayılan olarak tüm erişimi reddetmeli ve + her fonksiyona erişim için belirli rollere açık izin verilmesini + gerektirmelidir. +* Uygulamanın iş mantığını ve grup hiyerarşisini göz önünde bulundurarak + API uç noktalarınızı fonksiyon düzeyinde yetkilendirme açıkları + açısından gözden geçirin. +* Tüm yönetimsel denetleyicilerinizin, kullanıcının grubuna/rolüne dayalı + yetkilendirme kontrolleri uygulayan soyut bir yönetimsel + denetleyiciden türediğinden emin olun. +* Normal bir denetleyici içindeki yönetimsel fonksiyonların, kullanıcının + grubuna ve rolüne dayalı yetkilendirme kontrolleri uyguladığından emin + olun. + +## Kaynaklar + +### OWASP + +* [Forced Browsing Hakkında OWASP Makalesi][1] +* [OWASP Top 10 2013-A7-Eksik Fonksiyon Düzeyinde Erişim Kontrolü][2] +* [OWASP Geliştirme Rehberi: Yetkilendirme Bölümü][3] + +### Harici Kaynaklar + +* [CWE-285: Hatalı Yetkilendirme][4] + +[1]: https://www.owasp.org/index.php/Forced_browsing +[2]: https://www.owasp.org/index.php/Top_10_2013-A7-Missing_Function_Level_Access_Control +[3]: https://www.owasp.org/index.php/Category:Access_Control +[4]: https://cwe.mitre.org/data/definitions/285.html diff --git a/editions/2019/tr/0xa6-mass-assignment.md b/editions/2019/tr/0xa6-mass-assignment.md new file mode 100644 index 000000000..b9cd20000 --- /dev/null +++ b/editions/2019/tr/0xa6-mass-assignment.md @@ -0,0 +1,93 @@ +# API6:2019 Toplu Atama + +| Tehdit aktörleri / Saldırı vektörleri | Güvenlik Zayıflığı | Etkiler | +| - | - | - | +| API'ye Özgü : İstismar Edilebilirlik **2** | Yaygınlık **2** : Tespit Edilebilirlik **2** | Teknik **2** : Kuruluşa özgü | +| İstismar genellikle iş mantığının, nesneler arası ilişkilerin ve API yapısının anlaşılmasını gerektirir. Toplu atamanın istismarı API'lerde daha kolaydır; çünkü API'ler tasarımı gereği uygulamanın alttaki gerçekleştirimini, özellik adlarıyla birlikte dışarıya açar. | Modern framework'ler, geliştiricileri istemciden gelen girdiyi otomatik olarak kod değişkenlerine ve iç nesnelere bağlayan fonksiyonlar kullanmaya teşvik eder. Saldırganlar bu yöntemi kullanarak, geliştiricilerin hiçbir zaman dışarıya açmayı amaçlamadığı hassas nesne özelliklerini güncelleyebilir veya üzerine yazabilir. | İstismar; yetki yükseltmeye (privilege escalation), veri bütünlüğünün bozulmasına, güvenlik mekanizmalarının atlatılmasına ve daha fazlasına yol açabilir. | + +## API Bu Zafiyete Açık mı? + +Modern uygulamalardaki nesneler birçok özellik içerebilir. Bu +özelliklerin bir kısmı istemci tarafından doğrudan güncellenebilmelidir +(örn. `user.first_name` veya `user.address`), bir kısmı ise +güncellenememelidir (örn. `user.is_vip` bayrağı). + +Bir API uç noktası, istemci parametrelerini bu özelliklerin +hassasiyetini ve açığa çıkma düzeyini göz önünde bulundurmadan otomatik +olarak iç nesne özelliklerine dönüştürüyorsa zafiyete açıktır. Bu durum, +bir saldırganın erişimi olmaması gereken nesne özelliklerini +güncellemesine olanak tanıyabilir. + +Hassas özelliklere örnekler: + +* **İzinle ilgili özellikler**: `user.is_admin`, `user.is_vip` yalnızca + yöneticiler tarafından ayarlanmalıdır. +* **Sürece bağlı özellikler**: `user.cash` yalnızca ödeme doğrulaması + sonrasında sistem tarafından ayarlanmalıdır. +* **İç özellikler**: `article.created_time` yalnızca uygulama + tarafından sistem içinde ayarlanmalıdır. + +## Örnek Saldırı Senaryoları + +### Senaryo #1 + +Bir araç paylaşım uygulaması, kullanıcıya profilinin temel bilgilerini +düzenleme seçeneği sunar. Bu süreçte, aşağıdaki meşru JSON nesnesiyle +`PUT /api/v1/users/me` adresine bir API çağrısı gönderilir: + +```json +{"user_name":"inons","age":24} +``` + +`GET /api/v1/users/me` isteği ise ek olarak bir `credit_balance` +özelliği içerir: + +```json +{"user_name":"inons","age":24,"credit_balance":10} +``` + +Saldırgan, ilk isteği aşağıdaki veri yüküyle tekrar gönderir: + +```json +{"user_name":"attacker","age":60,"credit_balance":99999} +``` + +Uç nokta toplu atamaya karşı savunmasız olduğundan, saldırgan ödeme +yapmadan kredi kazanır. + +### Senaryo #2 + +Bir video paylaşım platformu, kullanıcıların içerik yüklemesine ve +farklı formatlarda içerik indirmesine olanak tanır. API'yi inceleyen +bir saldırgan, `GET /api/v1/videos/{video_id}/meta_data` uç noktasının, +videonun özelliklerini içeren bir JSON nesnesi döndürdüğünü keşfeder. +Bu özelliklerden biri olan `"mp4_conversion_params":"-v codec h264"`, +uygulamanın videoyu dönüştürmek için bir shell komutu kullandığını +göstermektedir. + +Saldırgan ayrıca `POST /api/v1/videos/new` uç noktasının toplu atamaya +karşı savunmasız olduğunu ve istemcinin video nesnesinin herhangi bir +özelliğini ayarlamasına izin verdiğini keşfeder. Saldırgan şu kötü +amaçlı değeri ayarlar: `"mp4_conversion_params":"-v codec h264 && format C:/"`. +Bu değer, saldırgan videoyu MP4 olarak indirdiğinde bir shell komut +enjeksiyonuna yol açar. + +## Nasıl Önlenir? + +* Mümkünse, istemcinin girdisini otomatik olarak kod değişkenlerine + veya iç nesnelere bağlayan fonksiyonları kullanmaktan kaçının. +* Yalnızca istemci tarafından güncellenmesi gereken özellikleri izin + verilenler listesine (whitelist) ekleyin. +* İstemcilerin erişmemesi gereken özellikleri engellenenler listesine + (blacklist) eklemek için yerleşik özellikleri kullanın. +* Uygunsa, girdi veri yükleri için şemaları açıkça tanımlayın ve + zorunlu kılın. + +## Kaynaklar + +### Harici Kaynaklar + +* [CWE-915: Dinamik Olarak Belirlenen Nesne Özniteliklerinin Uygunsuz + Biçimde Denetlenen Değişikliği][1] + +[1]: https://cwe.mitre.org/data/definitions/915.html diff --git a/editions/2019/tr/0xa7-security-misconfiguration.md b/editions/2019/tr/0xa7-security-misconfiguration.md new file mode 100644 index 000000000..9d4c82c8c --- /dev/null +++ b/editions/2019/tr/0xa7-security-misconfiguration.md @@ -0,0 +1,113 @@ +# API7:2019 Hatalı Güvenlik Yapılandırması + +| Tehdit aktörleri / Saldırı vektörleri | Güvenlik Zayıflığı | Etkiler | +| - | - | - | +| API'ye Özgü : İstismar Edilebilirlik **3** | Yaygınlık **3** : Tespit Edilebilirlik **3** | Teknik **2** : Kuruluşa özgü | +| Saldırganlar genellikle yetkisiz erişim veya sistem hakkında bilgi elde etmek amacıyla yamalanmamış açıkları, yaygın uç noktaları veya korumasız dosya ve dizinleri bulmaya çalışır. | Hatalı güvenlik yapılandırması, ağ düzeyinden uygulama düzeyine kadar API yığınının herhangi bir katmanında ortaya çıkabilir. Gereksiz servisler veya eski seçenekler gibi hatalı yapılandırmaları tespit etmek ve istismar etmek için otomatik araçlar mevcuttur. | Hatalı güvenlik yapılandırmaları yalnızca hassas kullanıcı verilerini değil, sunucunun tamamen ele geçirilmesine yol açabilecek sistem detaylarını da açığa çıkarabilir. | + +## API Bu Zafiyete Açık mı? + +API aşağıdaki durumlarda zafiyete açık olabilir: + +* Uygulama yığınının herhangi bir bölümünde uygun güvenlik + sıkılaştırması eksikse veya bulut servislerinde yanlış + yapılandırılmış izinler varsa. +* En son güvenlik yamaları eksikse veya sistemler güncel değilse. +* Gereksiz özellikler etkinse (örn. HTTP fiilleri). +* Aktarım Katmanı Güvenliği (TLS) eksikse. +* Güvenlik yönergeleri istemcilere gönderilmiyorsa (örn. [Güvenlik + Başlıkları][1]). +* Kaynaklar Arası Kaynak Paylaşımı (CORS) politikası eksikse veya + yanlış ayarlanmışsa. +* Hata mesajları yığın izlerini (stack trace) içeriyorsa veya başka + hassas bilgiler açığa çıkıyorsa. + +## Örnek Saldırı Senaryoları + +### Senaryo #1 + +Bir saldırgan, sunucunun kök dizininde DevOps ekibinin API'ye erişmek +için kullandığı komutları içeren `.bash_history` dosyasını bulur: + +``` +$ curl -X GET 'https://api.server/endpoint/' -H 'authorization: Basic Zm9vOmJhcg==' +``` + +Saldırgan ayrıca, yalnızca DevOps ekibi tarafından kullanılan ve +dokümante edilmemiş yeni uç noktaları da API üzerinde bulabilir. + +### Senaryo #2 + +Belirli bir servisi hedeflemek için bir saldırgan, İnternet üzerinden +doğrudan erişilebilen bilgisayarları aramak amacıyla popüler bir arama +motoru kullanır. Saldırgan, varsayılan portu dinleyen, popüler bir +veritabanı yönetim sistemi çalıştıran bir sunucu bulur. Sunucu, +varsayılan olarak kimlik doğrulamanın devre dışı olduğu varsayılan +yapılandırmayı kullanmaktadır; saldırgan da PII, kişisel tercihler ve +kimlik doğrulama verileri içeren milyonlarca kayda erişim sağlar. + +### Senaryo #3 + +Bir mobil uygulamanın trafiğini inceleyen bir saldırgan, tüm HTTP +trafiğinin güvenli bir protokol (örn. TLS) üzerinden yürütülmediğini +fark eder. Saldırgan bunun özellikle profil resimlerinin indirilmesi +için geçerli olduğunu tespit eder. Kullanıcı etkileşimi ikili +(binary) olduğundan, API trafiği güvenli bir protokol üzerinden +yürütülse bile saldırgan, API yanıtlarının boyutunda bir örüntü +(pattern) bulur ve bunu kullanıcının görüntülenen içeriğe (örn. profil +resimlerine) yönelik tercihlerini takip etmek için kullanır. + +## Nasıl Önlenir? + +API yaşam döngüsü şunları içermelidir: + +* Güvenliği sıkılaştırılmış bir ortamın hızlı ve kolay biçimde devreye + alınmasını sağlayan, tekrarlanabilir bir sıkılaştırma süreci. +* API yığınının tamamındaki yapılandırmaları gözden geçirmek ve + güncellemek için bir görev. Bu gözden geçirme; orkestrasyon + dosyalarını, API bileşenlerini ve bulut servislerini (örn. S3 bucket + izinleri) kapsamalıdır. +* Statik varlıklara (örn. görseller) erişim dâhil tüm API + etkileşimleri için güvenli bir iletişim kanalı. +* Tüm ortamlarda yapılandırma ve ayarların etkinliğini sürekli olarak + değerlendiren otomatik bir süreç. + +Ayrıca: + +* İstisna izlerinin ve diğer değerli bilgilerin saldırganlara geri + gönderilmesini önlemek amacıyla, uygunsa hata yanıtları da dâhil + olmak üzere tüm API yanıt gövdesi şemalarını tanımlayın ve + uygulayın. +* API'ye yalnızca belirtilen HTTP fiilleriyle erişilebildiğinden emin + olun. Diğer tüm HTTP fiilleri devre dışı bırakılmalıdır (örn. + `HEAD`). +* Tarayıcı tabanlı istemcilerden (örn. web uygulaması ön yüzü) + erişilmesi beklenen API'ler, uygun bir Kaynaklar Arası Kaynak + Paylaşımı (CORS) politikası uygulamalıdır. + +## Kaynaklar + +### OWASP + +* [OWASP Secure Headers Project][1] +* [OWASP Test Rehberi: Yapılandırma Yönetimi][2] +* [OWASP Test Rehberi: Hata Kodları için Test][3] +* [OWASP Test Rehberi: Cross-Origin Resource Sharing Testi][9] + +### Harici Kaynaklar + +* [CWE-2: Ortama Bağlı Güvenlik Açıkları][4] +* [CWE-16: Yapılandırma][5] +* [CWE-388: Hata Yönetimi][6] +* [Genel Sunucu Güvenliği Rehberi][7], NIST +* [Let's Encrypt: ücretsiz, otomatik ve açık bir Sertifika Otoritesi][8] + +[1]: https://www.owasp.org/index.php/OWASP_Secure_Headers_Project +[2]: https://www.owasp.org/index.php/Testing_for_configuration_management +[3]: https://www.owasp.org/index.php/Testing_for_Error_Code_(OTG-ERR-001) +[4]: https://cwe.mitre.org/data/definitions/2.html +[5]: https://cwe.mitre.org/data/definitions/16.html +[6]: https://cwe.mitre.org/data/definitions/388.html +[7]: https://csrc.nist.gov/publications/detail/sp/800-123/final +[8]: https://letsencrypt.org/ +[9]: https://www.owasp.org/index.php/Test_Cross_Origin_Resource_Sharing_(OTG-CLIENT-007) diff --git a/editions/2019/tr/0xa8-injection.md b/editions/2019/tr/0xa8-injection.md new file mode 100644 index 000000000..edd65eba8 --- /dev/null +++ b/editions/2019/tr/0xa8-injection.md @@ -0,0 +1,112 @@ +# API8:2019 Enjeksiyon + +| Tehdit aktörleri / Saldırı vektörleri | Güvenlik Zayıflığı | Etkiler | +| - | - | - | +| API'ye Özgü : İstismar Edilebilirlik **3** | Yaygınlık **2** : Tespit Edilebilirlik **3** | Teknik **3** : Kuruluşa özgü | +| Saldırganlar, verinin bir yorumlayıcıya (interpreter) gönderilmesini bekleyerek mevcut olan enjeksiyon vektörleri (örn. doğrudan girdi, parametreler, entegre servisler vb.) aracılığıyla API'ye kötü amaçlı veri gönderir. | Enjeksiyon açıkları çok yaygındır ve genellikle SQL, LDAP veya NoSQL sorgularında, işletim sistemi komutlarında, XML ayrıştırıcılarında (parser) ve ORM'de bulunur. Bu açıklar kaynak kodu incelenirken kolayca tespit edilir. Saldırganlar tarayıcı (scanner) ve fuzzer araçlarını kullanabilir. | Enjeksiyon; bilgi ifşasına ve veri kaybına yol açabilir. Ayrıca Hizmet Reddine (DoS) veya sunucunun tamamen ele geçirilmesine de neden olabilir. | + +## API Bu Zafiyete Açık mı? + +API, aşağıdaki durumlarda enjeksiyon açıklarına karşı savunmasızdır: + +* İstemci tarafından sağlanan veri, API tarafından doğrulanmıyor, + filtrelenmiyor veya arındırılmıyorsa. +* İstemci tarafından sağlanan veri, doğrudan kullanılıyor veya + SQL/NoSQL/LDAP sorgularına, işletim sistemi komutlarına, XML + ayrıştırıcılarına ve Nesne İlişkisel Eşleyicisine (ORM)/Nesne + Doküman Eşleyicisine (ODM) birleştiriliyorsa. +* Harici sistemlerden (örn. entegre sistemler) gelen veri, API + tarafından doğrulanmıyor, filtrelenmiyor veya arındırılmıyorsa. + +## Örnek Saldırı Senaryoları + +### Senaryo #1 + +Bir ebeveyn kontrolü cihazının firmware'i, bir appId'nin multipart +parametre olarak gönderilmesini bekleyen `/api/CONFIG/restore` uç +noktasını sunar. Bir decompiler kullanan saldırgan, appId'nin herhangi +bir arındırma yapılmadan doğrudan bir sistem çağrısına aktarıldığını +keşfeder: + +```c +snprintf(cmd, 128, "%srestore_backup.sh /tmp/postfile.bin %s %d", + "/mnt/shares/usr/bin/scripts/", appid, 66); +system(cmd); +``` + +Aşağıdaki komut, saldırganın aynı savunmasız firmware'e sahip herhangi +bir cihazı kapatmasına olanak tanır: + +``` +$ curl -k "https://${deviceIP}:4567/api/CONFIG/restore" -F 'appid=$(/etc/pod/power_down.sh)' +``` + +### Senaryo #2 + +Rezervasyonlarla ilgili işlemler için temel CRUD işlevselliğine sahip +bir uygulamamız var. Bir saldırgan, rezervasyon silme isteğindeki +`bookingId` sorgu dizesi parametresi üzerinden NoSQL enjeksiyonunun +mümkün olabileceğini tespit etmeyi başarır. İstek şu şekilde +görünmektedir: `DELETE /api/bookings?bookingId=678`. + +API sunucusu, silme isteklerini işlemek için şu fonksiyonu kullanır: + +```javascript +router.delete('/bookings', async function (req, res, next) { + try { + const deletedBooking = await Bookings.findOneAndRemove({'_id' : req.query.bookingId}); + res.status(200); + } catch (err) { + res.status(400).json({error: 'Unexpected error occured while processing a request'}); + } +}); +``` + +Saldırgan isteği yakalar ve `bookingId` sorgu dizesi parametresini +aşağıdaki gibi değiştirir. Bu durumda saldırgan, başka bir kullanıcının +rezervasyonunu silmeyi başarır: + +``` +DELETE /api/bookings?bookingId[$ne]=678 +``` + +## Nasıl Önlenir? + +Enjeksiyonu önlemek, veriyi komutlardan ve sorgulardan ayrı tutmayı +gerektirir. + +* Veri doğrulamasını tek, güvenilir ve aktif olarak bakımı yapılan bir + kütüphane kullanarak gerçekleştirin. +* İstemci tarafından sağlanan veya entegre sistemlerden gelen tüm + veriyi doğrulayın, filtreleyin ve arındırın. +* Özel karakterler, hedef yorumlayıcıya özgü sözdizimi kullanılarak + kaçışa (escape) uğratılmalıdır. +* Parametreleştirilmiş bir arayüz sunan güvenli bir API'yi tercih + edin. +* Enjeksiyon durumunda toplu veri ifşasını önlemek için döndürülen + kayıt sayısını her zaman sınırlandırın. +* Gelen veriyi, her girdi parametresi için yalnızca geçerli değerlere + izin verecek yeterli filtrelerle doğrulayın. +* Tüm string parametreleri için veri tiplerini ve katı örüntüleri + (pattern) tanımlayın. + +## Kaynaklar + +### OWASP + +* [OWASP Enjeksiyon Açıkları][1] +* [SQL Enjeksiyonu][2] +* [Nesneler ve Dizilerle NoSQL Enjeksiyonu][3] +* [Komut Enjeksiyonu][4] + +### Harici Kaynaklar + +* [CWE-77: Komut Enjeksiyonu][5] +* [CWE-89: SQL Enjeksiyonu][6] + +[1]: https://www.owasp.org/index.php/Injection_Flaws +[2]: https://www.owasp.org/index.php/SQL_Injection +[3]: https://www.owasp.org/images/e/ed/GOD16-NOSQL.pdf +[4]: https://www.owasp.org/index.php/Command_Injection +[5]: https://cwe.mitre.org/data/definitions/77.html +[6]: https://cwe.mitre.org/data/definitions/89.html diff --git a/editions/2019/tr/0xa9-improper-assets-management.md b/editions/2019/tr/0xa9-improper-assets-management.md new file mode 100644 index 000000000..8be0e3437 --- /dev/null +++ b/editions/2019/tr/0xa9-improper-assets-management.md @@ -0,0 +1,93 @@ +# API9:2019 Hatalı Varlık Yönetimi + +| Tehdit aktörleri / Saldırı vektörleri | Güvenlik Zayıflığı | Etkiler | +| - | - | - | +| API'ye Özgü : İstismar Edilebilirlik **3** | Yaygınlık **3** : Tespit Edilebilirlik **2** | Teknik **2** : Kuruluşa özgü | +| Eski API sürümleri genellikle yamalanmamıştır ve en güncel API sürümlerini korumak için devreye alınmış olabilecek son teknoloji güvenlik mekanizmalarıyla uğraşmadan sistemleri ele geçirmenin kolay bir yoludur. | Güncel olmayan dokümantasyon, zafiyetlerin bulunmasını ve/veya düzeltilmesini zorlaştırır. Varlık envanterinin ve emeklilik stratejilerinin eksikliği, yamalanmamış sistemlerin çalışmaya devam etmesine ve hassas verilerin sızmasına yol açar. Uygulamaları kolayca dağıtılabilir ve bağımsız hâle getiren mikroservisler gibi modern yaklaşımlar nedeniyle, gereksiz yere açığa çıkmış API sunucularına sıkça rastlanır (örn. bulut bilişim, k8s). | Saldırganlar, aynı veritabanına bağlı eski ve yamalanmamış API sürümleri üzerinden hassas verilere erişim elde edebilir, hatta sunucuyu ele geçirebilir. | + +## API Bu Zafiyete Açık mı? + +API aşağıdaki durumlarda zafiyete açık olabilir: + +* Bir API sunucusunun amacı belirsizse ve aşağıdaki sorulara açık + yanıtlar yoksa: + * API hangi ortamda çalışıyor (örn. üretim, staging, test, + geliştirme)? + * API'ye ağ erişimine kimler sahip olmalı (örn. herkese açık, + dahili, iş ortakları)? + * Hangi API sürümü çalışıyor? + * API tarafından hangi veri toplanıyor ve işleniyor (örn. PII)? + * Veri akışı nasıl gerçekleşiyor? +* Dokümantasyon yoksa veya mevcut dokümantasyon güncellenmiyorsa. +* Her API sürümü için bir emeklilik planı yoksa. +* Sunucu envanteri eksik veya güncel değilse. +* Birinci veya üçüncü taraf entegre servislerin envanteri eksik veya + güncel değilse. +* Eski veya önceki API sürümleri yamalanmamış biçimde çalışıyorsa. + +## Örnek Saldırı Senaryoları + +### Senaryo #1 + +Uygulamalarını yeniden tasarladıktan sonra, yerel bir arama servisi +eski bir API sürümünü (`api.someservice.com/v1`) korumasız biçimde ve +kullanıcı veritabanına erişimi açık olarak çalışır durumda bırakır. En +son yayımlanan uygulamalardan birini hedef alan bir saldırgan, API +adresini (`api.someservice.com/v2`) bulur. URL'deki `v2` ifadesini `v1` +ile değiştiren saldırgan, eski ve korumasız API'ye erişim sağlar; bu da +100 milyondan fazla kullanıcının kişisel olarak tanımlanabilir +bilgilerinin (PII) ifşa olmasına yol açar. + +### Senaryo #2 + +Bir sosyal ağ, saldırganların şifre sıfırlama belirteçlerini tahmin +etmek için kaba kuvvet kullanmasını engelleyen bir istek sınırlandırma +mekanizması uygulamıştır. Bu mekanizma, API kodunun kendisinin bir +parçası olarak değil, istemci ile resmi API (`www.socialnetwork.com`) +arasındaki ayrı bir bileşende uygulanmıştır. Bir araştırmacı, şifre +sıfırlama mekanizması dâhil aynı API'yi çalıştıran ancak istek +sınırlandırma mekanizması bulunmayan bir beta API sunucusu +(`www.mbasic.beta.socialnetwork.com`) bulur. Araştırmacı, 6 haneli +belirteci tahmin etmek için basit bir kaba kuvvet saldırısı kullanarak +herhangi bir kullanıcının şifresini sıfırlayabilir. + +## Nasıl Önlenir? + +* Tüm API sunucularının envanterini çıkarın ve her birinin önemli + yönlerini belgeleyin; API ortamına (örn. üretim, staging, test, + geliştirme), sunucuya ağ erişimine kimlerin sahip olması gerektiğine + (örn. herkese açık, dahili, iş ortakları) ve API sürümüne odaklanın. +* Entegre servislerin envanterini çıkarın ve sistemdeki rolleri, hangi + verilerin değiş tokuş edildiği (veri akışı) ve hassasiyetleri gibi + önemli yönleri belgeleyin. +* Kimlik doğrulama, hatalar, yönlendirmeler, istek sınırlandırma, + kaynaklar arası kaynak paylaşımı (CORS) politikası ve uç noktalar + dâhil olmak üzere API'nizin tüm yönlerini; parametreleri, istekleri + ve yanıtlarıyla birlikte belgeleyin. +* Açık standartları benimseyerek dokümantasyonu otomatik olarak + oluşturun. Dokümantasyon oluşturmayı CI/CD ardışık düzeninize dâhil + edin. +* API dokümantasyonunu yalnızca API'yi kullanmaya yetkili olanlara + açık hâle getirin. +* Yalnızca mevcut üretim sürümü için değil, API'lerinizin açığa çıkmış + tüm sürümleri için API güvenlik duvarları gibi harici koruma + önlemleri kullanın. +* Üretim dışı API dağıtımlarında üretim verisi kullanmaktan kaçının. + Bu kaçınılmazsa, bu uç noktalar üretim uç noktalarıyla aynı güvenlik + muamelesini görmelidir. +* API'lerin daha yeni sürümleri güvenlik iyileştirmeleri içerdiğinde, + eski sürüm için gereken risk azaltma eylemlerine karar vermek üzere + bir risk analizi yapın: örneğin, iyileştirmelerin API uyumluluğunu + bozmadan geriye taşınıp taşınamayacağını veya eski sürümü hızla + devre dışı bırakıp tüm istemcileri en son sürüme geçmeye zorlamanız + gerekip gerekmediğini değerlendirin. + +## Kaynaklar + +### Harici Kaynaklar + +* [CWE-1059: Eksik Dokümantasyon][1] +* [OpenAPI Initiative][2] + +[1]: https://cwe.mitre.org/data/definitions/1059.html +[2]: https://www.openapis.org/ diff --git a/editions/2019/tr/0xaa-insufficient-logging-monitoring.md b/editions/2019/tr/0xaa-insufficient-logging-monitoring.md new file mode 100644 index 000000000..1f96a4922 --- /dev/null +++ b/editions/2019/tr/0xaa-insufficient-logging-monitoring.md @@ -0,0 +1,76 @@ +# API10:2019 Yetersiz Loglama ve İzleme + +| Tehdit aktörleri / Saldırı vektörleri | Güvenlik Zayıflığı | Etkiler | +| - | - | - | +| API'ye Özgü : İstismar Edilebilirlik **2** | Yaygınlık **3** : Tespit Edilebilirlik **1** | Teknik **2** : Kuruluşa özgü | +| Saldırganlar, fark edilmeden sistemleri istismar etmek için loglama ve izleme eksikliğinden yararlanır. | Loglama ve izleme olmadan veya yetersiz loglama ve izlemeyle, şüpheli etkinlikleri takip etmek ve bunlara zamanında müdahale etmek neredeyse imkânsızdır. | Devam eden kötü amaçlı etkinlikler üzerinde görünürlük olmadan, saldırganların sistemleri tamamen ele geçirmek için bol miktarda zamanı olur. | + +## API Bu Zafiyete Açık mı? + +API aşağıdaki durumlarda zafiyete açıktır: + +* Herhangi bir log üretmiyorsa, log seviyesi doğru ayarlanmamışsa + veya log mesajları yeterli ayrıntı içermiyorsa. +* Log bütünlüğü garanti edilmiyorsa (örn. [Log Enjeksiyonu][1]). +* Loglar sürekli olarak izlenmiyorsa. +* API altyapısı sürekli olarak izlenmiyorsa. + +## Örnek Saldırı Senaryoları + +### Senaryo #1 + +Yönetimsel bir API'nin erişim anahtarları herkese açık bir +repository'de sızdırılır. Repository sahibi, olası sızıntı hakkında +e-postayla bilgilendirilir; ancak olaya müdahale etmesi 48 saatten +uzun sürer ve bu sürede erişim anahtarlarının ifşası hassas verilere +erişime izin vermiş olabilir. Yetersiz loglama nedeniyle şirket, kötü +niyetli kişilerin hangi verilere eriştiğini tespit edemez. + +### Senaryo #2 + +Bir video paylaşım platformu "büyük ölçekli" bir kimlik bilgisi +doldurma saldırısına maruz kalır. Başarısız girişler loglansa da, +saldırının sürdüğü süre boyunca herhangi bir uyarı tetiklenmez. +Kullanıcı şikâyetlerine tepki olarak API logları incelenir ve saldırı +tespit edilir. Şirket, kullanıcılardan şifrelerini sıfırlamalarını +isteyen bir kamuoyu duyurusu yapmak ve olayı düzenleyici otoritelere +bildirmek zorunda kalır. + +## Nasıl Önlenir? + +* Başarısız tüm kimlik doğrulama denemelerini, reddedilen erişimleri + ve girdi doğrulama hatalarını loglayın. +* Loglar, bir log yönetimi çözümü tarafından tüketilmeye uygun bir + formatta yazılmalı ve kötü niyetli kişiyi tanımlamaya yetecek kadar + ayrıntı içermelidir. +* Loglar hassas veri olarak ele alınmalı ve hem bekleme hem de aktarım + sırasında bütünlükleri garanti altına alınmalıdır. +* Altyapıyı, ağı ve API'nin çalışmasını sürekli olarak izlemek için + bir izleme sistemi yapılandırın. +* API yığınının tüm bileşenlerinden ve sunucularından gelen logları + toplamak ve yönetmek için bir Güvenlik Bilgi ve Olay Yönetimi (SIEM) + sistemi kullanın. +* Şüpheli etkinliklerin daha erken tespit edilip müdahale + edilebilmesini sağlayan özel panolar (dashboard) ve uyarılar + yapılandırın. + +## Kaynaklar + +### OWASP + +* [OWASP Loglama Hızlı Başvuru Rehberi][2] +* [OWASP Proaktif Kontroller: Loglama ve Saldırı Tespiti Uygulama][3] +* [OWASP Uygulama Güvenliği Doğrulama Standardı: V7: Hata Yönetimi ve + Loglama Doğrulama Gereksinimleri][4] + +### Harici Kaynaklar + +* [CWE-223: Güvenlikle İlgili Bilginin İhmal Edilmesi][5] +* [CWE-778: Yetersiz Loglama][6] + +[1]: https://www.owasp.org/index.php/Log_Injection +[2]: https://www.owasp.org/index.php/Logging_Cheat_Sheet +[3]: https://www.owasp.org/index.php/OWASP_Proactive_Controls +[4]: https://github.com/OWASP/ASVS/blob/master/4.0/en/0x15-V7-Error-Logging.md +[5]: https://cwe.mitre.org/data/definitions/223.html +[6]: https://cwe.mitre.org/data/definitions/778.html diff --git a/editions/2019/tr/0xb0-next-devs.md b/editions/2019/tr/0xb0-next-devs.md new file mode 100644 index 000000000..380067ff8 --- /dev/null +++ b/editions/2019/tr/0xb0-next-devs.md @@ -0,0 +1,37 @@ +# Geliştiricileri Neler Bekliyor? + +Güvenli uygulamalar oluşturmak ve bunların güvenliğini sürdürmek ya da +mevcut uygulamaları düzeltme görevi zor olabilir. API'ler için de durum +farklı değildir. + +Eğitim ve farkındalığın, güvenli yazılım yazmanın temel unsurları +olduğuna inanıyoruz. Bu hedefi gerçekleştirmek için gereken her şey, +**tekrarlanabilir güvenlik süreçlerinin ve standart güvenlik +kontrollerinin oluşturulmasına ve kullanılmasına** bağlıdır. + +OWASP, güvenliği ele almanıza yardımcı olacak çok sayıda ücretsiz ve +açık kaynak sunar. Mevcut projelerin kapsamlı bir listesi için lütfen +[OWASP Projeler sayfasını][1] ziyaret edin. + +| | | +|-|-| +| **Eğitim** | Mesleğinize ve ilgi alanınıza göre [OWASP Eğitim Projesi materyallerini][2] okumaya başlayabilirsiniz. Uygulamalı öğrenme için **crAPI** - **C**ompletely **R**idiculous **API**'yi [yol haritamıza][3] ekledik. Bu arada, kullanıcılara modern web uygulamalarını ve API'leri güvenlik açıkları için nasıl test edeceklerini ve gelecekte daha güvenli API'ler nasıl yazacaklarını öğretmeyi amaçlayan zafiyetli bir WebApp ve API servisi olan [OWASP DevSlop Pixi Module][4] ile WebAppSec pratiği yapabilirsiniz. Ayrıca [OWASP AppSec Conference][5] eğitim oturumlarına katılabilir veya [yerel topluluğunuza katılabilirsiniz][6]. | +| **Güvenlik Gereksinimleri** | Güvenlik, en başından itibaren her projenin bir parçası olmalıdır. Gereksinimleri tanımlarken, o proje için "güvenli"nin ne anlama geldiğini tanımlamak önemlidir. OWASP, güvenlik gereksinimlerini belirlemek için bir rehber olarak [OWASP Application Security Verification Standard (ASVS)][7] kullanmanızı önerir. Dış kaynak kullanıyorsanız, yerel yasa ve düzenlemelere göre uyarlanması gereken [OWASP Secure Software Contract Annex][8]'i göz önünde bulundurun. | +| **Güvenlik Mimarisi** | Güvenlik, tüm proje aşamalarında bir öncelik olarak kalmalıdır. [OWASP Prevention Cheat Sheets][9], mimari aşamada güvenliği tasarlama konusunda rehberlik için iyi bir başlangıç noktasıdır. Diğerlerinin yanı sıra, [REST Security Cheat Sheet][10] ve [REST Assessment Cheat Sheet][11]'i orada bulacaksınız. | +| **Standart Güvenlik Kontrolleri** | Standart güvenlik kontrollerini benimsemek, kendi mantığınızı yazarken güvenlik zayıflıkları oluşturma riskini azaltır. Birçok modern çerçeve artık etkili yerleşik standart kontrollerle geliyor olsa da, [OWASP Proactive Controls][12] projenize hangi güvenlik kontrollerini dâhil etmeniz gerektiği konusunda size iyi bir genel bakış sunar. OWASP ayrıca doğrulama kontrolleri gibi değerli bulabileceğiniz bazı kütüphaneler ve araçlar sağlar. | +| **Güvenli Yazılım Geliştirme Yaşam Döngüsü** | API'ler oluştururken süreci geliştirmek için [OWASP Software Assurance Maturity Model (SAMM)][13] kullanabilirsiniz. Farklı API geliştirme aşamalarında size yardımcı olacak, örneğin [OWASP Code Review Project][14] gibi, başka birçok OWASP projesi de mevcuttur. | + +[1]: https://www.owasp.org/index.php/Category:OWASP_Project +[2]: https://www.owasp.org/index.php/OWASP_Education_Material_Categorized +[3]: https://www.owasp.org/index.php/OWASP_API_Security_Project#tab=Road_Map +[4]: https://devslop.co/Home/Pixi +[5]: https://www.owasp.org/index.php/Category:OWASP_AppSec_Conference +[6]: https://www.owasp.org/index.php/OWASP_Chapter +[7]: https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project +[8]: https://www.owasp.org/index.php/OWASP_Secure_Software_Contract_Annex +[9]: https://www.owasp.org/index.php/OWASP_Cheat_Sheet_Series +[10]: https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/REST_Security_Cheat_Sheet.md +[11]: https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/REST_Assessment_Cheat_Sheet.md +[12]: https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=OWASP_Proactive_Controls_2018 +[13]: https://www.owasp.org/index.php/OWASP_SAMM_Project +[14]: https://www.owasp.org/index.php/Category:OWASP_Code_Review_Project diff --git a/editions/2019/tr/0xb1-next-devsecops.md b/editions/2019/tr/0xb1-next-devsecops.md new file mode 100644 index 000000000..c6b83b343 --- /dev/null +++ b/editions/2019/tr/0xb1-next-devsecops.md @@ -0,0 +1,31 @@ +# DevSecOps'u Neler Bekliyor? + +Modern uygulama mimarilerindeki önemleri nedeniyle, güvenli API'ler +oluşturmak son derece önemlidir. Güvenlik ihmal edilemez ve tüm +geliştirme yaşam döngüsünün bir parçası olmalıdır. Yıllık tarama ve +sızma testleri artık yeterli değildir. + +DevSecOps, tüm yazılım geliştirme yaşam döngüsü boyunca sürekli +güvenlik testlerini kolaylaştırarak geliştirme çalışmalarına dâhil +olmalıdır. Amaçları, geliştirme hızını etkilemeden geliştirme ardışık +düzenini güvenlik otomasyonuyla güçlendirmek olmalıdır. + +Şüpheye düştüğünüzde bilgi sahibi olmaya devam edin ve [DevSecOps +Manifesto][1]'yu sık sık gözden geçirin. + +| | | +|-|-| +| **Tehdit Modelini Anlayın** | Test öncelikleri bir tehdit modelinden gelir. Eğer bir tehdit modeliniz yoksa, girdi olarak [OWASP Application Security Verification Standard (ASVS)][2] ve [OWASP Testing Guide][3] kullanmayı düşünün. Geliştirme ekibini sürece dâhil etmek, onların güvenlik konusunda daha bilinçli olmasına yardımcı olacaktır. | +| **SDLC'yi Anlayın** | Yazılım Geliştirme Yaşam Döngüsünü daha iyi anlamak için geliştirme ekibine katılın. Sürekli güvenlik testlerine katkınız; insanlar, süreçler ve araçlarla uyumlu olmalıdır. Herkes süreç konusunda hemfikir olmalı, böylece gereksiz sürtüşme veya direnç yaşanmamalıdır. | +| **Test Stratejileri** | Çalışmanız geliştirme hızını etkilememesi gerektiğinden, güvenlik gereksinimlerini doğrulamak için en uygun (en basit, en hızlı, en doğru) tekniği akıllıca seçmelisiniz. [OWASP Security Knowledge Framework][4] ve [OWASP Application Security Verification Standard][5], fonksiyonel ve fonksiyonel olmayan güvenlik gereksinimleri için değerli kaynaklar olabilir. [DevSecOps topluluğu][8] tarafından sunulanlara benzer [projeler][6] ve [araçlar][7] için başka kaynaklar da vardır. | +| **Kapsam ve Doğruluğa Ulaşma** | Geliştiriciler ve operasyon ekipleri arasındaki köprüsünüz. Kapsama ulaşmak için yalnızca işlevselliğe değil, aynı zamanda orkestrasyona da odaklanmalısınız. Zamanınızı ve çabanızı optimize edebilmek için en baştan hem geliştirme hem de operasyon ekipleriyle yakın çalışın. Temel güvenliğin sürekli olarak doğrulandığı bir duruma ulaşmayı hedeflemelisiniz. | +| **Bulguları Açıkça İletin** | Az sürtüşmeyle veya hiç sürtüşme olmadan değer katın. Bulguları zamanında, geliştirme ekiplerinin kullandığı araçlar içinde teslim edin (PDF dosyaları içinde değil). Bulguları ele almak için geliştirme ekibine katılın. Zayıflığı ve nasıl kötüye kullanılabileceğini açıkça tanımlayarak, durumu gerçek kılmak için bir saldırı senaryosu da dâhil ederek onları eğitmek için bu fırsatı değerlendirin. | + +[1]: https://www.devsecops.org/ +[2]: https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project +[3]: https://www.owasp.org/index.php/OWASP_Testing_Project +[4]: https://www.owasp.org/index.php/OWASP_Security_Knowledge_Framework +[5]: https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project +[6]: http://devsecops.github.io/ +[7]: https://github.com/devsecops/awesome-devsecops +[8]: http://devsecops.org diff --git a/editions/2019/tr/0xd0-about-data.md b/editions/2019/tr/0xd0-about-data.md new file mode 100644 index 000000000..b6f3d264f --- /dev/null +++ b/editions/2019/tr/0xd0-about-data.md @@ -0,0 +1,43 @@ +# Metodoloji ve Veriler + +## Genel Bakış + +AppSec sektörü, API'lerin önemli bir rol oynadığı uygulamaların en +güncel mimarisine henüz özel olarak odaklanmadığından, herkese açık +bir veri çağrısına dayanarak en kritik 10 API güvenliği riskinin +listesini oluşturmak zor bir görev olurdu. Herkese açık bir veri +çağrısı yapılmamış olsa da, ortaya çıkan Top 10 listesi yine de +herkese açık verilere, güvenlik uzmanlarının katkılarına ve güvenlik +topluluğuyla yapılan açık tartışmalara dayanmaktadır. + +## Metodoloji + +İlk aşamada, API güvenliği olaylarına ilişkin herkese açık veriler bir +güvenlik uzmanları grubu tarafından toplandı, incelendi ve kategorize +edildi. Bu veriler, bug bounty platformlarından ve zafiyet veri +tabanlarından, bir yıllık bir zaman dilimi içinde toplandı ve +istatistiksel amaçlarla kullanıldı. + +Sonraki aşamada, sızma testi deneyimine sahip güvenlik uzmanlarından +kendi Top 10 listelerini oluşturmaları istendi. + +Risk analizini gerçekleştirmek için [OWASP Risk Değerlendirme +Metodolojisi][1] kullanıldı. Skorlar, güvenlik uzmanları arasında +tartışıldı ve gözden geçirildi. Bu konulardaki değerlendirmeler için +lütfen [API Güvenliği Riskleri][2] bölümüne bakın. + +OWASP API Security Top 10 2019'un ilk taslağı, birinci aşamadaki +istatistiksel sonuçlar ile güvenlik uzmanlarının listeleri arasındaki +fikir birliğinden ortaya çıktı. Bu taslak, ardından API güvenliği +alanında ilgili deneyime sahip başka bir güvenlik uzmanları grubu +tarafından değerlendirilmek ve gözden geçirilmek üzere paylaşıldı. + +OWASP API Security Top 10 2019, ilk kez OWASP Global AppSec Tel Aviv +etkinliğinde (Mayıs 2019) sunuldu. O zamandan bu yana, herkese açık +tartışma ve katkılar için GitHub üzerinde erişilebilir durumdadır. + +Katkıda bulunanların listesi [Teşekkürler][3] bölümünde mevcuttur. + +[1]: https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology +[2]: ./0x10-api-security-risks.md +[3]: ./0xd1-acknowledgments.md diff --git a/editions/2019/tr/0xd1-acknowledgments.md b/editions/2019/tr/0xd1-acknowledgments.md new file mode 100644 index 000000000..dade9fff7 --- /dev/null +++ b/editions/2019/tr/0xd1-acknowledgments.md @@ -0,0 +1,40 @@ +# Teşekkürler + +## Katkıda Bulunanlara Teşekkürler + +GitHub üzerinden veya başka kanallardan projeye açık biçimde katkıda +bulunan aşağıdaki kişilere teşekkür ederiz: + +* 007divyachawla +* Abid Khan +* Adam Fisher +* anotherik +* bkimminich +* caseysoftware +* Chris Westphal +* dsopas +* DSotnikov +* emilva +* ErezYalon +* flascelles +* Guillaume Benats +* IgorSasovets +* Inonshk +* JonnySchnittger +* jmanico +* jmdx +* Keith Casey +* kozmic +* LauraRosePorter +* Matthieu Estrade +* nathanawmk +* PauloASilva +* pentagramz +* philippederyck +* pleothaud +* r00ter +* Raj kumar +* Sagar Popat +* Stephen Gates +* thomaskonrad +* xycloops123 diff --git a/editions/2019/tr/images/cover.jpg b/editions/2019/tr/images/cover.jpg new file mode 100644 index 000000000..5ef93f221 Binary files /dev/null and b/editions/2019/tr/images/cover.jpg differ diff --git a/editions/2019/tr/images/front-cc.png b/editions/2019/tr/images/front-cc.png new file mode 100644 index 000000000..45f139804 Binary files /dev/null and b/editions/2019/tr/images/front-cc.png differ diff --git a/editions/2019/tr/images/front-wasp.png b/editions/2019/tr/images/front-wasp.png new file mode 100644 index 000000000..5a163dd4b Binary files /dev/null and b/editions/2019/tr/images/front-wasp.png differ diff --git a/editions/2019/tr/images/license.png b/editions/2019/tr/images/license.png new file mode 100644 index 000000000..124d3ba4d Binary files /dev/null and b/editions/2019/tr/images/license.png differ diff --git a/editions/2019/tr/images/owasp-logo.png b/editions/2019/tr/images/owasp-logo.png new file mode 100644 index 000000000..caeb47bdf Binary files /dev/null and b/editions/2019/tr/images/owasp-logo.png differ