diff --git a/2021/docs/0x00-notice.id.md b/2021/docs/0x00-notice.id.md index 58c9feab2..3808065b1 100644 --- a/2021/docs/0x00-notice.id.md +++ b/2021/docs/0x00-notice.id.md @@ -1,7 +1,7 @@ ## Rilis -Rilis tanggal 24 September 2021 +Dirilis tanggal 24 September 2021 ## Penulis Utama @@ -12,17 +12,17 @@ Rilis tanggal 24 September 2021 ## Kontributor -- Orange Tsai, penulis A10-2021: Server Side Request Forgery -- Jim Manico danJakub Maćkowski - OWASP CheatSheets Coordination +- Orange Tsai [@orange_8361](https://twitter.com/orange_8361), penulis A10-2021: Server Side Request Forgery +- Jim Manico [@manicode](https://twitter.com/manicode) dan Jakub Maćkowski [@kubamackowski](https://twitter.com/kubamackowski) - OWASP CheatSheets Coordination -## Bagaimana Anda dapat berkontribusi +## Bagaimana Anda dapat membantu -Pada level ini, kami mengharapkan +Pada tahap ni, kami mengharapkan -- Pengolah data - mereview analisa kami -- Desainer web - kami membutuhkan versi yang sesuai untuk perangkat portabel -- Translators - menolong meninjau teks bahasa Inggris untuk memastikan ini dapat diterjemahkan -- ASVS, panduan testing, dan pemimpin panduan tinjauan kode - silahkan menggunakan data kami dan membantu kami menghubungkan +- Ilmuwan data - harap meninjau analisa kami +- Desainer web - kami perlu membuat suatu versi yang ramah ke perangkat bergerak +- Penerjemah - harap meninjau teks bahasa Inggris untuk memastikan ini dapat diterjemahkan +- ASVS, Panduan Pengujian, dan pemimpin Panduan Tinjauan Kode - silakan menggunakan data kami dan membantu kami menghubungkan dokumen kami dan standarnya secara bersama-sama. ## Masalah log dan permintaan penarikan diff --git a/2021/docs/A00-about-owasp.id.md b/2021/docs/A00-about-owasp.id.md index 5ad18a3dd..e6de1b536 100644 --- a/2021/docs/A00-about-owasp.id.md +++ b/2021/docs/A00-about-owasp.id.md @@ -2,7 +2,7 @@ Open Web Application Security Project (OWASP) adalah komunitas terbuka yang didedikasikan untuk memungkinkan organisasi mengembangkan, membeli, dan memelihara aplikasi yang dapat dipercaya. -Di OWASP, anda akan menemukan kebebasan dan keterbukaan: +Di OWASP, Anda akan menemukan kebebasan dan keterbukaan: - Alat dan standar dalam keamanan aplikasi. - Penelitian terkini. @@ -16,7 +16,7 @@ Di OWASP, anda akan menemukan kebebasan dan keterbukaan: Pelajari lebih lanjut di: [https://www.owasp.org](https://www.owasp.org). -seluruh alat OWASP, dokumen, video, presentasi, dan bagian adalah kebebasan dan keterbukaan bagi semua orang yang tertarik dalam meningkatkan keamanan aplikasi +Seluruh alat, dokumen, video, presentasi, dan chapter OWASP adalah kebebasan dan keterbukaan bagi semua orang yang tertarik dalam meningkatkan keamanan aplikasi Kami menganjurkan mendekati keamanan aplikasi sebagai masalah orang, proses, dan teknologi, karena pendekatan yang paling efektif untuk keamanan aplikasi memerlukan peningkatan pada bidang-bidang ini. @@ -28,8 +28,8 @@ Yayasan OWASP adalah entitas nonprofit yang memastikan kesuksesan jangka panjang Ayo bergabung dengan kami! -## Copyright and License +## Hak Cipta dan Lisensi ![license](assets/license.png) -Copyright © 2003-2021 The OWASP&tm; Foundation. This document is released under the Creative Commons Attribution Share-Alike 4.0 license. For any reuse or distribution, you must make it clear to others the license terms of this work. +Hak cipta © 2003-2021 The OWASP&tm; Foundation. Dokumen ini rilis di bawah lisensi Creative Commons Attribution Share-Alike 4.0. Untuk penggunaan ulang atau distribusi apa pun, Anda mesti membuat jelas ke pihak lain persyaratan lisensi dari karya ini. diff --git a/2021/docs/A00_2021-How_to_start_an_AppSec_program_with_the_OWASP_Top_10.id.md b/2021/docs/A00_2021-How_to_start_an_AppSec_program_with_the_OWASP_Top_10.id.md index 8b887eee5..dfd42d270 100644 --- a/2021/docs/A00_2021-How_to_start_an_AppSec_program_with_the_OWASP_Top_10.id.md +++ b/2021/docs/A00_2021-How_to_start_an_AppSec_program_with_the_OWASP_Top_10.id.md @@ -1,87 +1,95 @@ -# Bagaimana cara untuk memulai program AppSec dengan OWASP Top 10 +# Bagaimana cara untuk memulai Program AppSec dengan OWASP Top 10 Sebelumnya, OWASP Top 10 tidak pernah dirancang untuk menjadi basis dari sebuah -program AppSec. Bagaimanapun, hal ini diperlukan untuk memulai darimanapun bagi -berbagai organisasi yang baru saja memulai perjalanan mereka dalam keamanan -aplikasi OWASP Top 10 2021 merupakan awal yang baik sebagai landasan untuk daftar -periksa dan sebagainya, tapi itu sendiri tidak cukup. +program AppSec. Namun, perlu untuk memulai darimanapun bagi berbagai organisasi +yang baru saja mengawali perjalanan mereka dalam keamanan aplikasi. OWASP Top +10 2021 merupakan awal yang baik sebagai landasan untuk daftar periksa dan +sebagainya, tapi itu sendiri tidak cukup. -## Tahap 1. Identifikasi kesenjangan dan tujuan dari program appsec anda +## Tahap 1. Identifikasi kesenjangan dan tujuan dari program appsec Anda -Banyak program Keamanan Aplikasi (AppSec) mencoba untuk berlali sebelum mereka +Banyak program Keamanan Aplikasi (AppSec) mencoba untuk berlari sebelum mereka dapat merangkak atau berjalan. Usaha seperti ini pasti akan gagal. Kami sangat -mendorong pimpinan CISO dan AppSec untuk menggunakan Jaminan Perangkat Lunak OWASP -Model Kematangan (SAMM) \[\] untuk mengidentifikasi +mendorong pimpinan CISO dan AppSec untuk menggunakan [OWASP Software Assurance +Maturity Model (SAMM)](https://owaspsamm.org>) untuk mengidentifikasi kelemahan dan wilayah untuk perbaikan selama periode 1-3 tahun. Tahap pertama -adalah untuk evaluasi dimana anda sekarang, identifikasi kesenjangan pada -pemerintahan, perencanaan, implementasi, verifikasi, dan operasi yang anda +adalah untuk evaluasi di mana Anda sekarang, identifikasi kesenjangan pada +pemerintahan, perencanaan, implementasi, verifikasi, dan operasi yang Anda butuhkan untuk menyelesaikan segera versus yang bisa menunggu, dan memprioritaskan implementasi atau memperbaiki lima belas praktik keamanan OWASP SAMM. OWASP SAMM -dapat membantu you build and measure improvements in your software assurance -efforts. anda membangun dan menimbang perbaikan dalam jaminan usaha perangkat -lunak anda. +dapat membantu Anda membangun dan mengukur peningkatan dalam upaya penjaminan +perangkat lunak Anda. -## Tahap 2. Rencana untuk siklus hidup pengembangan yang aman +## Tahap 2. Rencanakan untuk jalan beraspal siklus hidup pengembangan yang aman -Secara tradisional melestarikan apa yang disebut dengan "unicorns," konsep -jalan beraspal adalah jalan termudah untuk membuat sumber daya Aplikasi Keamanan -yang sangat berdampak dan berskala dengan kecepatan pengembangan tim, yang mana +Secara tradisional melestarikan apa yang disebut dengan "unicorns", konsep +jalan beraspal adalah cara termudah untuk membuat sumber daya Aplikasi Keamanan +yang sangat berdampak dan berskala dengan kecepatan pengembangan tim, yang makin meningkat setiap tahun. Konsep pengembangan yang aman adalah "jalan termudah dan juga jalur teraman" dan harus -melibatkan budaya kemitraan yang mendalam antara team pengembang dan tim -keamanan, sebaiknya seperti mereka adalah satu dan dalam tim yang sama. Jalan -beraspal bertujuan untuk terus memperbaiki, menimbang, mendeteksi dan mengubah +melibatkan budaya kemitraan yang mendalam antara tim pengembang dan tim +keamanan, lebih disukai mereka adalah satu tim yang sama. Jalan +beraspal bertujuan untuk terus memperbaiki, mengukur, mendeteksi, dan mengganti alternatif yang tidak aman dengan memiliki sebuah perpustakaan dengan skala seluruh perusahaan untuk menempatkan perubahan yang aman dengan alat untuk -membantu melihat dimana perbaikan dapat dibuat dengan mengadopsi konsep jalan -beraspal. Ini memungkinkan alat pengembangan yang ada untuk melaporkan pembuatan -dan membantu tim pengembang untuk mengoreksi kembali dari alternatif yang tidak -aman. - -Konsep pengembangan yang aman mungkin tampak banyak yang harus dilalui, tetapi itu harus dibangun secara bertahap dari waktu ke waktu. Ada bentuk lain dari program keamanan aplikasi diluar sana, terutama Microsoft Agile Secure Development Lifecycle. Tidak semua metode program keamanan aplikasi sesuai dengan semua bisnis. - -## Tahap 3. Mengimplementasikan konsep jalan pengembangan yang aman dengan tim pengembang anda. - -Konsep jalan beraspal dibentuk dengan persetujuan dan keterlibatan langsung dari tim pengembang dan operasi yang relevan. Pengembangan yang aman harus disejajarkan secara strategis dengan sisi bisnis dan membantu mengantarkan kembali aplikasi yang aman lebih cepat. Mengembangkan Konsep Pengembangan yang aman harus menjadi panduan penjagaan latihan yang mencakup seluruh perusahaan ataupun ekosistem aplikasi, bukan sebagai tambalan untuk aplikasi yang belum siap, seperti di hari-hari sebelumnya. - -## Tahap 4. Migrasikan semua aplikasi yang akan datang dan yang sudah ada ke Konsep Pengembangan yang aman. - -Tambahkan Alat pendeteksi pada Konsep Pengembangan yang aman saat anda mengembangkannya -dan menyediakan informasi untuk tim pengembang untuk meningkatkan keamanan dari +membantu melihat di mana perbaikan dapat dibuat dengan mengadopsi konsep jalan +beraspal. Ini memungkinkan alat pengembangan yang ada untuk melaporkan build +yang tidak aman dan membantu tim pengembang untuk mengoreksi diri sendiri dari +alternatif yang tidak aman. + +Konsep pengembangan yang aman mungkin tampak banyak yang harus dilalui, tetapi +itu harus dibangun secara bertahap dari waktu ke waktu. Ada bentuk lain dari +program keamanan aplikasi di luar sana, terutama Microsoft Agile Secure +Development Lifecycle. Tidak semua metode program keamanan aplikasi sesuai +dengan semua bisnis. + +## Tahap 3. Mengimplementasikan konsep jalan beraspal dengan tim pengembang Anda + +Konsep jalan beraspal dibentuk dengan persetujuan dan keterlibatan langsung +dari tim pengembang dan operasi yang relevan. Pengembangan yang aman harus +diselaraskan secara strategis dengan sisi bisnis dan membantu mengantarkan +aplikasi yang aman lebih cepat. Mengembangkan konsep jalan beraspal +harus menjadi latihan holistik yang mencakup seluruh perusahaan ataupun +ekosistem aplikasi, bukan sebagai tambalan untuk aplikasi yang belum siap, +seperti di masa lalu. + +## Tahap 4. Migrasikan semua aplikasi yang akan datang dan yang sudah ada ke konsep jalan beraspal + +Tambahkan alat pendeteksi pada konsep jalan beraspal saat Anda mengembangkannya +dan sediakan informasi bagi tim pengembang untuk meningkatkan keamanan dari aplikasi mereka dengan bagaimana mereka bisa langsung mengadopsi elemen dari konsep -jalan beraspal. Ketika sebuah aspekdari konsep jalan beraspal telah diadopsi, -organisasi harus mengimplementasikan pemeriksaan integrasi yang berkelanjutan yang -mana memeriksa kode yang telah ada dan check-in yang menggunakan alternatif terlarang -dan memperingatkan atau menolak build program atau check-in. Hal ini mencegah opsi -yang tidak aman dapat merayap ke dalam kode sepanjang waktu, mencegah hutang teknis -dan aplikasi tidak aman yang rusak. Peringatan semacam itu harus terhubung kepada -alternatif yang aman, sehingga tim pengembang dapat diberikan jawaban yang benar -sesegera mungkin. Mereka dapat melakukan refactoring dan mengadopsi kompnen pada +jalan beraspal. Sekali sebuah aspek dari konsep jalan beraspal telah diadopsi, +organisasi harus mengimplementasikan pemeriksaan integrasi berkelanjutan yang +memeriksa kode yang telah ada dan check-in yang menggunakan alternatif terlarang +dan memperingatkan atau menolak build atau check-in tersebut. Hal ini mencegah opsi +yang tidak aman dapat merayap ke dalam kode dengan berjalannya waktu, mencegah +hutang teknis, dan aplikasi tidak aman yang rusak. Peringatan semacam itu harus +menaut kepada alternatif yang aman, sehingga tim pengembang diberik jawaban +yang benar seketika. Mereka dapat melakukan refactor dan mengadopsi komponen konsep jalan beraspal dengan cepat. -## Tahap 5. Uji apakah konsep Pengembangan yang aman telah mengurangi masalah yang ditemukan di OWASP Top 10 +## Tahap 5. Uji apakah konsep jalan beraspal telah memitigasi masalah yang ditemukan di OWASP Top 10 -Komponen konsep Pengembangan yang aman harus mengatasi masalah yang signifikan -dengan OWASP Top 10, sebagai contohnya, bagaimana untuk mendeteksi secara +Komponen konsep jalan beraspal harus mengatasi masalah yang signifikan +dengan OWASP Top 10, sebagai contoh, bagaimana untuk mendeteksi secara otomatis atau memperbaiki komponen yang rentan, atau plugin IDE analisis -kode statis untuk mendeteksi injeksi atau bahkan lebih seperti perpustakaan -yang dikenal aman terhadap injeksi, seperti React atau Vue. Semakin banyak -penggantian pengiriman aman yang diberikan kepada tim, semakin baik. sebuah -tugas penting pada tim keamanan aplikasi adalah untuk memastikan bahwa -keamanan komponen-komponen ini adalah ditingkatkan dan dievaluasi secara -berkelanjutan. Setelah mereka diperbaiki, beberapa bentuk jalur komunikasi -dengan konsumen dari komponen harus mengindikasikan bahwa peningkatan harus -terjadi, sebaiknya secara otomatis, tapi apabila tidak, setidaknya disorot -pada sebuah tampilan dasar atau sejenisnya. - -## Tahap 6. Bangun program anda menjadi program keamanan aplikasi yang matang +kode statis untuk mendeteksi injeksi, atau lebih baik lagi seperti perpustakaan +yang dikenal aman terhadap injeksi. Semakin banyak pengganti aman yang ini +diberikan kepada tim, semakin baik. Sebuah tugas penting pada tim keamanan +aplikasi adalah untuk memastikan bahwa keamanan komponen-komponen ini +ditingkatkan dan dievaluasi secara berkelanjutan. Setelah mereka diperbaiki, +beberapa bentuk jalur komunikasi dengan konsumen dari komponen harus +mengindikasikan bahwa peningkatan harus terjadi, sebaiknya secara otomatis, +tapi apabila tidak, setidaknya disorot pada sebuah tampilan dasbor atau sejenisnya. + +## Tahap 6. Bangun program Anda menjadi program keamanan aplikasi yang matang Anda tidak boleh berhenti hanya di OWASP Top 10. Itu hanya mencakup 10 kategori resiko. Kami sangat mendorong organisasi untuk mengadopsi Application Security Verification Standard dan semakin menambah komponen jalan beraspal dan menguji untuk tingkat 1, 2, dan 3, -tergantung pada pengembangan tingkat resiko pada aplikasi +tergantung pada tingkat resiko aplikasi yang dikembangkan. ## Lakukan yang terbaik @@ -91,11 +99,11 @@ kerentanan keamanan aplikasi. - **Integritas Konseptual**. Program aplikasi keamanan yang matang harus mengandung beberapa konsep dari arsitektur keamanan, - Apakah berupa cloud yang formal atau arsitektur keamanan - perusahaan atau threat modeling. + apakah berupa cloud yang formal atau arsitektur keamanan + perusahaan, atau pemodelan ancaman. - **Skala dan otomasi**. Program aplikasi keamanan yang matang mencoba - untuk mengotomasi sebanyak pengiriman yang dapat dilakukan, + untuk mengotomasi sebanyak mungkin hasil mereka, menggunakan skrip untuk meniru tahapan penetration testing yang kompleks, alat analisis kode statis tersedia secara langsung ke tim pengembang, membantu tim pengembang dalam membangun unit aplikasi @@ -104,15 +112,15 @@ kerentanan keamanan aplikasi. - **Budaya**. Program Aplikasi Keamanan yang matang mencoba untuk membongkar rancangan yang tidak aman dan menghapuskan hutang teknis dari kode yang telah ada dengan menjadi bagian dari tim pengembang - dan tidak menyampingkannya. tim aplikasi keamanan yang melihat tim - pengembang sebagai "kami" atau "mereka" ditakdirkan untuk gagal. + dan tidak menyampingkannya. Tim aplikasi keamanan yang melihat tim + pengembang sebagai "kami" dan "mereka" ditakdirkan untuk gagal. - **Peningkatan berkelanjutan**. Program Aplikasi Keamanan yang matang - merujuk kepada peningkatan yang konstan. Apabila terjadi hal yang - tidak bekerja atau berhenti melakukan hal tersebut. Apabila sesuatu - kikuk atau tidak terukur, bekerjalah untuk meningkatkan nya. Apabila - sesuatu tidak digunakan oleh tim pengembang dan tidak memiliki atau + merujuk kepada peningkatan yang konstan. Apabila sesuatu + tidak bekerja, berhenti melakukan hal tersebut. Apabila sesuatu + kikuk atau tidak terukur, bekerjalah untuk meningkatkannya. Apabila + sesuatu tidak digunakan oleh tim pengembang dan tidak punya atau memiliki dampak yang terbatas, lakukan sesuatu yang berbeda. Hanya - karena kita telah melakukan pengujian seperti desk checks sejak + karena kita telah melakukan pengujian seperti desk check sejak tahun 1970-an tidak berarti itu adalah ide bagus. Ukur, evaluasi, lalu bangun atau tingkatkan. diff --git a/2021/docs/A00_2021_How_to_use_the_OWASP_Top_10_as_a_standard.id.md b/2021/docs/A00_2021_How_to_use_the_OWASP_Top_10_as_a_standard.id.md index 941e9ce97..2954866b4 100644 --- a/2021/docs/A00_2021_How_to_use_the_OWASP_Top_10_as_a_standard.id.md +++ b/2021/docs/A00_2021_How_to_use_the_OWASP_Top_10_as_a_standard.id.md @@ -1,22 +1,22 @@ -# Bagaimana cara menggunakan OWASP Top 10 sebagai sebuah standarisasi +# Bagaimana cara menggunakan OWASP Top 10 sebagai sebuah standar OWASP Top 10 terutama merupakan dokumen kesadaran. Bagaimanapun, hal ini -tidak menutup organisasi untuk menggunakannya sebagai sebuah standar de +tidak menghentikan organisasi untuk menggunakannya sebagai sebuah standar de facto pada industri keamanan aplikasi sejak kelahirannya pada tahun 2003. -Apabila anda ingin menggunakan OWASP Top 10 sebagai standar dalam coding -atau pengujian, ketahuilah bahwa ini adalah batas minimal dan hanya sebuah -tahap awal. +Apabila Anda ingin menggunakan OWASP Top 10 sebagai standar dalam coding +atau pengujian, ketahuilah bahwa ini adalah minimal dan hanya sebuah +titik awal. Salah satu kesulitan dalam menggunakan OWASP Top 10 sebagai sebuah standar adalah kita mendokumentasikan resiko keamanan aplikasi, dan belum tentu -sebuah masalah yang mudah diuji. Sebagai contohnya, A04:2021-Insecure Design -yang mana berada di luar cakupan sebagian besar bentuk dari pengujian. -Contoh lainnya adalah pengujian di tempat, digunakan, dan pencatatan dan +sebuah masalah yang mudah diuji. Sebagai contoh, A04:2021-Insecure Design +berada di luar cakupan dari sebagian besar bentuk pengujian. +Contoh lain adalah pengujian di tempat, digunakan, serta pencatatan log dan pemantauan yang efektif hanya dapat dilakukan dengan wawancara dan meminta -sebuah sampel dari respon tanggapan insiden yang efektif. Sebuah alat analisa -kode statis dapat melihat mengenai ketidakhadiran pada pencatatan, namun hal -ini mungkin mustahil untuk ditentukan apabila business logic atau kontrol -akses mencatat penjebolan keamanan yang kritis. penguji penetrasi hanya dapat +sebuah sampel dari respon tanggap insiden yang efektif. Sebuah alat analisa +kode statis dapat mencari ketidakhadiran pencatatan log, namun hal +ini mungkin mustahil untuk ditentukan apakah logika bisnis atau kontrol +akses mencatat pelanggaran keamanan yang kritis. Penguji penetrasi hanya dapat menentukan bahwa mereka telah memanggil respons insiden di lingkungan pengujian, yang jarang dipantau dengan cara yang sama seperti pada produksi. @@ -25,26 +25,27 @@ menggunakan OWASP Top 10: | Use Case | OWASP Top 10 2021 | OWASP Application Security Verification Standard | |-------------------------|:-------------------:|:--------------------------------------------------:| -| Awareness | Yes | | -| Training | Entry level | Comprehensive | -| Design and architecture | Occasionally | Yes | -| Coding standard | Bare minimum | Yes | -| Secure Code review | Bare minimum | Yes | -| Peer review checklist | Bare minimum | Yes | -| Unit testing | Occasionally | Yes | -| Integration testing | Occasionally | Yes | -| Penetration testing | Bare minimum | Yes | -| Tool support | Bare minimum | Yes | -| Secure Supply Chain | Occasionally | Yes | +| Awareness | Ya | | +| Training | Entry level | Komprehensif | +| Design and architecture | Kadang-kadang | Ya | +| Coding standard | Minimal | Ya | +| Secure Code review | Minimal | Ya | +| Peer review checklist | Minimal | Ya | +| Unit testing | Kadang-kadang | Ya | +| Integration testing | Kadang-kadang | Ya | +| Penetration testing | Minimal | Ya | +| Tool support | Minimal | Ya | +| Secure Supply Chain | Kadang-kadang | Ya | Kami akan mendorong siapa pun yang ingin mengadopsi standar keamanan -aplikasi untuk menggunakan OWASP Application Security Verification -Standar (ASVS), yang mana ini dirancang agar dapat diverifikasi dan -diuji, dan dapat digunakan di berbagai bagian dari siklus hidup +aplikasi untuk menggunakan [OWASP Application Security Verification +Standar](https://owasp.org/www-project-application-security-verification-standard/) +(ASVS), karena ini dirancang agar dapat diverifikasi dan +diuji, dan dapat digunakan di semua bagian dari siklus hidup pengembangan yang aman. ASVS hanyalah sebuah pilihan yang dapat diterima untuk vendor alat. Alat tidak bisa secara menyeluruh mendeteksi, menguji, ataupun melindungi dari OWASP Top 10 dikarenakan sifat dari beberapa resiko OWASP Top 10, dengan mengacu kepada A04:2021-Insecure Design. OWASP tidak menyarankan -penangguhan penuh dari OWASP Top 10, dikarenakan hal itu tidak benar. +cakupan penuh dari OWASP Top 10, karena hal itu sama sekali tidak benar. diff --git a/2021/docs/A00_2021_Introduction.id.md b/2021/docs/A00_2021_Introduction.id.md index 9a5a90276..b9e67f9af 100644 --- a/2021/docs/A00_2021_Introduction.id.md +++ b/2021/docs/A00_2021_Introduction.id.md @@ -1,6 +1,8 @@ -# Pengenalan +# Pengantar -## Selamat datang di OWASP Top 10 - 2021 +## Selamat datang ke OWASP Top 10 - 2021 + +![OWASP Top 10 Logo](./assets/TOP_10_logo_Final_Logo_Colour.png){:class="img-responsive"} Selamat datang ke versi terakhir dari OWASP Top 10! OWASP Top 10 2021 semua baru, dengan desain grafis baru dan suatu infografis satu-halaman yang dapat Anda cetak atau dapatkan dari beranda kami. @@ -8,94 +10,88 @@ Terima kasih sebesar-besarnya ke semua orang yang menyumbangkan waktu dan data m ## Apa yang berubah di Top 10 untuk 2021 -Terdapat tiga kategori baru, empat kategori dengan penamaan dan perbuahan ruang lingkup, dan beberapa konsolidasi baru di Top 10 untuk 2021 +Terdapat tiga kategori baru, empat kategori dengan penamaan dan perubahan ruang lingkup, dan beberapa konsolidasi baru di Top 10 untuk 2021. Kami telah mengubah nama ketika diperlukan untuk berfokus pada akar masalah daripada gejala. -![license](assets/mapping.png) +![Mapping](assets/mapping.png) -- **A01:2021-Broken Access Control** naik dari posisi kelima; 94% dari aplikasi yang telah diuji dengan broken access kontrol dalam beberapa bentuk. 34 CWE yang dipetakan ke Broken Access Control memiliki lebih banyak kemunculan dalam aplikasi daripada kategori lainnya. -- **A02:2021-Cryptographic Failures** menggeser satu posisi menjadi #2, sebelumnya dikenal sebagai Pengungkapan Data Sensitif, yang merupakan gejala luas dan bukan penyebab utama. Fokus baru di sini adalah pada kegagalan yang terkait dengan Kriptografi yang sering mengarah pada Pengungkapan Data Sensitif atau sistem yang telah terinfeksi oleh hacker. -- **A03:2021-Injection** turun ke posisi ketiga. 94% aplikasi diuji untuk beberapa bentuk injeksi, dan 33 CWE yang dipetakan ke dalam kategori ini memiliki kejadian terbanyak kedua dalam aplikasi. Skrip cross-site sekarang menjadi bagian dari kategori ini dalam edisi ini. -- **A04:2021-Insecure Design** adalah kategori baru untuk tahun 2021, dengan fokus pada resiko yang terkait dengan kekurangan desain. Jika kita ingin benar-benar bergerak sebagai industri, itu membutuhkan lebih banyak penggunaan pemodelan ancaman, pola dan desain yang aman, dan arsitektur referensi -- **A05:2021-Security Misconfiguration** naik dari #6 di edisi sebelumnya; 90% aplikasi diuji untuk beberapa bentuk kesalahan konfigurasi. Dengan lebih banyak perubahan ke software dengan konfigurasi yang banyak, tidak mengherankan melihat kategori ini naik. Kategori sebelumnya untuk XML External Entities (XXE) sekarang menjadi bagian dari kategori ini. -- **A06:2021-Vulnerable and Outdated Components** sebelumnya berjudul Using Components with Known Vulnerabilities dan #2 dalam survei industri, tapi juga memiliki cukup data untuk masuk TOP 10 melalui analisis data. Kategori ini naik dari #9 di tahun 2017 dan merupakan masalah umum yang kami perjuangkan untuk menguji dan menilai resiko. Ini adalah satu-satunya kategori yang tidak memiliki CVE yang dipetakan ke CWE yang disertakan, jadi eksploitasi default dan bobot dampak 5.0 diperhitungkan dalam skornya. -- **A07:2021-Identification and Authentication Failures** sebelumnya adalah Broken Authentication dan turun dari posisi kedua, dan sekarang termasuk CWE yang lebih terkait dengan kegagalan identifikasi. Kategori ini masih merupakan bagian integral dari Top 10, tetapi peningkatan ketersediaan framework yang telah distandarisasi tampaknya membantu. -- **A08:2021-Software and Data Integrity Failures** adalah kategori baru untuk tahun 2021, yang berfokus pada pembuatan asusmsi terkait pembaruan perangkat lunak, data penting, dan pipeline CI/CD tanpa memverifikasi integritas. Salah satu dampak tertinggi dari CVE/CVSS yang dipetakan ke 10 CWE dalam kategori ini. Insecure Deserialization dari tahun 2017 sekarang menjadi bagian dari kategori yang lebih besar ini. -- **A09:2021-Security Logging and Monitoring Failures** sebelumnya Logging dan Monitoring tidak memadai dan ditambahkan dari survei industri (#3), naik dari #10 sebelumnya. Kategori ini diperluas untuk mencakup lebih banyak jenis kegagalan, suatu tantangan untuk diiuji, dan tidak terwakili dengan baik dalam data CVE/CVSS. Namun, kegagalan dalam kategori ini dapat secara langsung mempengaruhi visibilitas, alert pada insiden, dan forensik -- **A10:2021-Server-Side Request Forgery** ditambahkan dari survei industri (#1). Data menunjukkan tingkat insiden yang relatif rendah dengan cakupan pengujian di atas rata-rata, bersama dengan peringkat di atas rata-rata untuk potensi eksploitasi dan dampak. Kategori ini mewakili skenario di mana para profesional industri memberi tahu kami bahwa ini penting, meskipun tidak diilustrasikan dalam data saat ini. +- **A01:2021-Broken Access Control** naik dari posisi kelima ke kategori dengan risiko keamanan aplikasi web paling serius; data yang disumbangkan mengindikasikan bahwa rata-rata, 3,81% aplikasi yang diuji memiliki satu atau lebih Common Weakness Enumeration (CWE) dengan lebih dari 318k kemunculan CWE dalam kategori risiko ini. 34 CWE yang dipetakan ke Broken Access Control memiliki lebih banyak kemunculan dalam aplikasi daripada kategori lainnya. +- **A02:2021-Cryptographic Failures** naik satu posisi menjadi #2, sebelumnya dikenal sebagai **A3:2017-Pengungkapan Data Sensitif**, yang merupakan gejala luas dan bukan akar masalah. Nama yang diperbarui di sini berfokus pada kegagalan yang terkait dengan kriptografi seperti yang sebelumnya tersirat. Kategori ini sering mengarah pada pengungkapan data sensitif atau sistem terkompromi. +- **A03:2021-Injection** turun ke posisi ketiga. 94% aplikasi diuji untuk beberapa bentuk injeksi dengan laju insidensi maks 19%, laju insidensi rata-rata 3,37%, dan 33 CWE yang dipetakan ke dalam kategori ini memiliki kejadian terbanyak kedua dalam aplikasi dengan 274k kemunculan. Cross-site Scripting sekarang menjadi bagian dari kategori ini dalam edisi ini. +- **A04:2021-Insecure Design** adalah kategori baru untuk tahun 2021, dengan fokus pada risiko yang terkait dengan cacat desain. Jika kita ingin benar-benar "bergerak ke kiri" sebagai industri, itu membutuhkan lebih banyak pemodelan ancaman, prinsip dan pola desain yang aman, dan arsitektur referensi. Suatu desain yang tidak aman tidak bisa diperbaiki dengan suatu implementasi sempurna karena secara definisi, kendali keamanan yang diperlukan tidak pernah diciptakan untuk bertahan atas serangan spesifik. +- **A05:2021-Security Misconfiguration** naik dari #6 di edisi sebelumnya; 90% aplikasi diuji untuk beberapa bentuk kesalahan konfigurasi, dengan laju insidensi rata-rata 4,5%, dan lebih dari 208k kemunculan dari CWE yang dipetakan ke kategori risiko ini. Dengan lebih banyak pergeseran ke software yang sangat bisa dikonfigurasi, tidak mengherankan melihat kategori ini naik. Kategori sebelumnya untuk **A4:2017-XML External Entities (XXE)** sekarang menjadi bagian dari kategori risiko ini. +- **A06:2021-Vulnerable and Outdated Components** sebelumnya berjudul Using Components with Known Vulnerabilities dan #2 dalam survei komunitas, tapi juga memiliki cukup data untuk masuk TOP 10 melalui analisis data. Kategori ini naik dari #9 di tahun 2017 dan merupakan masalah yang telah dikenal, yang kami mengalami kesulitan untuk menguji dan menilai risikonya. Ini adalah satu-satunya kategori yang tidak memiliki CVE yang dipetakan ke CWE yang disertakan, jadi eksploitasi default dan bobot dampak 5.0 diperhitungkan dalam skornya. +- **A07:2021-Identification and Authentication Failures** sebelumnya dalah **A2:2017-Broken Authentication** dan turun dari posisi kedua, dan sekarang termasuk CWE yang lebih terkait dengan kegagalan identifikasi. Kategori ini masih merupakan bagian integral dari Top 10, tetapi peningkatan ketersediaan framework yang telah distandarisasi tampaknya membantu. +- **A08:2021-Software and Data Integrity Failures** adalah kategori baru untuk tahun 2021, yang berfokus pada pembuatan asumsi terkait pembaruan perangkat lunak, data penting, dan pipeline CI/CD tanpa memverifikasi integritas. Salah satu dampak tertinggi dari Common Vulnerability and Exposures/Common Vulnerability Scoring System (CVE/CVSS) yang dipetakan ke 10 CWE dalam kategori ini. **A8:2017-Insecure Deserialization** dari tahun 2017 sekarang menjadi bagian dari kategori yang lebih besar ini. +- **A09:2021-Security Logging and Monitoring Failures** sebelumnya **A10:2017-Logging dan Monitoring** dan ditambahkan dari survei komunitas Top 10 (#3), naik dari #10 sebelumnya. Kategori ini diperluas untuk mencakup lebih banyak jenis kegagalan, suatu tantangan untuk diiuji, dan tidak terwakili dengan baik dalam data CVE/CVSS. Namun, kegagalan dalam kategori ini dapat secara langsung mempengaruhi visibilitas, alert atas insiden, dan forensik. +- **A10:2021-Server-Side Request Forgery** ditambahkan dari survei komunitas Top 10 (#1). Data menunjukkan tingkat insiden yang relatif rendah dengan cakupan pengujian di atas rata-rata, bersama dengan peringkat di atas rata-rata untuk potensi Eksploitasi dan Dampak. Kategori ini mewakili skenario di mana para anggota komunitas keamanan memberi tahu kami bahwa ini penting, meskipun tidak diilustrasikan dalam data saat ini. ## Metodologi -Penyusunan dari Top 10 ini lebih didorong oleh data daripada sebelumnya tetapi tidak didorong oleh data yang tidak di verifikasi dahulu. Kami memilih delapan dari sepuluh kategori dari kontribusi data dan 2 kategori dari survei industri tingkat tinggi. Kami melakukan ini karena alasan mendasar, melihat data yang telah dikumpulkan sama dengan melihat ke masa lalu. Peneliti AppSec membutuhkan waktu untuk menemukan kerentanan baru dan cara baru untuk mengujinya. Dibutuhkan waktu untuk mengintegrasikan tes ini ke dalam alat dan proses. Pada saat kita dapat dengan andal menguji kelemahan dalam skala, tahun-tahun kemungkinan telah berlalu. Untuk menyeimbangkan pandangan itu, kami menggunakan survei industri untuk bertanya kepada orang-orang di garis depan apa yang mereka lihat sebagai kelemahan penting yang mungkin belum ditunjukkan oleh data. +Penyusunan dari Top 10 ini lebih didorong oleh data daripada sebelumnya tetapi tidak membabi-buta didorong data. Kami memilih delapan dari sepuluh kategori dari kontribusi data dan 2 kategori dari survei komunitas Top 10 pada tingkat tinggi. Kami melakukan ini karena alasan mendasar, melihat data yang telah dikumpulkan sama dengan melihat ke masa lalu. Peneliti AppSec membutuhkan waktu untuk menemukan kerentanan baru dan cara-cara baru untuk mengujinya. Dibutuhkan waktu untuk mengintegrasikan tes ini ke dalam alat dan proses. Pada saat kita dapat dengan andal menguji kelemahan dalam skala, mungkin beberapa tahun telah berlalu. Untuk menyeimbangkan pandangan itu, kami menggunakan survei komunitas untuk bertanya kepada para pakar pengembangan dan keamanan aplikasi di garis depan, apa yang mereka lihat sebagai kelemahan penting yang mungkin belum ditunjukkan oleh data. Ada beberapa perubahan penting yang kami adopsi untuk terus mematangkan Top 10. -## Bagaimana kategori disusun +## Bagaimana kategori distrukturkan -Beberapa kategori telah berubah dari pemasangan OWASP Top 10 sebelumnya. Berikut adalah ringkasan tingkat tinggi dari perubahan kategori +Beberapa kategori telah berubah dari pemasangan OWASP Top 10 sebelumnya. Berikut adalah ringkasan tingkat tinggi dari perubahan kategori. -Upaya pengumpulan data sebelumnya difokuskan pada subset yang ditentukan sekitar 30 CWE dengan bidang yang meminta temuan tambahan. Kami mengetahui bahwa organisasi akan fokus hanya pada 30 CWE tersebut dan jarang menambahkan CWE tambahan yang mereka lihat. Dalam iterasi ini, kami membukanya dan hanya meminta data, tanpa batasan pada CWE. Kami meminta jumlah aplikasi yang diuji untuk tahun tertentu (mulai 2017), dan jumlah aplikasi dengan setidaknya satu contoh CWE yang ditemukan dalam pengujian. Format ini memungkinkan kami untuk melacak seberapa lazim setiap CWE dalam populasi aplikasi. Kami mengabaikan frekuensi untuk tujuan kami; sementara mungkin diperlukan untuk situasi lain, itu hanya menyembunyikan prevalensi aktual dalam populasi aplikasi. Apakah sebuah aplikasi memiliki empat instans CWE atau 4.000 instans bukanlah bagian dari perhitungan untuk 10 Besar. Kami beralih dari sekitar 30 CWE menjadi hampir 400 CWE untuk dianalisis dalam kumpulan data. Kami berencana untuk melakukan analisis data tambahan sebagai suplemen di masa depan. Peningkatan jumlah CWE yang signifikan ini memerlukan perubahan pada struktur kategori. +Upaya pengumpulan data sebelumnya difokuskan pada subset yang ditentukan dari sekitar 30 CWE dengan bidang yang meminta temuan tambahan. Kami mengetahui bahwa organisasi akan fokus hanya pada 30 CWE tersebut dan jarang menambahkan CWE lain yang mereka lihat. Dalam iterasi ini, kami membukanya dan hanya meminta data, tanpa batasan pada CWE. Kami meminta jumlah aplikasi yang diuji untuk tahun tertentu (mulai 2017), dan jumlah aplikasi dengan setidaknya satu contoh CWE yang ditemukan dalam pengujian. Format ini memungkinkan kami untuk melacak seberapa lazim setiap CWE dalam populasi aplikasi. Kami mengabaikan frekuensi untuk tujuan kami; sementara mungkin diperlukan untuk situasi lain, itu hanya menyembunyikan prevalensi aktual dalam populasi aplikasi. Apakah sebuah aplikasi memiliki empat instansi CWE atau 4.000 instansi bukanlah bagian dari perhitungan untuk Top 10. Kami berubah dari sekitar 30 CWE menjadi hampir 400 CWE untuk dianalisis dalam kumpulan data. Kami berrencana untuk melakukan analisis data tambahan sebagai suplemen di masa depan. Peningkatan jumlah CWE yang signifikan ini memerlukan perubahan pada bagaimana kategori distrukturkan. -Kami menghabiskan beberapa bulan untuk mengelompokkan dan mengkategorikan CWE dan dapat melanjutkannya selama beberapa bulan lagi. Kami harus berhenti di beberapa titik. Ada akar penyebab dan jenis gejala CWE, di mana jenis akar penyebab seperti "Kegagalan Kriptografis" dan "Kesalahan Konfigurasi" kontras dengan jenis gejala seperti "Pengungkapan Data Sensitif" dan "Penolakan Layanan." Kami memutuskan untuk fokus pada akar penyebab bila memungkinkan karena lebih logis untuk memberikan panduan identifikasi dan perbaikan. Berfokus pada akar penyebab di atas gejala bukanlah konsep baru; Sepuluh Besar telah menjadi campuran gejala dan akar penyebab. CWE juga merupakan campuran dari gejala dan akar penyebab; kami hanya menjadi lebih berhati-hati tentang hal itu dan menyebutnya. Ada rata-rata 19,6 CWE per kategori dalam pemasangan ini, dengan batas bawah pada 1 CWE untuk A10:2021-Server-Side Request Forgery (SSRF) hingga 40 CWE dalam A04:2021-Insecure Design. Struktur kategori yang diperbarui ini menawarkan manfaat pelatihan tambahan karena perusahaan dapat fokus pada CWE yang masuk akal untuk bahasa/kerangka kerja. +Kami menghabiskan beberapa bulan untuk mengelompokkan dan mengkategorikan CWE dan dapat melanjutkannya selama beberapa bulan lagi. Kami harus berhenti di beberapa titik. Ada tipe CWE *akar masalah* dan *gejala*, di mana jenis *akar masalah* adalah seperti "Kegagalan Kriptografis" dan "Kesalahan Konfigurasi" dibandingkan dengan jenis *gejala* seperti "Pengungkapan Data Sensitif" dan "Penolakan Layanan." Kami memutuskan untuk fokus pada *akar masalah* bila memungkinkan karena lebih logis untuk memberikan panduan identifikasi dan perbaikan. Berfokus pada *akar masalah* di atas *gejala* bukanlah konsep baru; Top 10 telah menjadi campuran *gejala* dan *akar masalah*. CWE juga merupakan campuran dari *gejala* dan *akar masalah*; kami hanya menjadi lebih berhati-hati tentang hal itu dan menyebutnya. Ada rata-rata 19,6 CWE per kategori dalam pemasangan ini, dengan batas bawah pada 1 CWE untuk **A10:2021-Server-Side Request Forgery (SSRF)** hingga 40 CWE dalam **A04:2021-Insecure Design**. Struktur kategori yang diperbarui ini menawarkan manfaat pelatihan tambahan karena perusahaan dapat fokus pada CWE yang masuk akal untuk bahasa/kerangka kerja. ## Bagaimana data digunakan untuk memilih kategori -Pada tahun 2017, kami memilih kategori berdasarkan tingkat insiden untuk menentukan kemungkinan, lalu memeringkatnya berdasarkan diskusi tim berdasarkan pengalaman puluhan tahun untuk Exploitability, Detectability (juga kemungkinan), dan Dampak Teknis. Untuk tahun 2021, kami ingin menggunakan data untuk Exploitability and Impact jika memungkinkan. +Pada tahun 2017, kami memilih kategori berdasarkan tingkat insiden untuk menentukan kemungkinan, lalu memeringkatnya menurut diskusi tim berdasarkan pengalaman puluhan tahun untuk *Exploitability, Detectability* (juga *kemungkinan*), dan *Dampak Teknis*. Untuk tahun 2021, kami ingin menggunakan data untuk *Exploitability* and *Impact (Teknis)* jika memungkinkan. Kami mengunduh Pemeriksaan Ketergantungan OWASP dan mengekstrak Eksploitasi CVSS, dan skor Dampak yang dikelompokkan berdasarkan CWE terkait. Butuh sedikit riset dan usaha karena semua CVE memiliki skor CVSSv2, tetapi ada kekurangan dalam CVSSv2 yang harus diatasi oleh CVSSv3. Setelah titik waktu tertentu, semua CVE juga diberi skor CVSSv3. Selain itu, rentang penilaian dan formula diperbarui antara CVSSv2 dan CVSSv3. -Di CVSSv2, Eksploitasi dan Dampak bisa mencapai 10,0, tetapi rumusnya akan menjatuhkannya hingga 60% untuk Eksploitasi dan 40% untuk Dampak. Di CVSSv3, maks secara teori dibatasi hingga 6,0 untuk Eksploitasi dan 4,0 untuk Dampak. Dengan mempertimbangkan pembobotan, skor Dampak bergeser lebih tinggi, rata-rata hampir satu setengah poin di CVSSv3, dan kemampuan eksploitasi turun rata-rata hampir setengah poin. +Di CVSSv2, *Eksploitasi* dan *Dampak (Teknis)* bisa mencapai 10,0, tetapi rumusnya akan menjatuhkannya hingga 60% untuk *Eksploitasi* dan 40% untuk *Dampak*. Di CVSSv3, maks secara teori dibatasi hingga 6,0 untuk *Eksploitasi* dan 4,0 untuk *Dampak*. Dengan mempertimbangkan pembobotan, skor Dampak bergeser lebih tinggi, rata-rata hampir satu setengah poin di CVSSv3, dan kemampuan eksploitasi turun rata-rata hampir setengah poin. -Ada 125 ribu catatan CVE yang dipetakan ke CWE dalam data NVD yang diekstraksi dari OWASP Dependency Check, dan ada 241 CWE unik yang dipetakan ke CVE. Peta CWE 62 ribu memiliki skor CVSSv3, yang kira-kira setengah dari populasi dalam kumpulan data. +Ada 125 ribu catatan CVE yang dipetakan ke CWE dalam data NVD yang diekstraksi dari OWASP Dependency Check, dan ada 241 CWE unik yang dipetakan ke CVE. 62 ribu peta CWE memiliki skor CVSSv3, yang kira-kira setengah dari populasi dalam kumpulan data. -Untuk Top 10, kami menghitung rata-rata skor eksploitasi dan dampak dengan cara berikut. Kami mengelompokkan semua CVE dengan skor CVSS berdasarkan CWE dan memberi bobot pada skor eksploitasi dan dampak berdasarkan persentase populasi yang memiliki skor CVSSv3 + populasi yang tersisa dari skor CVSSv2 untuk mendapatkan rata-rata keseluruhan. Kami memetakan rata-rata ini ke CWE dalam kumpulan data untuk digunakan sebagai skor Eksploitasi dan Dampak untuk separuh persamaan risiko lainnya. +Untuk Top 10 2021, kami menghitung rata-rata skor *eksploitasi* dan *dampak* dengan cara berikut. Kami mengelompokkan semua CVE dengan skor CVSS berdasarkan CWE dan memberi bobot pada skor *eksploitasi* dan *dampak* berdasarkan persentase populasi yang memiliki skor CVSSv3 + populasi yang tersisa dari skor CVSSv2 untuk mendapatkan rata-rata keseluruhan. Kami memetakan rata-rata ini ke CWE dalam kumpulan data untuk digunakan sebagai skor *Eksploitasi* dan *Dampak (Teknis)* untuk separuh persamaan risiko lainnya. -## Kenapa tidak hanya bersumber dari data statistik murni? +## Kenapa tidak hanya data statistik murni? -Hasil dalam data utamanya terbatas pada apa yang dapat kami uji secara otomatis. Bicaralah dengan seorang Profesional AppSec, dan mereka akan memberi tahu Anda tentang hal-hal yang mereka temukan dan tren yang mereka lihat yang belum ada dalam data. Dibutuhkan waktu bagi orang untuk mengembangkan metodologi pengujian untuk jenis kerentanan tertentu dan kemudian lebih banyak waktu agar pengujian tersebut diotomatisasi dan dijalankan terhadap populasi aplikasi yang besar. Semua yang kami temukan adalah melihat kembali ke masa lalu dan mungkin kehilangan tren dari tahun lalu, yang tidak ada dalam data. +Hasil dalam data utamanya terbatas pada apa yang dapat kami uji secara otomatis. Bicaralah dengan seorang Profesional AppSec yang berpengalaman, dan mereka akan memberi tahu Anda tentang hal-hal yang mereka temukan dan tren yang mereka lihat yang belum ada dalam data. Dibutuhkan waktu bagi orang untuk mengembangkan metodologi pengujian untuk jenis kerentanan tertentu dan kemudian lebih banyak waktu agar pengujian tersebut diotomatisasi dan dijalankan terhadap populasi aplikasi yang besar. Semua yang kami temukan adalah melihat kembali ke masa lalu dan mungkin kehilangan tren dari tahun lalu, yang tidak ada dalam data. -Oleh karena itu, kami hanya memilih delapan dari sepuluh kategori dari data karena tidak lengkap. Dua kategori lainnya berasal dari survei industri. Hal ini memungkinkan para praktisi di garis depan untuk memilih apa yang mereka lihat sebagai risiko tertinggi yang mungkin tidak ada dalam data (dan mungkin tidak pernah diungkapkan dalam data). +Oleh karena itu, kami hanya memilih delapan dari sepuluh kategori dari data karena tidak lengkap. Dua kategori lainnya berasal dari survei komunitas Top 10. Hal ini memungkinkan para praktisi di garis depan untuk memilih apa yang mereka lihat sebagai risiko tertinggi yang mungkin tidak ada dalam data (dan mungkin tidak akan pernah diungkapkan dalam data). -## Mengapa tingkatan insiden bukan bersumber dari frekuensi? +## Mengapa tingkatan insiden, bukan frekuensi? Ada tiga sumber data utama. Kami mengidentifikasi mereka sebagai Human-assisted Tooling (HaT), Tool-assisted Human (TaH), dan raw Tooling. Tooling dan HaT adalah generator pencarian frekuensi tinggi. Alat akan mencari kerentanan tertentu dan tanpa lelah berusaha untuk menemukan setiap contoh kerentanan itu dan akan menghasilkan jumlah temuan yang tinggi untuk beberapa jenis kerentanan. Lihatlah Cross-Site Scripting, yang biasanya merupakan salah satu dari dua rasa: itu kesalahan kecil yang terisolasi atau masalah sistemik. Jika ini merupakan masalah sistemik, jumlah temuan bisa mencapai ribuan untuk sebuah aplikasi. Frekuensi tinggi ini menenggelamkan sebagian besar kerentanan lain yang ditemukan dalam laporan atau data. -TaH, di sisi lain, akan menemukan jenis kerentanan yang lebih luas tetapi pada frekuensi yang jauh lebih rendah karena kendala waktu. Ketika manusia menguji aplikasi dan melihat sesuatu seperti Cross-Site Scripting, mereka biasanya akan menemukan tiga atau empat instance dan berhenti. Mereka dapat menentukan temuan sistemik dan menuliskannya dengan rekomendasi untuk diperbaiki pada skala aplikasi yang luas. Tidak perlu (atau waktu) untuk menemukan setiap contoh. -Misalkan kita mengambil dua kumpulan data yang berbeda ini dan mencoba menggabungkannya pada frekuensi. Dalam hal ini, data Tooling dan HaT akan menenggelamkan data TaH yang lebih akurat (tetapi luas) dan merupakan bagian yang baik dari mengapa sesuatu seperti Cross-Site Scripting memiliki peringkat yang sangat tinggi di banyak daftar ketika dampaknya umumnya rendah hingga sedang. Itu karena banyaknya temuan. (Cross-Site Scripting juga cukup mudah untuk diuji, jadi ada lebih banyak tes untuk itu juga). -Pada tahun 2017, kami memperkenalkan penggunaan tingkat insiden sebagai gantinya untuk melihat data baru dan menggabungkan data Tooling dan HaT dengan data TaH dengan rapi. Tingkat insiden menanyakan berapa persentase populasi aplikasi yang memiliki setidaknya satu contoh jenis kerentanan. Kami tidak peduli apakah itu satu kali atau sistemik. Itu tidak relevan untuk tujuan kita; kita hanya perlu mengetahui berapa banyak aplikasi yang memiliki setidaknya satu instance, yang membantu memberikan pandangan yang lebih jelas tentang pengujian temuan di beberapa jenis pengujian tanpa menenggelamkan data dalam hasil frekuensi tinggi. +TaH, di sisi lain, akan menemukan jenis kerentanan yang lebih luas tetapi pada frekuensi yang jauh lebih rendah karena kendala waktu. Ketika manusia menguji aplikasi dan melihat sesuatu seperti Cross-Site Scripting, mereka biasanya akan menemukan tiga atau empat instansi dan berhenti. Mereka dapat menentukan temuan sistemik dan menuliskannya dengan rekomendasi untuk diperbaiki pada skala seluruh aplikasi. Tidak ada kebutuhan (atau waktu) untuk menemukan setiap instansi. + +Misalkan kita mengambil dua kumpulan data yang berbeda ini dan mencoba menggabungkannya pada frekuensi. Dalam hal ini, data Tooling dan HaT akan menenggelamkan data TaH yang lebih akurat (tetapi luas) dan merupakan bagian yang baik dari mengapa sesuatu seperti Cross-Site Scripting memiliki peringkat yang sangat tinggi di banyak daftar ketika dampaknya umumnya rendah hingga sedang. Itu karena demikian banyaknya temuan. (Cross-Site Scripting juga cukup mudah untuk diuji, jadi ada lebih banyak tes untuk itu juga). + +Pada tahun 2017, kami memperkenalkan penggunaan tingkat insiden sebagai gantinya untuk melihat data baru dan menggabungkan data Tooling dan HaT dengan data TaH secara bersih. Tingkat insiden menanyakan berapa persentase populasi aplikasi yang memiliki setidaknya satu instansi jenis kerentanan. Kami tidak peduli apakah itu satu kali atau sistemik. Itu tidak relevan untuk tujuan kita; kita hanya perlu mengetahui berapa banyak aplikasi yang memiliki setidaknya satu instansi, yang membantu memberikan pandangan yang lebih jelas tentang pengujian temuan di beberapa jenis pengujian tanpa menenggelamkan data dalam hasil frekuensi tinggi. Ini sesuai dengan pandangan terkait risiko karena penyerang hanya membutuhkan satu instansi untuk menyerang aplikasi dengan sukses melalui kategori. ## Apa proses pengumpulan dan analisis data Anda? -Kami meresmikan proses pengumpulan data OWASP Top 10 di Open Security Summit pada 2017. Para Leader OWASP Top 10 dan komunitas telah menghabiskan dua hari untuk memformalkan proses pengumpulan data yang transparan. Edisi 2021 adalah kedua kalinya kami menggunakan metodologi ini. +Kami meresmikan proses pengumpulan data OWASP Top 10 di Open Security Summit pada 2017. Para leader OWASP Top 10 dan komunitas telah menghabiskan dua hari untuk memformalkan proses pengumpulan data yang transparan. Edisi 2021 adalah kedua kalinya kami menggunakan metodologi ini. + Kami mempublikasikan panggilan untuk data melalui saluran media sosial yang tersedia untuk kami, baik projek maupun OWASP. Pada halaman Projek OWASP, kami mencantumkan elemen dan struktur data yang kami cari dan cara mengirimkannya. Dalam proyek GitHub, kami memiliki file contoh yang berfungsi sebagai template. Kami bekerja dengan organisasi yang diperlukan untuk membantu mengetahui struktur dan pemetaan ke CWE. -Kami mendapatkan data dari organisasi yang menguji vendor berdasarkan perdagangan, vendor bug bounty, dan organisasi yang menyumbangkan data pengujian internal. Setelah kami memiliki data, kami memuatnya bersama dan menjalankan analisis fundamental tentang apa yang dipetakan CWE ke kategori risiko. Ada tumpang tindih antara beberapa CWE, dan yang lainnya sangat erat kaitannya (mis. Kerentanan kriptografis). Setiap keputusan yang terkait dengan data mentah yang dikirimkan didokumentasikan dan dipublikasikan agar terbuka dan transparan dengan cara kami menormalkan data. -Kami melihat delapan kategori dengan tingkat insiden tertinggi untuk dimasukkan dalam Top 10. Kami juga melihat hasil survei industri untuk melihat mana yang mungkin sudah ada dalam data. Dua suara teratas yang belum ada dalam data akan dipilih untuk dua tempat lainnya di Top 10. Setelah kesepuluh dipilih, kami menerapkan faktor umum untuk eksploitabilitas dan dampak; untuk membantu menentukan peringkat 10 Besar secara berurutan. +Kami mendapatkan data dari organisasi vendor pengujian, vendor bug bounty, dan organisasi yang menyumbangkan data pengujian internal. Setelah kami memiliki data, kami memuatnya bersama dan menjalankan analisis fundamental tentang apa yang dipetakan CWE ke kategori risiko. Ada tumpang tindih antara beberapa CWE, dan yang lainnya sangat erat kaitannya (mis. Kerentanan kriptografis). Setiap keputusan yang terkait dengan data mentah yang dikirimkan didokumentasikan dan dipublikasikan agar terbuka dan transparan dengan cara kami menormalkan data. + +Kami melihat delapan kategori dengan tingkat insiden tertinggi untuk dimasukkan dalam Top 10. Kami juga melihat hasil survei komunitas Top 10 untuk melihat mana yang mungkin sudah ada dalam data. Dua suara teratas yang belum ada dalam data akan dipilih untuk dua tempat lainnya di Top 10. Setelah sepuluh dipilih, kami menerapkan faktor umum untuk eksploitabilitas dan dampak; untuk membantu menentukan peringkat Top 10 2021 dalam urutan berbasis risiko. ## Faktor-faktor Data Ada data faktor yang dicantumkan untuk masing-masing dari 10 Kategori Teratas, berikut artinya: -- CWEs Mapped: Jumlah CWE yang dipetakan ke kategori oleh 10 tim teratas. -- Incidence Rate: Tingkat insiden adalah persentase aplikasi yang rentan terhadap CWE tersebut dari populasi yang diuji oleh organisasi tersebut untuk tahun tersebut. -- (Pengujian) Cakupan: Persentase aplikasi yang diuji oleh semua organisasi untuk CWE tertentu. -- Weighted Exploit: Sub-skor Eksploitasi dari skor CVSSv2 dan CVSSv3 yang ditetapkan ke CVE yang dipetakan ke CWE, dinormalisasi, dan ditempatkan pada skala 10pt. -- Weighted Impact: Sub-skor Dampak dari skor CVSSv2 dan CVSSv3 yang ditetapkan ke CVE dipetakan ke CWE, dinormalisasi, dan ditempatkan pada skala 10pt. +- CWE Dipetakan: Jumlah CWE yang dipetakan ke kategori oleh tim Top 10. +- Laju Insidensi: Tingkat insiden adalah persentase aplikasi yang rentan terhadap CWE tersebut dari populasi yang diuji oleh organisasi tersebut untuk tahun tersebut. +- Cakupan (Pengujian): Persentase aplikasi yang diuji oleh semua organisasi untuk CWE tertentu. +- Ekslpoitasi Terbobot: Sub-skor Eksploitasi dari skor CVSSv2 dan CVSSv3 yang ditetapkan ke CVE yang dipetakan ke CWE, dinormalisasi, dan ditempatkan pada skala 10. +- Dampak Terbobot: Sub-skor Dampak dari skor CVSSv2 dan CVSSv3 yang ditetapkan ke CVE dipetakan ke CWE, dinormalisasi, dan ditempatkan pada skala 10. - Total Kejadian: Jumlah total aplikasi yang ditemukan memiliki CWE yang dipetakan ke suatu kategori. - Total CVE: Jumlah total CVE dalam NVD DB yang dipetakan ke CWE yang dipetakan ke suatu kategori. -### Hubungan Kategori dari 2017 - -Ada banyak pembicaraan tentang tumpang tindih antara risiko Top 10. Menurut definisi masing-masing (daftar CWE yang termasuk), sebenarnya tidak ada tumpang tindih. Namun, secara konseptual, dapat terjadi tumpang tindih atau interaksi berdasarkan penamaan tingkat yang lebih tinggi. Diagram Venn berkali-kali digunakan untuk menunjukkan tumpang tindih seperti ini. - -Diagram Venn di atas merepresentasikan interaksi antara Sepuluh Kategori Risiko Teratas 2017. Saat melakukannya, beberapa poin penting menjadi jelas: - -1. Orang bisa berargumen bahwa Cross-Site Scripting pada akhirnya termasuk dalam Injeksi karena pada dasarnya adalah Injeksi Konten. Melihat data tahun 2021, semakin jelas bahwa XSS perlu pindah ke Injeksi. -2. Tumpang tindih hanya satu arah. Kita akan sering mengklasifikasikan kerentanan berdasarkan manifestasi akhir atau "gejala", bukan akar penyebab (yang berpotensi dalam). Misalnya, "Pengungkapan Data Sensitif" mungkin merupakan hasil dari "Kesalahan Konfigurasi Keamanan"; namun, Anda tidak akan melihatnya ke arah lain. Akibatnya, panah digambar di zona interaksi untuk menunjukkan arah mana itu terjadi. -3. Terkadang diagram ini digambar dengan semua yang ada di A06:2021 Menggunakan Komponen dengan Kerentanan yang Diketahui. Sementara beberapa kategori risiko ini mungkin menjadi akar penyebab kerentanan pihak ketiga, mereka umumnya dikelola secara berbeda dan dengan tanggung jawab yang berbeda. Jenis lainnya biasanya mewakili risiko pihak pertama. - -### Terima kasih kepada kontributor data kami +## Terima kasih kepada kontributor data kami Organisasi berikut (bersama dengan beberapa donor anonim) dengan baik hati menyumbangkan data untuk lebih dari 500.000 aplikasi untuk menjadikan ini kumpulan data keamanan aplikasi terbesar dan terlengkap. Tanpa Anda, ini tidak akan mungkin. @@ -111,3 +107,11 @@ Organisasi berikut (bersama dengan beberapa donor anonim) dengan baik hati menyu - Sqreen - Veracode - WhiteHat (NTT) + +## Terima kasih kepada sponsor kami + +Tim OWASP Top 10 2021 berterimakasih atas dukungan finansial dari Secure Code Warrior dan Just Eat. + +[![Secure Code Warrior](assets/securecodewarrior.png){ width="256" }](https://securecodewarrior.com) + +[![Just Eat](assets/JustEat.png){ width="256" }](https://www.just-eat.co.uk) diff --git a/2021/docs/A01_2021-Broken_Access_Control.id.md b/2021/docs/A01_2021-Broken_Access_Control.id.md index 5b2a4e52b..bd9c391b1 100644 --- a/2021/docs/A01_2021-Broken_Access_Control.id.md +++ b/2021/docs/A01_2021-Broken_Access_Control.id.md @@ -1,73 +1,115 @@ -# A01:2021 – Kerusakan Akses Kontrol +# A01:2021 – Kontrol Akses yang Rusak ![icon](assets/TOP_10_Icons_Final_Broken_Access_Control.png){: style="height:80px;width:80px" align="right"} ## Faktor-Faktor -| Klasifikasi CWE | Tingkat Kejadian Maksimum | Rata - Rata Tingkat kejadian | Cakupan Maksimum | Rata - Rata Cakupan | Rata-rata Bobot Eksploitasi | Rata - Rata Bobot Dampak | Total Kejadian | Total CVEs | -| :---------: | :----------------: | :----------------------: | :----------: | :----------------: | :------------------------: | :-----------------------: | :------------: | :--------: | -| 34 | 55.97% | 3.81% | 94.55% | 47.72% | 6.92 | 5.93 | 318,487 | 19,013 | +| CWE Dipetakan | Tingkat Kejadian Maksimum | Rata-Rata Tingkat Kejadian | Cakupan Maksimum | Rata-Rata Cakupan | Rata-rata Bobot Eksploitasi | Rata-Rata Bobot Dampak | Total Kejadian | Total CVE | +| :---------: | :----------------: | :----------------------: | :----------: | :----------------: | :------------------------: | :-----------------------: | :------------: | :--------: | +| 34 | 55,97% | 3,81% | 94,55% | 47,72% | 6,92 | 5,93 | 318.487 | 19.013 | ## Gambaran -Bergerak ke atas dari posisi ke 5, 94% aplikasi di tes untuk untuk berbagai jenis dari broken access control. CWE (Common Weakness Enumeration) atau kelemahan enumerasi umum yang perlu diperhatikan termasuk dari _CWE-200: Exposure of Sensitive Information to an Unauthorized Actor_, _CWE-201: Exposure of Sensitive Information Through Sent Data_, and _CWE-352: Cross-Site Request Forgery_. +Bergerak ke atas dari posisi ke 5, 94% aplikasi diuji untuk untuk berbagai jenis +dari broken access control. CWE (Common Weakness Enumeration) atau kelemahan +enumerasi umum yang perlu diperhatikan termasuk dari _CWE-200: Exposure of +Sensitive Information to an Unauthorized Actor_, _CWE-201: Exposure of Sensitive +Information Through Sent Data_, dan _CWE-352: Cross-Site Request Forgery_. ## Deskripsi -Akses Kontrol menetapkan sebuah peraturan yang dimana user tidak dapat melakukan sebuah aksi diluar permission yang diberikan. Kegagalan atas hal ini dapat mengakibatkan pengeluaran informasi yang tidak diizinkan, modifikasi, atau penghancuran dari semua data atau pemberlakuan sebuah fungsi bisnis di luar limit sebuah user. Kelemahan Akses Kontrol termasuk dari : +Kontrol akses memberlakukan sebuah kebijalan sedemikian rupa sehingga pengguna +tidak dapat bertindak di luar izin yang dimaksudkan. Kegagalan biasanya mengarah +pada pengungkapan informasi yang tidak diizinkan, modifikasi, atau penghancuran +dari semua data atau menjalankan sebuah fungsi bisnis di luar batas pengguna. +Kelemahan umum kontrol akses termasuk: -Melewati pengecekan akses kontrol dengan memodifikasi URL, internal application state, atau HTML page, atau menggunakan custom API attack tool. +- Pelanggaran prinsip privilese terkecil (least privilege) atau penolakan baku + (deny by default), dimana akses semestinya hanya diberikan untuk + kapabilitas, peran, atau pengguna tertentu, tapi tersedia untuk siapa pun. -Membolehkan primary key untuk dapat diganti ke record user lain, membolehkan penglihatan atau perubahan akun orang lain. +- Melewati pengecekan kontrol akses dengan memodifikasi URL (parameter + tampering atau force browsing), state aplikasi internal, atau halaman HTML, + atau menggunakan alat serang yang memodifikasi permintaan API. -Penaikan sebuah privilege (Elevation Privilege). Yang dimana sebuah orang dapat dianggap sebagai user tanpa melakukan logged in dan yang dimana sebuah user dapat dianggap sebagai admin tanpa melakukan logged in. +- Mengizinkan melihat atau mengedit akun orang lain, dengen menyediakan + identifier uniknya (insecure direct object references). -Manipulasi metadata, seperti memanipulasi dengan JSON Web Token (JWT) akses kontrol token, atau memanipulasi cookie atau hidden field untuk menaikan privilege (elevation privilege) atau menyalahgunakan penggunaan dari JWT invalidation. +- Mengakses API dengan kontrol akses yang kurang untuk POST, PUT dan DELETE. -Konfigurasi yang salah pada CORS sehingga menyebabkan API akses yang tidak diizinkan. +- Penaikan sebuah privilese (Elevation of privilege). Bertindak sebagai + seorang pengguna tanpa login atau bertindak sebagai seorang admin ketika + login sebagai pengguna. -Force browsing untuk mengakses authenticated pages sebagai unauthenticated user atau mengakses privileged pages sebagai user standard. Mengakses API yang tidak memiliki akses kontrol untuk POST, PUT, dan DELETE. +- Manipulasi metadata, seperti memakai ulang atau mengubah token kontrol akses + JSON Web Token (JWT), atau memanipulasi cookie atau hidden field untuk + menaikan privilese (elevation privilege) atau menyalahgunakan JWT + invalidation. -## Cara Mencegah - -Akses Kontrol hanya efektif pada kode server-side yang dapat dipercaya dan server-less API, yang dimana penyerang tidak dapat memodifikasi pengecek akses kontrol atau meta datanya. +- Salah konfigurasi CORS sehingga mengizinkan akses API dari asal yang tidak + terotorisasi/tak terpercaya. -- Menolak semua akses kecuali ke public resource. +- Force browsing untuk mengakses halaman terotentikasi sebagai pengguna tak + terotentikasi atau mengakses privileged pages sebagai pengguna standar. -- Melakukan implementasi mekanisme akses kontrol sekali dan digunakan kembali pada seluruh aplikasi sehingga meminimalisir penggunaan CORS. +## Cara Mencegah -- Agar user tidak dapat melakukan create, read, update, atau mendelete record secara bebas, model akses kontrol seharusnya membatasi hal tersebut dengan menggunakan ownership untuk tiap record. +Kontrol akses hanya efektif pada kode server-side yang dapat dipercaya atau +server-less API, dimana penyerang tidak dapat memodifikasi pemeriksaan kontrol +akses atau meta data. -- Batas yang diperlukan oleh bisnis yang unik pada aplikasi seharusnya dilakukan oleh domain models. +- Menolak semua akses kecuali ke sumber daya publik. -- Nonaktifkan direktori listing web server dan pastikan file metadata (contohnya .git) dan file backup tidak ada di dalam web roots. +- Melakukan implementasi mekanisme kontrol akses sekali dan digunakan kembali + pada seluruh aplikasi sehingga meminimalisir penggunaan Cross-Origin Resource + Sharing (CORS). -- Catat kegagalan akses kontrol dan alert admin jika diperlukan (seperti adanya kegagalan yang terjadi berulang - ulang). +- Agar user tidak dapat melakukan create, read, update, atau delete record + secara bebas, model kontrol akses seharusnya membatasi hal tersebut dengan + menggunakan ownership untuk tiap record. -- Ukur batasan dari API dan akses ke kontroler untuk meminimalisir kerusakan dari automated attack tooling. +- Batas yang diperlukan oleh bisnis yang unik pada aplikasi seharusnya dilakukan + oleh domain models. -- JWT tokens harus langsung di hilangkan validasinya pada server setelah logout. +- Nonaktifkan direktori listing web server dan pastikan file metadata (contohnya + .git) dan file backup tidak ada di dalam web root. -Developers and QA staff should include functional access control unit -and integration tests. +- Catat kegagalan kontrol akses dan alert admin jika diperlukan (seperti + kegagalan berulang). -## Contoh Skenario Penyerangan +- Batasi laju akses kontroler dan API untuk meminimalisir kerusakan dari + automated attack tooling. -**Skenario #1:** Aplikasi menggunakan data yang belum diverifikasi pada sebuah pemanggilan SQL yang mengakses informasi akun +- Identifier sesi stateful mesti di-invalidasi pada server setelah logout. + Token JWT stateless mesti agak berumur pendek sehingga jendela kesempatan + bagi penyerang diminimalkan. Untuk JWT yang berumur lebih panjang sangat + disarankan untuk mengikuti standar OAuth untuk mencabut akses. -> pstmt.setString(1, request.getParameter("acct")); -> -> ResultSet results = pstmt.executeQuery( ); +Pengembang dan staf QA mesti menyertakan unit kontrol akses fungsional dan uji +integrasi. -Penyerang hanya perlu untuk memodifikasi parameter ‘acct’ pada browser untuk mengirim nomer akun mana yang diinginkan. Jika parameter tersebut tidak diverifikasi secara benar, maka penyerang dapat mengakses akun user manapun. +## Contoh Skenario Penyerangan +**Skenario #1:** Aplikasi menggunakan data yang belum diverifikasi pada sebuah +pemanggilan SQL yang mengakses informasi akun: +``` + pstmt.setString(1, request.getParameter("acct")); + ResultSet results = pstmt.executeQuery( ); +``` +Penyerang hanya perlu untuk memodifikasi parameter ‘acct’ pada browser untuk +mengirim nomor akun mana yang diinginkan. Jika tidak diverifikasi secara benar, +maka penyerang dapat mengakses akun user mana pun. +``` https://example.com/app/accountInfo?acct=notmyacct - -**Skenario #2:** Penyerang dapat memaksa untuk melakukan penjelajahan ke target URLs. Halaman Admin memerlukan hak admin untuk dapat diakses. - -> https://example.com/app/getappInfo -> -> https://example.com/app/admin_getappInfo - -Jika sebuah user yang belum di autentikasi dapat mengakses kedua page tersebut maka itu merupakan suatu kelemahan. Jika user yang non-admin dapat mengakses halaman admin, maka merupakan suatu kelemahan. +``` +**Skenario #2:** Penyerang dapat memaksa untuk melakukan penjelajahan ke URL +target. Hak admin diperlukan untuk mengakses halaman admin. +``` +https://example.com/app/getappInfo +https://example.com/app/admin_getappInfo +``` + +Jika sebuah user yang belum diautentikasi dapat mengakses kedua halaman tersebut +maka itu merupakan suatu kelemahan. Jika user yang non-admin dapat mengakses +halaman admin, maka merupakan suatu kelemahan. ## Referensi @@ -83,10 +125,10 @@ Jika sebuah user yang belum di autentikasi dapat mengakses kedua page tersebut m - [PortSwigger: Exploiting CORS misconfiguration](https://portswigger.net/blog/exploiting-cors-misconfigurations-for-bitcoins-and-bounties) -## Daftar Klasifikasi CWE +## Daftar CWE Dipetakan -CWE-22 Improper Limitation of a Pathname to a Restricted Directory -('Path Traversal') +CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path +Traversal') CWE-23 Relative Path Traversal @@ -100,8 +142,7 @@ CWE-201 Exposure of Sensitive Information Through Sent Data CWE-219 Storage of File with Sensitive Data Under Web Root -CWE-264 Permissions, Privileges, and Access Controls (should no longer -be used) +CWE-264 Permissions, Privileges, and Access Controls (should no longer be used) CWE-275 Permission Issues @@ -113,23 +154,21 @@ CWE-285 Improper Authorization CWE-352 Cross-Site Request Forgery (CSRF) -CWE-359 Exposure of Private Personal Information to an Unauthorized -Actor +CWE-359 Exposure of Private Personal Information to an Unauthorized Actor CWE-377 Insecure Temporary File -CWE-402 Transmission of Private Resources into a New Sphere ('Resource -Leak') +CWE-402 Transmission of Private Resources into a New Sphere ('Resource Leak') CWE-425 Direct Request ('Forced Browsing') CWE-441 Unintended Proxy or Intermediary ('Confused Deputy') -CWE-497 Exposure of Sensitive System Information to an Unauthorized -Control Sphere +CWE-497 Exposure of Sensitive System Information to an Unauthorized Control +Sphere -CWE-538 Insertion of Sensitive Information into Externally-Accessible -File or Directory +CWE-538 Insertion of Sensitive Information into Externally-Accessible File or +Directory CWE-540 Inclusion of Sensitive Information in Source Code diff --git a/2021/docs/A02_2021-Cryptographic_Failures.id.md b/2021/docs/A02_2021-Cryptographic_Failures.id.md index 3f71425a0..4f2e0184f 100644 --- a/2021/docs/A02_2021-Cryptographic_Failures.id.md +++ b/2021/docs/A02_2021-Cryptographic_Failures.id.md @@ -1,15 +1,15 @@ -# A02:2021 – Kegagalan Kriptografi +# A02:2021 – Kegagalan Kriptografi ![icon](assets/TOP_10_Icons_Final_Crypto_Failures.png){: style="height:80px;width:80px" align="right"} ## Faktor-Faktor -| Klasifikasi CWE | Tingkat Kejadian Maksimum | Rata-rata Tingkat kejadian | Cakupan Maksimum | Rata-rata Cakupan | Rata-rata Bobot Eksploitasi | Rata-rata Bobot Dampak | Total Kejadian | Total CVEs | +| CWE Dipetakan | Tingkat Kejadian Maksimum | Rata-rata Tingkat kejadian | Rata-rata Eksploitasi Terbobot | Rata-rata Dampak Terbobot | Cakupan Maks | Rata-rata Cakupan | Total Kejadian | Total CVE | |:-------------:|:--------------------:|:--------------------:|:--------------:|:--------------:|:----------------------:|:---------------------:|:-------------------:|:------------:| -| 29 | 46.44% | 4.49% | 79.33% | 34.85% | 7.29 | 6.81 | 233,788 | 3,075 | +| 29 | 46,44% | 4,49% | 7,29 | 6,81 | 79,33% | 34,85% | 233.788 | 3.075 | ## Ikhtisar Bergeser satu posisi ke #2, sebelumnya dikenal sebagai *Sensitive Data -Exposure*, yang lebih merupakan gejala yang luas daripada akar penyebab, +Exposure*, yang lebih merupakan gejala yang luas daripada akar masalah, fokusnya adalah kegagalan yang terkait dengan kriptografi (atau ketiadaannya), yang sering menyebabkan paparan data sensitif. CWE terkenal yang disertakan adalah *CWE-259: Use of Hard-coded Password*, *CWE-327: Broken or Risky @@ -25,23 +25,48 @@ misalnya, General Data Protection Regulation (GDPR) Uni Eropa, atau peraturan, misalnya, perlindungan data keuangan seperti PCI Data Security Standard (PCI DSS). Untuk semua data tersebut: -- Apakah ada data yang dikirimkan dalam bentuk teks yang jelas? - ini menyangkut protokol seperti HTTP, SMTP, and FTP. Lalu lintas internet - luar yang berbahaya. Verifikasi semua lalu lintas yang ada di internal, - misalnya antara penyeimbang beban, server web, atau sistem back-end. +- Apakah ada data yang dikirimkan dalam bentuk teks polos? + Ini menyangkut protokol seperti HTTP, SMTP, FTP dan memakai peningkatan TLS + seperti STARTTLS. Lalu lintas internet eksternal itu berbahaya. Verifikasi + semua lalu lintas yang ada di internal, misalnya antara load balancer, + server web, atau sistem back-end. - Apakah ada algoritma kriptografi lama atau lemah yang digunakan baik secara default atau dalam kode yang lebih lama? - Apakah kunci kripto bawaan sedang digunakan, kunci kripto yang lemah dihasilkan atau digunakan kembali, - atau apakah kurangnya manajemen atau rotasi kunci yang tepat? + atau apakah kurangnya manajemen atau rotasi kunci yang tepat? Apakah kunci + kripto dimasukkan ke dalam repositori kode sumber? -- Apakah enkripsi tidak diterapkan, misalnya, apakah ada agen pengguna (browser) - yang arahan atau header keamanan hilang? +- Apakah enkripsi tidak dipaksakan, misalnya, apakah header atau direktif + keamanan browser HTTP ada yang kurang? -- Apakah agen pengguna (misalnya, aplikasi, klien email) tidak memverifikasi jika - sertifikat yang diterima server valid? +- Apakah sertifikat server yang diterima dan rantai kepercayaan divalidasi + secara tepat? + +- Apakah vektor inisialisasi diabaikan, dipakai ulang, atau tidak + dibangkitkan secara cukup aman bagi mode operasi kriptografis? Apakah + mode operasi yang tidak aman seperti ECB dipakai? Apakah enkripsi dipakai + ketika enkripsi terautentikasi lebih sesuai? + +- Apakah kata sandi dipakai sebagai kunci kriptografis karena ketiadaan + fungsi penurunan kunci basis kata sandi? + +- Apakah keacakan yang dipakai untuk tujuan kriptografis tidak dirancang + untuk memenuhi persyaratan kriptografis? Bahkan bila fungsi yang benar + dipilih, apakah itu perlu di-seed oleh pengembang, dan bila tidak, apakah + pengembang menimpa fungsionalitas seed kuat yang dibangun ke dalamnya + dengan suatu seed yang kurang cukup entropi/ketidak-tertebakan? + +- Apakah fungsi hash usang seperti MD5 atau SHA1 dipakai, atau apakah fungsi + hash non kriptografis dipakai ketika fungsi hash kriptografsi diperlukan? + +- Apakah metoda padding kriptografis yang usang seperti PKCS no 1 v1.5 + dipakai? + +- Apakah pesan kesalahan kriptografis atau informasi side channel dapat + dieksploitasi, misalnya dalam bentuk serangan padding oracle? Lihat ASVS Crypto (V7), Data Protection (V9), dan SSL/TLS (V10) @@ -51,30 +76,55 @@ Lakukan minimal hal berikut, dan lihat referensi: - Mengklasifikasikan data yang diproses, disimpan, atau dikirim oleh aplikasi. Identifikasi data mana yang sensitif menurut undang-undang privasi, - persyaratan peraturan, atau kebutuhan bisnis. + persyaratan regulasi, atau kebutuhan bisnis. -- Tetapkan kontrol sesuai klasifikasi. - -- Jangan menyimpan data sensitif yang tidak perlu. Buang sesegera - mungkin atau gunakan tokenisasi yang sesuai dengan PCI DSS atau bahkan pemotongan. +- Jangan menyimpan data sensitif yang tidak perlu. Buang sesegera mungkin + atau gunakan tokenisasi yang sesuai dengan PCI DSS atau bahkan pemotongan. Data yang tidak disimpan tidak dapat dicuri. - Pastikan untuk mengenkripsi semua data sensitif saat istirahat. -- Pastikan gunakan standar algoritma, protokol yang mutakhir dan kuat, serta - kunci berada pada tempatnya; menggunakan manajemen kunci yang tepat. +- Pastikan standar algoritma, protokol, dan kunci yang mutakhir dan kuat dipakai; + gunakan manajemen kunci yang tepat. - Enkripsi semua data dalam perjalanan dengan protokol aman seperti TLS dengan - cipher perfect forward secrecy (PFS), prioritas cipher oleh - server, dan parameter yang aman. Terapkan enkripsi menggunakan arahan - seperti HTTP Strict Transport Security (HSTS). + cipher forward secrecy (FS), penentuan prioritas cipher oleh server, dan + parameter yang aman. Paksakan enkripsi menggunakan direktif seperti HTTP + Strict Transport Security (HSTS). - Menonaktifkan caching untuk respons yang berisi data sensitif. +- Tetapkan kontrol keamanan yang diperlukan sesuai klasifikasi data. + +- Jangan memakai protokol warisan (legacy) seperti FTP dan SMTP untuk + mengirim data sensitif. + - Simpan kata sandi menggunakan fungsi hashing adaptif dan salted yang kuat dengan faktor kerja (faktor penundaan), seperti Argon2, scrypt, bcrypt, atau PBKDF2. +- Vektor inisialisasi (IV, initialization vector) mesti dipilih yang sesuai + bagi mode operasi. Untuk banyak mode, ini berarti memakai suatu CSPRNG + (cryptographically secure pseudo random number generator). Untuk mode-mode + yang memerlukan suatu nonce, maka IV tidak memerlukan sebuah CSPRNG. Dalam + semua kasus, IV tidak boleh dipakai dipakai dua kali untuk sebuah kunci + tetap. + +- Selalu gunakan enkripsi terautentikasi bukan hanya enkripsi. + +- Kunci mesti dibuat secara kriptografis acak dan disimpan di memori sebagai + larik byte. Bila suatu kata sandi dipakai, maka itu mesti dikonversi ke + suatu kunci melalui sebuah fungsi penurunan kunci basis kata sandi yang + tepat. + +- Pastikan bahwa keacakan kriptografis dipakai dimana sesuai, dan itu tidak + di-seed dalam suatu cara yang dapat diprediksi atau dengan entropi rendah. + Kebanyakan API modern tidak memerlukan pengembang men-seed CSPRNG untuk + memperoleh keamanan. + +- Hindari fungsi kriptografis dan skema padding yang usang, seperti misalnya + MD5, SHA1, PKCS no 1 v1.5. + - Verifikasi secara independen efektivitas konfigurasi dan pengaturan. ## Contoh Skenario Serangan @@ -87,15 +137,15 @@ mengambil nomor kartu kredit dalam teks polos. **Skenario #2**: Situs tidak menggunakan atau menerapkan TLS untuk semua halaman atau mendukung enkripsi yang lemah. Penyerang memantau lalu lintas jaringan (misalnya, di jaringan nirkabel yang tidak aman), menurunkan versi koneksi dari HTTPS ke -HTTP, memotong permintaan, dan mencuri cookie sesi pengguna. -Penyerang kemudian replay cookie ini dan membajak pengguna sesi (dikonfirmasi), mengakses -atau memodifikasi data pribadi pengguna. Alih-alih di atas, +HTTP, mengintersepsi permintaan, dan mencuri cookie sesi pengguna. +Penyerang kemudian replay cookie ini dan membajak sesi pengguna (yang terautentikasi), +mengakses atau memodifikasi data pribadi pengguna. Alih-alih di atas, mereka dapat mengubah semua data yang diangkut, misalnya, penerima -mentransfer uang. +dari suatu transfer uang. **Skenario #3**: Kata sandi pada database menggunakan hash tanpa salt atau sederhana untuk menyimpan kata sandi semua orang. Cacat unggah file memungkinkan penyerang untuk -mengambil basis data kata sandi. Semua unsalted hashes dapat diekspos +mengambil basis data kata sandi. Semua unsalted hash dapat diekspos dengan tabel pelangi dari hash yang telah dihitung sebelumnya. Hash yang dihasilkan oleh fungsi hash sederhana atau cepat dapat dipecahkan oleh GPU, meskipun telah di-salt. @@ -114,73 +164,69 @@ di-salt. - [OWASP Cheat Sheet: User Privacy Protection](https://cheatsheetseries.owasp.org/cheatsheets/User_Privacy_Protection_Cheat_Sheet.html) -- OWASP Cheat Sheet: Password and Cryptographic Storage +- [OWASP Cheat Sheet: Password and Cryptographic Storage](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html) - [OWASP Cheat Sheet: HSTS](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html) -- OWASP Testing Guide: Testing for weak cryptography - +- [OWASP Testing Guide: Testing for weak cryptography](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/09-Testing_for_Weak_Cryptography/README) ## Daftar Klasifikasi CWE -CWE-261 Weak Encoding for Password +[CWE-261 Weak Encoding for Password](https://cwe.mitre.org/data/definitions/261.html) -CWE-296 Improper Following of a Certificate's Chain of Trust +[CWE-296 Improper Following of a Certificate's Chain of Trust](https://cwe.mitre.org/data/definitions/296.html) -CWE-310 Cryptographic Issues +[CWE-310 Cryptographic Issues](https://cwe.mitre.org/data/definitions/310.html) -CWE-319 Cleartext Transmission of Sensitive Information +[CWE-319 Cleartext Transmission of Sensitive Information](https://cwe.mitre.org/data/definitions/319.html) -CWE-321 Use of Hard-coded Cryptographic Key +[CWE-321 Use of Hard-coded Cryptographic Key](https://cwe.mitre.org/data/definitions/321.html) -CWE-322 Key Exchange without Entity Authentication +[CWE-322 Key Exchange without Entity Authentication](https://cwe.mitre.org/data/definitions/322.html) -CWE-323 Reusing a Nonce, Key Pair in Encryption +[CWE-323 Reusing a Nonce, Key Pair in Encryption](https://cwe.mitre.org/data/definitions/323.html) -CWE-324 Use of a Key Past its Expiration Date +[CWE-324 Use of a Key Past its Expiration Date](https://cwe.mitre.org/data/definitions/324.html) -CWE-325 Missing Required Cryptographic Step +[CWE-325 Missing Required Cryptographic Step](https://cwe.mitre.org/data/definitions/325.html) -CWE-326 Inadequate Encryption Strength +[CWE-326 Inadequate Encryption Strength](https://cwe.mitre.org/data/definitions/326.html) -CWE-327 Use of a Broken or Risky Cryptographic Algorithm +[CWE-327 Use of a Broken or Risky Cryptographic Algorithm](https://cwe.mitre.org/data/definitions/327.html) -CWE-328 Reversible One-Way Hash +[CWE-328 Reversible One-Way Hash](https://cwe.mitre.org/data/definitions/328.html) -CWE-329 Not Using a Random IV with CBC Mode +[CWE-329 Not Using a Random IV with CBC Mode](https://cwe.mitre.org/data/definitions/329.html) -CWE-330 Use of Insufficiently Random Values +[CWE-330 Use of Insufficiently Random Values](https://cwe.mitre.org/data/definitions/330.html) -CWE-331 Insufficient Entropy +[CWE-331 Insufficient Entropy](https://cwe.mitre.org/data/definitions/331.html) -CWE-335 Incorrect Usage of Seeds in Pseudo-Random Number Generator -(PRNG) +[CWE-335 Incorrect Usage of Seeds in Pseudo-Random Number Generator(PRNG)](https://cwe.mitre.org/data/definitions/335.html) -CWE-336 Same Seed in Pseudo-Random Number Generator (PRNG) +[CWE-336 Same Seed in Pseudo-Random Number Generator (PRNG)](https://cwe.mitre.org/data/definitions/336.html) -CWE-337 Predictable Seed in Pseudo-Random Number Generator (PRNG) +[CWE-337 Predictable Seed in Pseudo-Random Number Generator (PRNG)](https://cwe.mitre.org/data/definitions/337.html) -CWE-338 Use of Cryptographically Weak Pseudo-Random Number Generator -(PRNG) +[CWE-338 Use of Cryptographically Weak Pseudo-Random Number Generator(PRNG)](https://cwe.mitre.org/data/definitions/338.html) -CWE-340 Generation of Predictable Numbers or Identifiers +[CWE-340 Generation of Predictable Numbers or Identifiers](https://cwe.mitre.org/data/definitions/340.html) -CWE-347 Improper Verification of Cryptographic Signature +[CWE-347 Improper Verification of Cryptographic Signature](https://cwe.mitre.org/data/definitions/347.html) -CWE-523 Unprotected Transport of Credentials +[CWE-523 Unprotected Transport of Credentials](https://cwe.mitre.org/data/definitions/523.html) -CWE-720 OWASP Top Ten 2007 Category A9 - Insecure Communications +[CWE-720 OWASP Top Ten 2007 Category A9 - Insecure Communications](https://cwe.mitre.org/data/definitions/720.html) -CWE-757 Selection of Less-Secure Algorithm During Negotiation -('Algorithm Downgrade') +[CWE-757 Selection of Less-Secure Algorithm During Negotiation('Algorithm Downgrade')](https://cwe.mitre.org/data/definitions/757.html) -CWE-759 Use of a One-Way Hash without a Salt +[CWE-759 Use of a One-Way Hash without a Salt](https://cwe.mitre.org/data/definitions/759.html) -CWE-760 Use of a One-Way Hash with a Predictable Salt +[CWE-760 Use of a One-Way Hash with a Predictable Salt](https://cwe.mitre.org/data/definitions/760.html) -CWE-780 Use of RSA Algorithm without OAEP +[CWE-780 Use of RSA Algorithm without OAEP](https://cwe.mitre.org/data/definitions/780.html) -CWE-818 Insufficient Transport Layer Protection +[CWE-818 Insufficient Transport Layer Protection](https://cwe.mitre.org/data/definitions/818.html) -CWE-916 Use of Password Hash With Insufficient Computational Effort +[CWE-916 Use of Password Hash With Insufficient Computational Effort](https://cwe.mitre.org/data/definitions/916.html) diff --git a/2021/docs/A03_2021-Injection.id.md b/2021/docs/A03_2021-Injection.id.md index 89cffb22e..2f09dcc72 100644 --- a/2021/docs/A03_2021-Injection.id.md +++ b/2021/docs/A03_2021-Injection.id.md @@ -1,72 +1,93 @@ -# A03:2021 – Injeksi +# A03:2021 – Injeksi ![icon](assets/TOP_10_Icons_Final_Injection.png){: style="height:80px;width:80px" align="right"} ## Faktor-Faktor -| Klasifikasi CWE | Tingkat Kejadian Maksimum | Rata-rata Tingkat Kejadian | Cakupan Maksimum | Rata-rata Cakupan | Rata-rata Bobot Exploitasi | Rata-rata Bobot Dampak | Total Kejadian| Total CVEs | -|:-------------------:|:------------------------:|:-------------------------:|:----------------:|:-----------------:|:-----------------------------:|:---------------------------:|:---------------:|:----------:| -| 33 | 19.09% | 3.37% | 94.04% | 47.90% | 7.25 | 7.15 | 274,228 | 32,078 | +| CWE Dipetakan | Tingkat Kejadian Maksimum | Rata-rata Tingkat Kejadian | Rata-rata Exploitasi Terbobot | Rata-rata Dampak Terbobot | Cakupan Maksimum | Rata-rata Cakupan | Total Kejadian| Total CVE | +|:-------------:|:--------------------:|:--------------------:|:--------------:|:--------------:|:----------------------:|:---------------------:|:-------------------:|:------------:| +| 33 | 19,09% | 3,37% | 7,25 | 7,15 | 94,04% | 47,90% | 274.228 | 32.078 | -## Sudut pandang +## Ringkasan Injeksi meluncur turun ke posisi tiga. 94% dari aplikasi-aplikasi yang -dites oleh beberapa bentuk dari injeksi. Yang dapat dicatat dari CWEs meliputi : -*CWE-79: Pengkodean lintas situs*, *CWE-89: injeksi SQL*, and *CWE-73: -Kontrol eksternal dari nama file atau bagian*. +dites oleh beberapa bentuk dari injeksi dengan tingkat kejadian maksimum 19%, +rata-rata tingkat kejadian 3%, dan total kejadian 274 ribu. CWE yang menonjol meliputi: +*CWE-79: Cross-site Scripting*, *CWE-89: SQL Injection*, dan *CWE-73: +External Control of File Name or Path*. -## Gambaran +## Deskripsi Sebuah aplikasi rentan untuk diserang ketika: -- Pengguna memasukkan data yang tidak divalidasi, disaring atau dibersihkan oleh aplikasi. - -- Kueri secara dinamis atau permintaan yang tidak diberikan parameter tanpa konteks-peringatan pengalihan biasanya langsung pada mesin penerjemah. - -- Data berlawanan digunakan di antara parameter pencari pemetaan relasi object (ORM) untuk mengekstraksi tambahan, rekaman sensitif. - -- Data berlawanan biasanya langsung digunakan atau digabungkan. SQL atau perintah mengandung struktur dan data malfungsi dalam perintah kueri dinamis, - perintah-perintah, atau prosedur tersimpan. - -Beberapa injeksi yang biasa terjadi adalah SQL, NoSQL, perintah OS, pemetaan relasi objek(ORM), LDAP, dan bahasa ekspresi(EL) atau injeksi perpustakaan navigasi grafik objek. Konsepnya adalah identik -di antara semua mesin penerjemah. Penelaahan kode sumber adalah metode terbaik dalam mendeteksi apakah aplikasi tersebut beresiko untuk diinjeksi. Testing otomatis -terhadap semua parameter-parameter, headers, URL, cookies, JSON, SOAP, and input data XML sangat disarankan. -Organisasi dapat menyertakan sumber statik (SAST) dan perangkat tes aplikasi dinamis (DAST) ke dalam CI/CD -pipeline untuk mengidentifikasi pengenalan serpihan-serpihan injeksi sebelum di sebarkan ke produksi. - -## Bagaimana cara mencegah -- Pencegahan injeksi membutuhkan penyimpanan data terpisah dari perintah dan kueri. - -- Pilihan yang disukai adalah menggunakan API yang aman, dimana mencegah penggunaan mesin penerjemah secara keseluruhan, menyediakan sebuah tatap muka berparameter, atau migrasi ke perangkat pemetaan relasi objek. - -- Catatan : Bahkan ketika diparameterkan, prosedur tersimpan masih memperkenalkan injeksi SQL jika PL/SQL atau T-SQL menggabungkan kueri dan data atau mengeksekusi data yang berlawanan dengan EXECUTE IMMEDIATE or exec(). - -- Menggunakan positif atau "daftar putih" pada validasi masukan di sisi server. Ini bukan pertahanan komplit seperti banyak aplikasi membutuhkan karakter spesial, seperti area teks atau APIs untuk aplikasi portabel. - -- Untuk sisa apapun dari kueri dinamis, melewatkan karakter spesial menggunakan sintaks peralihan spesifik untuk mesin penerjemah. - -- Catatan: struktur SQL seperti nama tabel, nama kolom, dan lain sebagainya tidak bisa dilewatkan, dan nama struktur yang diberikan pengguna adalah berbahaya. Ini adalah masalah yang sering terjadi dalam pelaporan penulisan perangkat lunak. - -- Menggunakan LIMIT dan kontrol SQL lainnya di antara kueri untuk mencegah penyingkapan rekaman data secara massal dalam kasus injeksi SQL. - -## Contoh skenario serangan - -**Skenario #1:** sebuah aplikasi menggunakan data yang tidak terpercaya pada kontruksi dari panggilan SQL yang rawan berikut ini: - -String query = "SELECT \* FROM accounts WHERE custID='" + -request.getParameter("id") + "'"; - -**Skenario #2:** serupa dengan sebuah aplikasi dengan kepercayaan buta dalam frameworks -akan menghasilkan kueri yang masih rawan, (contoh, bahasa kueri hibernate(HQL)): - -> Query HQLQuery = session.createQuery("FROM accounts WHERE custID='" + -> request.getParameter("id") + "'"); - -pada kedua kasus tersebut, penyerang akan memodifikasi nilai parameter ‘id’ pada peramban web -untuk mengirim :‘ or ‘1’=’1. Sebagai contoh: - +- Pengguna memasukkan data yang tidak divalidasi, disaring, atau disanitasi + oleh aplikasi. + +- Kueri secara dinamis atau pemanggilan yang tidak diparameterkan tanpa + escape peka konteks dipakai secara langsung pada interpreter. + +- Data jahat digunakan di dalam parameter pencarian object-relational mapping + (ORM) untuk mengekstraksi rekaman sensitif tambahan. + +- Data jahat langsung digunakan atau digabungkan. SQL atau perintah + mengandung struktur dan data jahat dalam kueri dinamis, perintah, atau + stored procedure. + +Beberapa injeksi yang biasa terjadi adalah SQL, NoSQL, perintah OS, pemetaan +relasi objek (ORM), LDAP, dan bahasa ekspresi (EL), atau injeksi Object +Graph Navigation Library (OGNL). Konsepnya identik di antara semua interpreter. +Peninjauan kode sumber adalah metode terbaik dalam mendeteksi apakah aplikasi +tersebut rentan injeksi. Testing otomatis terhadap semua parameter, header, +URL, cookies, JSON, SOAP, and masukan data XML sangat disarankan. +Organisasi dapat menyertakan alat uji keamanan aplikasi statik (SAST), dinamis +(DAST), dan interaktif (IAST) ke dalam CI/CD pipeline untuk mengidentifikasi +cacat injeksi yang ditambahkan sebelum penggelaran produksi. + +## Bagaimana Mencegah + +Pencegahan injeksi membutuhkan pemisahan data dari perintah dan kueri: + +- Pilihan yang disukai adalah menggunakan API yang aman, yang mencegah + penggunaan interpreter secara keseluruhan, menyediakan sebuah antar muka + terparameterisasi, atau migrasi ke Object Relational Mapping Tools (ORMs).
+ **Catatan:** Bahkan ketika diparameterkan, stored procedure masih dapat + memperkenalkan injeksi SQL jika PL/SQL atau T-SQL menggabungkan kueri dan + data atau mengeksekusi data jahat dengan EXECUTE IMMEDIATE atau exec(). + +- Menggunakan validasi masukan positif di sisi server. Ini bukan pertahanan + komplit karena banyak aplikasi membutuhkan karakter spesial, seperti area + teks atau API untuk aplikasi mobile. + +- Untuk sisa apapun dari kueri dinamis, escape-kan karakter khusus + menggunakan sintaks escape spesifik untuk interpreter tersebut.
+ **Catatan:** Struktur SQL seperti nama tabel, nama kolom, dan lain + sebagainya tidak bisa di-escape, sehingga nama struktur yang diberikan + pengguna itu berbahaya. Ini adalah masalah umum dalam perangkat lunak + penyusun laporan. + +- Gunakan LIMIT dan kontrol SQL lainnya di dalam kueri untuk mencegah + penyingkapan rekaman data secara masal dalam kasus injeksi SQL. + +## Contoh Skenario Serangan + +**Skenario #1:** Sebuah aplikasi menggunakan data yang tidak terpercaya dalam +konstruksi dari panggilan SQL yang rawan berikut ini: +``` +String query = "SELECT \* FROM accounts WHERE custID='" + request.getParameter("id") + "'"; +``` +**Skenario #2:** Serupa itu, sebuah aplikasi dengan kepercayaan buta ke +framework akan menghasilkan kueri yang masih rawan, (contoh, Hibernate Query +Language (HQL)): +``` + Query HQLQuery = session.createQuery("FROM accounts WHERE custID='" + request.getParameter("id") + "'"); +``` + +Pada kedua kasus, penyerang akan memodifikasi nilai parameter ‘id’ pada +peramban web untuk mengirim: ‘ or ‘1’=’1. Sebagai contoh: +``` http://example.com/app/accountView?id=' or '1'='1 - -Ini akan merubah arti dari kedua kueri untuk mengembalikan semua rekaman data dari akun tabel. -Serangan lebih berbahaya dapat merubah atau menghapus data atau bahkan prosedur tersimpan. +``` +Ini akan mengubah arti dari kedua kueri untuk mengembalikan semua rekaman +data dari akun tabel. Serangan yang lebih berbahaya dapat mengubah atau +menghapus data atau bahkan memanggil stored procedure. ## Referensi diff --git a/2021/docs/A04_2021-Insecure_Design.id.md b/2021/docs/A04_2021-Insecure_Design.id.md index 831714ee7..f5642ac0a 100644 --- a/2021/docs/A04_2021-Insecure_Design.id.md +++ b/2021/docs/A04_2021-Insecure_Design.id.md @@ -1,22 +1,23 @@ -# A04:2021 – Insecure Design +# A04:2021 – Rancangan Tak Aman ![icon](assets/TOP_10_Icons_Final_Insecure_Design.png){: style="height:80px;width:80px" align="right"} + ## Faktor-Faktor -| Klasifikasi CWE | Tingkat Kejadian Maksimum | Rata - Rata Tingkat kejadian | Cakupan Maksimum | Rata - Rata Cakupan | Rata-rata Bobot Eksploitasi | Rata - Rata Bobot Dampak | Total Kejadian | Total CVEs | +| CWE Dipetakan | Tingkat Kejadian Maksimum | Rata - Rata Tingkat kejadian | Rata-rata Eksploitasi Terbobot | Rata-rata Dampak Terbobot | Cakupan Maksimum | Rata-rata Cakupan | Total Kejadian | Total CVE | |:-------------:|:--------------------:|:--------------------:|:--------------:|:--------------:|:----------------------:|:---------------------:|:-------------------:|:------------:| -| 40 | 24.19% | 3.00% | 77.25% | 42.51% | 6.46 | 6.78 | 262,407 | 2,691 | +| 40 | 24,19% | 3,00% | 6,46 | 6,78 | 77,25% | 42,51% | 262.407 | 2.691 | -## Tinjauan +## Ringkasan -Kategori baru untuk 2021 ini berfokus pada resiko yang berhubungan ke desain dan kekurangan arsitektur, kategori ini mencakup penggunaan permodelan ancaman, design pattern yang jauh lebih aman dan referensi arsitektur. Sebagai sebuah komunitas kami perlu bergerak lebih dari "shift-left" dalam ruang pengodean untuk aktivitas-aktivtas pra-kode yang kritis bagi prinsip-prinsip Aman dari Disain. Contoh CWE termasuk *CWE-209: Generation of Error Message Containing Sensitive Information*, *CWE-256: Unprotected Storage of Credentials*, CWE-501: Trust Boundary Violation*, dan *CWE-522: Insufficiently Protected Credentials*. +Kategori baru untuk 2021 ini berfokus pada resiko yang berhubungan ke desain dan kekurangan arsitektur, kategori ini mencakup penggunaan permodelan ancaman, design pattern yang jauh lebih aman dan referensi arsitektur. Sebagai sebuah komunitas kami perlu bergerak lebih dari "shift-left" dalam ruang pengodean untuk aktivitas-aktivtas pra-kode yang kritis bagi prinsip-prinsip Aman dari Disain. Contoh CWE termasuk *CWE-209: Generation of Error Message Containing Sensitive Information*, *CWE-256: Unprotected Storage of Credentials*, *CWE-501: Trust Boundary Violation*, dan *CWE-522: Insufficiently Protected Credentials*. ## Deskripsi -Desain yang tidak aman adalah sebuah representasi kategori yang luas dari banyak kelemahan yang berbeda, yang diekspresikan sebagai "desain kontrol yang tidak ada atau kurang efisien." Desain tidak aman bukan sumber dari semua kategori risiko Top 10 yang lain. Ada perbedaan antara desain tidak aman dan implementasi tidak aman. Kami membedakan antara cacat desain dan kerusakan implementasi karena suatu alasan, mereka memiliki root cause dan remediasi yang berbeda. Sebuah desain aman masih bisa memiliki kerusakan implementasi yang mengarah ke kerentanan yang dapat dieksploitasi. Suatu desain tidak aman tidak dapat diperbaiki oleh sebuah implementasi yang sempurna karena menurut definisi, kendali keamanan yang diperlukan tidak pernah dibuat untuk bertahan terhadap serangan tertentu. Satu dari faktor yang berkontribusi terhadap desain tidak aman adalah ketiadaan pembuatan profil risiko bisnis yang inheren dalam perangkat lunak atau sistem yang sedang dikembangkan, maka menjadi kegagagalan untuk menentukan desain keamanan level apa yang diperlukan. +Desain yang tidak aman adalah sebuah representasi kategori yang luas dari banyak kelemahan yang berbeda, yang diekspresikan sebagai "desain kontrol yang tidak ada atau kurang efisien." Desain tidak aman bukan sumber dari semua kategori risiko Top 10 yang lain. Ada perbedaan antara desain tidak aman dan implementasi tidak aman. Kami membedakan antara cacat desain dan kerusakan implementasi karena suatu alasan, mereka memiliki akar masalah dan remediasi yang berbeda. Sebuah desain aman masih bisa memiliki kerusakan implementasi yang mengarah ke kerentanan yang dapat dieksploitasi. Suatu desain tidak aman tidak dapat diperbaiki oleh sebuah implementasi yang sempurna karena menurut definisi, kendali keamanan yang diperlukan tidak pernah dibuat untuk bertahan terhadap serangan tertentu. Satu dari faktor yang berkontribusi terhadap desain tidak aman adalah ketiadaan pembuatan profil risiko bisnis yang inheren dalam perangkat lunak atau sistem yang sedang dikembangkan, maka menjadi kegagagalan untuk menentukan desain keamanan level apa yang diperlukan. ### Persyaratan dan Manajemen Sumber Daya -Kumpulkan dan negosiasikan persyaratan bisnis bagi suatu aplikasi dengan pemilik bisnis, termasuk persyaratan perlindungan menyangkut kerahasiaan, integritas, ketersediaan, dan otentisitas dari semua aset data dan logika bisnis yang diharapkan. Perhitungkan akan seberapa terpapar aplikasi Anda dan bila Anda perlu segregasi tenant (sebagai tambahan ke kendali akses). Kompail persyaratkan teknis, termasuk persyaratan keamanan fungsional dan non-fungsional. Rencanakan dan negosiasikan budget yang mencakup semua desain, build, uji coba, dan operasi, termasuk aktivitas-aktivitas keamanan. +Kumpulkan dan negosiasikan persyaratan bisnis bagi suatu aplikasi dengan pemilik bisnis, termasuk persyaratan perlindungan menyangkut kerahasiaan, integritas, ketersediaan, dan otentisitas dari semua aset data dan logika bisnis yang diharapkan. Perhitungkan akan seberapa terpapar aplikasi Anda dan bila Anda perlu segregasi tenant (sebagai tambahan ke kendali akses). Kumpulkan persyaratkan teknis, termasuk persyaratan keamanan fungsional dan non-fungsional. Rencanakan dan negosiasikan budget yang mencakup semua desain, build, uji coba, dan operasi, termasuk aktivitas-aktivitas keamanan. ### Desain Aman @@ -24,132 +25,155 @@ Desain yang aman adalah sebuah budaya dan metodologi yang secara konstan mengeva ### Siklus Hidup Pengembangan Aman -Perangkat lunak aman memerlukan sebuah siklus hidup pengembangan aman, beberapa bentuk pola desain aman, metodologi 'paved road', pustaka komponen yang diamankan, 'tooling', dan pemodelan ancaman. Hubungi spesialis keamanan Anda di awal proyek perangkat lunak untuk keseluruhan proyek dan pemeliharaan perangkat lunak Anda. Pertimbangkan untuk memanfaatkan Software Assurance Maturity Model (SAMM) untuk membantu menstrukturkan upaya pengembangan perangkat lunak aman Anda. +Perangkat lunak aman memerlukan sebuah siklus hidup pengembangan aman, beberapa bentuk pola desain aman, metodologi 'paved road', pustaka komponen yang diamankan, 'tooling', dan pemodelan ancaman. Hubungi spesialis keamanan Anda di awal proyek perangkat lunak untuk keseluruhan proyek dan pemeliharaan perangkat lunak Anda. Pertimbangkan untuk memanfaatkan [OWASP Software Assurance Maturity Model (SAMM)](https://owaspsamm.org) untuk membantu menstrukturkan upaya pengembangan perangkat lunak aman Anda. ## Cara Mencegah -- Buat dan gunakan alur pengembangan aman dengan profesional untuk membantu dalam mengevaluasi dan mendesain keamanan serta kontrol yang terkait privasi -- Buat dan gunakan sebuah pustaka dari design pattern yang aman atau gunakan komponen yang sudah dapat dipakai -- Gunakan permodelan ancaman untuk autentikasi genting, kontrol akses, business logic, dan key flows +- Buat dan gunakan alur pengembangan aman dengan para profesional AppSec + untuk membantu dalam mengevaluasi dan mendesain keamanan serta kontrol + yang terkait privasi + +- Buat dan gunakan sebuah pustaka dari design pattern yang aman atau gunakan + komponen jalan beraspal siap pakai + +- Gunakan pemodelan ancaman untuk autentikasi kritis, kontrol akses, logika + bisnis, dan alur-alur kunci + - Integrasikan kendali dan bahasa keamanan ke dalam cerita pengguna -- Integrasikan uji plausabilitu pada setiap tier dari aplikasi Anda (dari frontend ke backend) -- Tulis tes unit dan tes integrasi untuk memvalidasi bahwa semua aliran genting tahan ke permodelan ancaman. Kompail use-case dan misuse-case bagi setiap tier aplikasi Anda -- Segregasikan lapisan tier pada sistem dan lapisan jaringa bergantung pada kebutuhan eksposur dan proteksi + +- Integrasikan uji plausabilitas pada setiap tier dari aplikasi Anda (dari + frontend ke backend) + +- Tulis tes unit dan tes integrasi untuk memvalidasi bahwa semua aliran + kritis tahan ke pemodelan ancaman. Kompail use-case dan misuse-case bagi + setiap tier aplikasi Anda + +- Segregasikan lapisan tier pada sistem dan lapisan jaringan bergantung pada + kebutuhan eksposur dan proteksi + - Segregasikan tenant secara robust dengan desain pada seluruh tier + - Batasi konsumsi sumber daya oleh pengguna atau layanan ## Contoh Skenario Penyerang **Skenario #1:** Sebuah alur kerja untuk pemulihan kredensial mungkin -termasuk "Pertanayaan dan Jawaban" Dimana telah di larang oleh NIST 800-63b, -OWASP ASVS dan OWASP TOP 10. Pertanyaan dan Jawaban tidak dapat dipercayai -sebagai bukti dari identitas dimana bisa jadi jawaban diketaui lebih -dari satu orang, dimana inilah mengapa mereka di larang. Kode seperti -tersebut harus di hilangkan dan di ganti dengan desain yang lebih aman. +termasuk "pertanyaan dan jawaban" yang telah dilarang oleh NIST 800-63b, +OWASP ASVS, dan OWASP TOP 10. Pertanyaan dan jawaban tidak dapat dipercayai +sebagai bukti dari identitas dimana bisa jadi jawaban diketahui lebih +dari satu orang, dimana inilah mengapa mereka dilarang. Kode seperti +itu harus dihilangkan dan diganti dengan desain yang lebih aman. **Skenario #2:** Sebuah bioskop memungkinkan agar mendapatkan diskon bila -membooking secara grup dan memiliki maksimal 15 peserta sebelum memerlukan deposit. +memesan secara grup dan memiliki maksimal 15 peserta sebelum memerlukan deposit. Penyerang dapat memodelkan sebuah ancaman untuk alur ini dan mereka melakukan -pengujian apaklah mereka dapat membooking enam ratus kursi dan semua bioskop +pengujian apakah mereka dapat memesan enam ratus kursi dan semua bioskop dalam satu waktu dengan request yang sedikit, hal ini menyebabkan hilangnya pemasukan secara besar-besaran oleh bioskop tersebut. -**Skenario #3:** Sebuah rantai retail e-commerce website tidak memiliki -perlindungan dari bot yang dijalankan oleh "Scalper" untuk membeli kartu grafis -kelas tinggi untuk dijual kembali diwebsite tersebut. hal ini membuat image jelek dari -pembuat kartu grafis dan pemiliki rantai retail dan membuat penggemar kecewa -dikarenakan tidak dapat mendapat kartu ini dalam harga apapun. hati-hati juga -desain anti-bot dan aturan logika domain, seperti membeli dengan beberapa detik -ketersediaan dapat kemungkinan mengidentifikasikan pembelian tidak autentik -dan menolak beberapa transaksi. +**Skenario #3:** Sebuah situs web e-commerce rantai retail tidak memiliki +perlindungan dari bot yang dijalankan oleh "scalper" untuk membeli kartu grafis +kelas tinggi untuk dijual kembali di website tersebut. Hal ini membuat image +jelek dari pembuat kartu grafis dan pemiliki rantai retail dan membuat +penggemar kecewa dikarenakan tidak bisa mendapat kartu ini pada harga apa pun. +Hati-hati juga desain anti-bot dan aturan logika domain, seperti pembelian yang +dilakukan beberapa detik setelah ketersediaan mungkin mengidentifikasikan + pembelian tidak autentik dan menolak beberapa transaksi. ## Referensi -- \[OWASP Cheat Sheet: Secure Design Principles\] (TBD) +- [OWASP Cheat Sheet: Secure Design Principles](Segera Hadir) + +- [OWASP SAMM: Design:Security Architecture](https://owaspsamm.org/model/design/security-architecture/) + +- [OWASP SAMM: Design:Threat Assessment](https://owaspsamm.org/model/design/threat-assessment/) + +- [NIST – Guidelines on Minimum Standards for Developer Verification of Software](https://www.nist.gov/publications/guidelines-minimum-standards-developer-verification-software) + +- [The Threat Modeling Manifesto](https://threatmodelingmanifesto.org) + +- [Awesome Threat Modeling](https://github.com/hysnsec/awesome-threat-modelling) + -- NIST - Pedoman Standar Minimum Untuk Verivikasi Pengembang Dari - > Perangkat Lunak - > https://nvlpubs.nist.gov/nistpubs/ir/2021/NIST.IR.8397.pdf +## Daftar CWE yang Dipetakan -## Daftar Klasifikasi CWE +[CWE-73 External Control of File Name or Path](https://cwe.mitre.org/data/definitions/73.html) -CWE-73 External Control of File Name or Path +[CWE-183 Permissive List of Allowed Inputs](https://cwe.mitre.org/data/definitions/183.html) -CWE-183 Permissive List of Allowed Inputs +[CWE-209 Generation of Error Message Containing Sensitive Information](https://cwe.mitre.org/data/definitions/209.html) -CWE-209 Generation of Error Message Containing Sensitive Information +[CWE-213 Exposure of Sensitive Information Due to Incompatible Policies](https://cwe.mitre.org/data/definitions/213.html) -CWE-213 Exposure of Sensitive Information Due to Incompatible Policies +[CWE-235 Improper Handling of Extra Parameters](https://cwe.mitre.org/data/definitions/235.html) -CWE-235 Improper Handling of Extra Parameters +[CWE-256 Unprotected Storage of Credentials](https://cwe.mitre.org/data/definitions/256.html) -CWE-256 Unprotected Storage of Credentials +[CWE-257 Storing Passwords in a Recoverable Format](https://cwe.mitre.org/data/definitions/257.html) -CWE-257 Storing Passwords in a Recoverable Format +[CWE-266 Incorrect Privilege Assignment](https://cwe.mitre.org/data/definitions/266.html) -CWE-266 Incorrect Privilege Assignment +[CWE-269 Improper Privilege Management](https://cwe.mitre.org/data/definitions/269.html) -CWE-269 Improper Privilege Management +[CWE-280 Improper Handling of Insufficient Permissions or Privileges](https://cwe.mitre.org/data/definitions/280.html) -CWE-280 Improper Handling of Insufficient Permissions or Privileges +[CWE-311 Missing Encryption of Sensitive Data](https://cwe.mitre.org/data/definitions/311.html) -CWE-311 Missing Encryption of Sensitive Data +[CWE-312 Cleartext Storage of Sensitive Information](https://cwe.mitre.org/data/definitions/312.html) -CWE-312 Cleartext Storage of Sensitive Information +[CWE-313 Cleartext Storage in a File or on Disk](https://cwe.mitre.org/data/definitions/313.html) -CWE-313 Cleartext Storage in a File or on Disk +[CWE-316 Cleartext Storage of Sensitive Information in Memory](https://cwe.mitre.org/data/definitions/316.html) -CWE-316 Cleartext Storage of Sensitive Information in Memory +[CWE-419 Unprotected Primary Channel](https://cwe.mitre.org/data/definitions/419.html) -CWE-419 Unprotected Primary Channel +[CWE-430 Deployment of Wrong Handler](https://cwe.mitre.org/data/definitions/430.html) -CWE-430 Deployment of Wrong Handler +[CWE-434 Unrestricted Upload of File with Dangerous Type](https://cwe.mitre.org/data/definitions/434.html) -CWE-434 Unrestricted Upload of File with Dangerous Type +[CWE-444 Inconsistent Interpretation of HTTP Requests ('HTTP Request Smuggling')](https://cwe.mitre.org/data/definitions/444.html) -CWE-444 Inconsistent Interpretation of HTTP Requests ('HTTP Request -Smuggling') +[CWE-451 User Interface (UI) Misrepresentation of Critical Information](https://cwe.mitre.org/data/definitions/451.html) -CWE-451 User Interface (UI) Misrepresentation of Critical Information +[CWE-472 External Control of Assumed-Immutable Web Parameter](https://cwe.mitre.org/data/definitions/472.html) -CWE-472 External Control of Assumed-Immutable Web Parameter +[CWE-501 Trust Boundary Violation](https://cwe.mitre.org/data/definitions/501.html) -CWE-501 Trust Boundary Violation +[CWE-522 Insufficiently Protected Credentials](https://cwe.mitre.org/data/definitions/522.html) -CWE-522 Insufficiently Protected Credentials +[CWE-525 Use of Web Browser Cache Containing Sensitive Information](https://cwe.mitre.org/data/definitions/525.html) -CWE-525 Use of Web Browser Cache Containing Sensitive Information +[CWE-539 Use of Persistent Cookies Containing Sensitive Information](https://cwe.mitre.org/data/definitions/539.html) -CWE-539 Use of Persistent Cookies Containing Sensitive Information +[CWE-579 J2EE Bad Practices: Non-serializable Object Stored in Session](https://cwe.mitre.org/data/definitions/579.html) -CWE-579 J2EE Bad Practices: Non-serializable Object Stored in Session +[CWE-598 Use of GET Request Method With Sensitive Query Strings](https://cwe.mitre.org/data/definitions/598.html) -CWE-598 Use of GET Request Method With Sensitive Query Strings +[CWE-602 Client-Side Enforcement of Server-Side Security](https://cwe.mitre.org/data/definitions/602.html) -CWE-602 Client-Side Enforcement of Server-Side Security +[CWE-642 External Control of Critical State Data](https://cwe.mitre.org/data/definitions/642.html) -CWE-642 External Control of Critical State Data +[CWE-646 Reliance on File Name or Extension of Externally-Supplied File](https://cwe.mitre.org/data/definitions/646.html) -CWE-646 Reliance on File Name or Extension of Externally-Supplied File +[CWE-650 Trusting HTTP Permission Methods on the Server Side](https://cwe.mitre.org/data/definitions/650.html) -CWE-650 Trusting HTTP Permission Methods on the Server Side +[CWE-653 Insufficient Compartmentalization](https://cwe.mitre.org/data/definitions/653.html) -CWE-653 Insufficient Compartmentalization +[CWE-656 Reliance on Security Through Obscurity](https://cwe.mitre.org/data/definitions/656.html) -CWE-656 Reliance on Security Through Obscurity +[CWE-657 Violation of Secure Design Principles](https://cwe.mitre.org/data/definitions/657.html) -CWE-657 Violation of Secure Design Principles +[CWE-799 Improper Control of Interaction Frequency](https://cwe.mitre.org/data/definitions/799.html) -CWE-799 Improper Control of Interaction Frequency +[CWE-807 Reliance on Untrusted Inputs in a Security Decision](https://cwe.mitre.org/data/definitions/807.html) -CWE-807 Reliance on Untrusted Inputs in a Security Decision +[CWE-840 Business Logic Errors](https://cwe.mitre.org/data/definitions/840.html) -CWE-840 Business Logic Errors +[CWE-841 Improper Enforcement of Behavioral Workflow](https://cwe.mitre.org/data/definitions/841.html) -CWE-841 Improper Enforcement of Behavioral Workflow +[CWE-927 Use of Implicit Intent for Sensitive Communication](https://cwe.mitre.org/data/definitions/927.html) -CWE-927 Use of Implicit Intent for Sensitive Communication +[CWE-1021 Improper Restriction of Rendered UI Layers or Frames](https://cwe.mitre.org/data/definitions/1021.html) -CWE-1021 Improper Restriction of Rendered UI Layers or Frames +[CWE-1173 Improper Use of Validation Framework](https://cwe.mitre.org/data/definitions/1173.html) -CWE-1173 Improper Use of Validation Framework diff --git a/2021/docs/A05_2021-Security_Misconfiguration.id.md b/2021/docs/A05_2021-Security_Misconfiguration.id.md index bd1bbb5da..398403251 100644 --- a/2021/docs/A05_2021-Security_Misconfiguration.id.md +++ b/2021/docs/A05_2021-Security_Misconfiguration.id.md @@ -1,121 +1,131 @@ -# A05:2021 – Kesalahan Konfigurasi Keamanan +# A05:2021 – Kesalahan Konfigurasi Keamanan ![icon](assets/TOP_10_Icons_Final_Security_Misconfiguration.png){: style="height:80px;width:80px" align="right"} ## Faktor - Faktor -| Klasifikasi CWE | Tingkat Kejadian Maksimum | Rata-rata Tingkat Kejadian | Cakupan Maksimum | Rata-rata Cakupan | Rata-rata Bobot Exploitasi | Rata-rata Bobot Dampak | Total Kejadian| Total CVEs | -| :---------: | :----------------: | :----------------------: | :----------: | :----------------: | :------------------------: | :-----------------------: | :------------: | :--------: | -| 20 | 19.84% | 4.51% | 89.58% | 44.84% | 8.12 | 6.56 | 208,387 | 789 | +| CWE Dipetakan | Tingkat Kejadian Maksimum | Rata-rata Tingkat Kejadian | Rata-rata Exploitasi Terbobot | Rata-rata Dampak Terbobot | Cakupan Maksimum | Rata-rata Cakupan | Total Kejadian | Total CVE | +|:-------------:|:--------------------:|:--------------------:|:--------------:|:--------------:|:----------------------:|:---------------------:|:-------------------:|:------------:| +| 20 | 19,84% | 4,51% | 8,12 | 6,56 | 89,58% | 44,84% | 208.387 | 789 | ## Gambaran -Bergerak dari posisi ke 6 pada edisi sebelumnya, 90% aplikasi dilakukan pengecekan untuk sebuah bentuk dari miskonfigurasi. Dengan bergeraknya kearah software yang memiliki konfigurasi yang tinggi, maka tidak mengejutkan melihat kategori ini naik untuk posisinya. CWE (Common Weakness Enumeration) atau kelemahan enumerasi umum yang perlu diperhatikan termasuk dari _CWE-16 Configuration_ and _CWE-611 Improper Restriction of XML External Entity Reference_. +Bergerak dari posisi ke 6 pada edisi sebelumnya, 90% aplikasi dilakukan pengecekan untuk sebuah bentuk dari miskonfigurasi. Dengan bergeraknya ke arah software yang sangat bisa dikonfigurasi, maka tidak mengejutkan melihat kategori ini naik untuk posisinya. CWE (Common Weakness Enumeration) atau kelemahan enumerasi umum yang perlu diperhatikan termasuk dari *CWE-16 Configuration* dan *CWE-611 Improper Restriction of XML External Entity Reference*. ## Deskripsi -Aplikasi dapat dikatakan rentan apabila aplikasi tersebut : +Aplikasi dapat dikatakan rentan apabila aplikasi tersebut: -- Tidak memiliki pertahanan yang sesuai atau security hardening yang diperlukan diseluruh bagian dari stack aplikasi atau tidak benar dalam melakukan konfigurasi untuk permission pada cloud services. +- Kurangnya security hardening yang sesuai di seluruh bagian dari stack + aplikasi atau tidak benar dalam melakukan konfigurasi untuk izin pada + layanan cloud. -- Fitur - fitur yang tidak digunakan masih di enable atau diinstall (contoh seperti port, services, pages, accounts, atau privileges yang tidak dipakai) +- Fitur-fitur yang tidak digunakan masih difungsikan atau dipasang (mis. + seperti port, layanan, halaman, akun, atau privilege yang tidak dipakai). -- Akun default dan passwordnya masih di bolehkan dan tidak pernah diubah. +- Akun default dan kata sandinya masih difungsikan dan tidak pernah diubah. -- Cara menghandle error memperlihatkan stack traces atau pesan lainnya yang terlalu informatif kepada user +- Penanganan kesalahan mengungkap stack trace atau pesan lainnya yang + terlalu informatif kepada user. -- Untuk sistem yang telah diupdate, fitur security terbaru tidak digunakan atau belum dikonfigurasi. +- Untuk sistem yang ditingkatkan, fitur keamanan terbaru dinon-aktifkan atau + tidak dikonfigurasi secara aman. -- Pengaturan security pada server aplikasi, framework aplikasi (contoh Struts, Spring, ASP.NET), libraries, databases, dll, tidak diatur dengan secure values. +- Pengaturan keamanan pada server aplikasi, framework aplikasi (mis. Struts, + Spring, ASP.NET), pustaka, basis data, dll, tidak diisi dengan nilai-nilai + yang aman. -- Server tidak mengirim security header atau directives, atau tidak diatur dengan secure values. +- Server tidak mengirim header atau direktif keamanan, atau tidak diisi + dengan nilai-nilai aman. -- Software bersifat lama atau rentan (lihat A06:2021-Vulnerable and Outdated Components). +- Perangkat lunak kedaluwarsa atau rentan (lihat [A06:2021-Vulnerable and + Outdated Components](A06_2021-Vulnerable_and_Outdated_Components.id.md)). -Tanpa proses konfigurasi keamanan aplikasi yang berulang dan terpadu, sistem berada dalam resiko yang tinggi. + +Tanpa proses konfigurasi keamanan aplikasi yang dapat diulang dan terpadu, +sistem berada dalam resiko yang lebih tinggi. ## Cara untuk mencegah -Proses instalasi yang aman harus diimplementasikan, termasuk : +Proses instalasi yang aman harus diimplementasikan, termasuk: -- Proses hardening yang dapat diulang akan mempercepat dan memudahkan untuk membuat untuk melakukan deploy ke environment lainnya yang dikunci dengan tepat. Development, QA, dan production environment harus dikonfigurasi secara identik, dengan credentials yang berbeda digunakan pada setiap environment. Proses ini harus di automasi untuk meminimalisir usaha yang diperlukan untuk mengatur environment baru yang aman. +- Proses hardening yang dapat diulang akan mempercepat dan memudahkan untuk membuat untuk melakukan deploy ke environment lainnya yang dikunci dengan tepat. Development, QA, dan production environment harus dikonfigurasi secara identik, dengan kredential yang berbeda digunakan pada setiap environment. Proses ini harus diotomasi untuk meminimalisir usaha yang diperlukan untuk mengatur environment baru yang aman. -- Platform minimal tanpa fitur, komponen, dokumentasi, dan sampel yang tidak diperlukan. Hapus atau jangan install fitur dan framework yang tidak digunakan. +- Platform minimal tanpa fitur, komponen, dokumentasi, dan sampel yang tidak diperlukan. Hapus atau jangan pasang fitur dan framework yang tidak digunakan. -- Sebuah tugas (task) untuk meninjau dan memperbarui konfigurasi yang sesuai untuk ke semua security notes, updates, dan patches sebagai bagian dari proses patch management (lihat A06:2021-Vulnerable and Outdated Components). Review cloud storage permissions (contoh, S3 bucket permissions). +- Sebuah tugas (task) untuk meninjau dan memperbarui konfigurasi yang sesuai untuk ke semua security notes, updates, dan patches sebagai bagian dari proses patch management (lihat [A06:2021-Vulnerable and Outdated Components](A06_2021-Vulnerable_and_Outdated_Components.id.md)). Tinjau izin cloud storage (contoh, izin S3 bucket). -- Sebuah arsitektur aplikasi yang tersegmentasi yang memberikan efektif dan pemisahan yang aman diantara komponen atau tenant, dengan segmentasi, containerization, atau cloud security groups (ACLs). +- Sebuah arsitektur aplikasi yang tersegmentasi yang memberikan pemisahan yang efektif dan aman diantara komponen atau tenant, dengan segmentasi, containerization, atau cloud security groups (ACLs). -- Mengirim security directives ke clients, contoh Security Headers. +- Mengirim security directive ke client, contoh Security Header. - Sebuah proses automasi untuk memverifikasi keefektifan dari konfigurasi dan setting di semua environments. ## Contoh Skenario Penyerangan -**Skenario #1:** Server Aplikasi datang dengan sampel aplikasi yang tidak dihapus dari server production. Sampel Aplikasi tersebut memiliki kelemahan keamanan yang dapat mengkompromi servernya. Misal salah satu aplikasi merupakan admin console dan default dari akun belum diganti. Maka penyerang dapat login dengan default password dan masuk. +**Skenario #1:** Server aplikasi datang dengan sampel aplikasi yang tidak dihapus dari server production. Sampel aplikasi tersebut memiliki kelemahan keamanan yang dapat mengkompromi servernya. Misal salah satu aplikasi merupakan admin console dan default dari akun belum diganti. Maka penyerang dapat login dengan default password dan masuk. -**Skenario #2:** Direktori listing tidak di nonaktifkan di server. Sebuah penyerang menemukan bahwa mereka dapat melihat list direktori. Penyerang menemukan dan mendownload compiled Java classes, yang dimana mereka akan lakukan decompile dan reverse engineer untuk melihat kodenya. Setelah itu penyerang menemukan kelemahan fatal untuk akses kontrol pada aplikasi. +**Skenario #2:** Direktori listing tidak di nonaktifkan di server. Seorang penyerang menemukan bahwa mereka dapat melihat list direktori. Penyerang menemukan dan mengunduh compiled Java class, dimana mereka akan lakukan decompile dan reverse engineer untuk melihat kodenya. Setelah itu penyerang menemukan kelemahan fatal untuk akses kontrol pada aplikasi. -**Skenario #3:** Konfigurasi server aplikasi membolehkan error message yang detail, seperti stack traces, untuk ditampilkan kepada user. Hal tersebut dapat berpotensi untuk memberikan informasi yang bersifat sensitif atau kelemahan mendasar seperti versi komponen yang diketahui kelemahannya. +**Skenario #3:** Konfigurasi server aplikasi membolehkan error message yang detail, seperti stack trace, untuk ditampilkan kepada user. Hal tersebut dapat berpotensi untuk memberikan informasi yang bersifat sensitif atau kelemahan mendasar seperti versi komponen yang diketahui kelemahannya. **Skenario #4:** Sebuah cloud service provider memiliki permission default open untuk sharing ke internet pada pengguna CSP lainnya. Ini memungkinkan untuk data sensitif yang disimpan pada cloud storage untuk diakses ## Referensi -- [OWASP Testing Guide: Configuration - Management](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/README) +- [OWASP Testing Guide: Configuration + Management](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/README) + +- [OWASP Testing Guide: Testing for Error Codes](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/08-Testing_for_Error_Handling/01-Testing_For_Improper_Error_Handling) -- OWASP Testing Guide: Testing for Error Codes +- [Application Security Verification Standard V14 Configuration](https://github.com/OWASP/ASVS/blob/master/4.0/en/0x22-V14-Config.md) -- Application Security Verification Standard V19 Configuration +- [NIST Guide to General Server + Hardening](https://csrc.nist.gov/publications/detail/sp/800-123/final) -- [NIST Guide to General Server - Hardening](https://csrc.nist.gov/publications/detail/sp/800-123/final) +- [CIS Security Configuration + Guides/Benchmarks](https://www.cisecurity.org/cis-benchmarks/) -- [CIS Security Configuration - Guides/Benchmarks](https://www.cisecurity.org/cis-benchmarks/) +- [Amazon S3 Bucket Discovery and + Enumeration](https://blog.websecurify.com/2017/10/aws-s3-bucket-discovery.html) -- [Amazon S3 Bucket Discovery and - Enumeration](https://blog.websecurify.com/2017/10/aws-s3-bucket-discovery.html) +## Daftar CWE Dipetakan -## Daftar Klasifikasi CWE +[CWE-2 7PK - Environment](https://cwe.mitre.org/data/definitions/2.html) -CWE-2 Configuration +[CWE-11 ASP.NET Misconfiguration: Creating Debug Binary](https://cwe.mitre.org/data/definitions/11.html) -CWE-11 ASP.NET Misconfiguration: Creating Debug Binary +[CWE-13 ASP.NET Misconfiguration: Password in Configuration File](https://cwe.mitre.org/data/definitions/13.html) -CWE-13 ASP.NET Misconfiguration: Password in Configuration File +[CWE-15 External Control of System or Configuration Setting](https://cwe.mitre.org/data/definitions/15.html) -CWE-15 External Control of System or Configuration Setting +[CWE-16 Configuration](https://cwe.mitre.org/data/definitions/16.html) -CWE-16 Configuration +[CWE-260 Password in Configuration File](https://cwe.mitre.org/data/definitions/260.html) -CWE-260 Password in Configuration File +[CWE-315 Cleartext Storage of Sensitive Information in a Cookie](https://cwe.mitre.org/data/definitions/315.html) -CWE-315 Cleartext Storage of Sensitive Information in a Cookie +[CWE-520 .NET Misconfiguration: Use of Impersonation](https://cwe.mitre.org/data/definitions/520.html) -CWE-520 .NET Misconfiguration: Use of Impersonation +[CWE-526 Exposure of Sensitive Information Through Environmental Variables](https://cwe.mitre.org/data/definitions/526.html) -CWE-526 Exposure of Sensitive Information Through Environmental -Variables +[CWE-537 Java Runtime Error Message Containing Sensitive Information](https://cwe.mitre.org/data/definitions/537.html) -CWE-537 Java Runtime Error Message Containing Sensitive Information +[CWE-541 Inclusion of Sensitive Information in an Include File](https://cwe.mitre.org/data/definitions/541.html) -CWE-541 Inclusion of Sensitive Information in an Include File +[CWE-547 Use of Hard-coded, Security-relevant Constants](https://cwe.mitre.org/data/definitions/547.html) -CWE-547 Use of Hard-coded, Security-relevant Constants +[CWE-611 Improper Restriction of XML External Entity Reference](https://cwe.mitre.org/data/definitions/611.html) -CWE-611 Improper Restriction of XML External Entity Reference +[CWE-614 Sensitive Cookie in HTTPS Session Without 'Secure' Attribute](https://cwe.mitre.org/data/definitions/614.html) -CWE-614 Sensitive Cookie in HTTPS Session Without 'Secure' Attribute +[CWE-756 Missing Custom Error Page](https://cwe.mitre.org/data/definitions/756.html) -CWE-756 Missing Custom Error Page +[CWE-776 Improper Restriction of Recursive Entity References in DTDs ('XML Entity Expansion')](https://cwe.mitre.org/data/definitions/776.html) -CWE-776 Improper Restriction of Recursive Entity References in DTDs -('XML Entity Expansion') +[CWE-942 Permissive Cross-domain Policy with Untrusted Domains](https://cwe.mitre.org/data/definitions/942.html) -CWE-942 Overly Permissive Cross-domain Whitelist +[CWE-1004 Sensitive Cookie Without 'HttpOnly' Flag](https://cwe.mitre.org/data/definitions/1004.html) -CWE-1004 Sensitive Cookie Without 'HttpOnly' Flag +[CWE-1032 OWASP Top Ten 2017 Category A6 - Security Misconfiguration](https://cwe.mitre.org/data/definitions/1032.html) -CWE-1032 OWASP Top Ten 2017 Category A6 - Security Misconfiguration +[CWE-1174 ASP.NET Misconfiguration: Improper Model Validation](https://cwe.mitre.org/data/definitions/1174.html) -CWE-1174 ASP.NET Misconfiguration: Improper Model Validation diff --git a/2021/docs/A06_2021-Vulnerable_and_Outdated_Components.id.md b/2021/docs/A06_2021-Vulnerable_and_Outdated_Components.id.md index 730520936..36cf08aa3 100644 --- a/2021/docs/A06_2021-Vulnerable_and_Outdated_Components.id.md +++ b/2021/docs/A06_2021-Vulnerable_and_Outdated_Components.id.md @@ -1,45 +1,93 @@ -# A06:2021 – Komponen yang Rentan dan Kedaluwarsa +# A06:2021 – Komponen yang Rentan dan Kedaluwarsa ![icon](assets/TOP_10_Icons_Final_Vulnerable_Outdated_Components.png){: style="height:80px;width:80px" align="right"} ## Faktor-Faktor -| Klasifikasi CWE | Tingkat Kejadian Maksimum | Rata-rata Tingkat kejadian | Cakupan Maksimum | Rata-rata Cakupan | Rata-rata Bobot Eksploitasi | Rata-rata Bobot Dampak | Total Kejadian | Total CVEs | +| CWE Dipetakan | Tingkat Kejadian Maksimum | Rata-rata Tingkat kejadian | Cakupan Maksimum | Rata-rata Cakupan | Rata-rata Eksploitasi Terbobot | Rata-rata Dampak Terbobot | Total Kejadian | Total CVE | |:-------------:|:--------------------:|:--------------------:|:--------------:|:--------------:|:----------------------:|:---------------------:|:-------------------:|:------------:| -| 3 | 27.96% | 8.77% | 51.78% | 22.47% | 5.00 | 5.00 | 30,457 | 0 | +| 3 | 27,96% | 8,77% | 51,78% | 22,47% | 5,00 | 5,00 | 30.457 | 0 | ## Ikhtisar -Sebelumnya #2 dari survei komunitas Top 10 tetapi juga memiliki data yang cukup untuk membuat Top 10 melalui data. Komponen yang rentan adalah masalah umum yang kami 'struggle' untuk menguji dan menilai risiko dan merupakan satu-satunya kategori yang tidak memiliki CWE yang dipetakan ke CWE yang disertakan, jadi bobot baku eksploitasi/dampak 5.0 digunakan. CWE terkenal yang disertakan adalah *CWE-1104: Penggunaan Komponen Pihak Ketiga yang Tidak Dikelola* dan dua CWE dari Top 10 2013 dan 2017. +Sebelumnya #2 dari survei komunitas Top 10 tetapi juga memiliki data yang cukup untuk membuat Top 10 melalui data. Komponen yang rentan adalah masalah umum yang kami 'struggle' untuk menguji dan menilai risiko dan merupakan satu-satunya kategori yang tidak memiliki Common Vulnerability and Exposures (CVE) yang dipetakan ke CWE yang disertakan, jadi bobot baku eksploitasi/dampak 5.0 digunakan. CWE terkenal yang disertakan adalah *CWE-1104: Penggunaan Komponen Pihak Ketiga yang Tidak Dikelola* dan dua CWE dari Top 10 2013 dan 2017. ## Deskripsi Anda kemungkinan besar rentan: -- Jika Anda tidak mengetahui versi semua komponen yang Anda gunakan (sisi klien dan sisi server). Ini termasuk komponen yang secara langsung Anda gunakan serta dependensi bersarang. -- Jika perangkat lunak rentan, tidak didukung, atau ketinggalan zaman. Ini termasuk OS, server web/aplikasi, sistem manajemen basis data (DBMS), aplikasi, API dan semua komponen, lingkungan runtime, dan pustaka. -- Jika Anda tidak memindai kerentanan secara teratur dan berlangganan buletin keamanan yang terkait dengan komponen yang Anda gunakan. -- Jika Anda tidak memperbaiki atau meningkatkan platform, kerangka kerja, dan dependensi yang mendasarinya secara tepat waktu dan berbasis risiko. Ini biasanya terjadi di lingkungan ketika patch adalah tugas bulanan atau triwulanan dibawah kendali perubahan, membiarkan organisasi terbuka selama berhari-hari atau berbulan-bulan terpapar secara tidak perlu atas kerentanan-kerentangan yang telah diperbaiki. -- Jika pengembang perangkat lunak tidak menguji kompatibilitas pustaka-pustaka yang diperbarui, ditingkatkan, atau di-patch. -- Jika Anda tidak mengamankan konfigurasi komponen (lihat A05:2021-Security Misconfiguration). +- Jika Anda tidak mengetahui versi semua komponen yang Anda gunakan (sisi + klien dan sisi server). Ini termasuk komponen yang secara langsung Anda + gunakan serta dependensi bersarang. + +- Jika perangkat lunak rentan, tidak didukung, atau ketinggalan zaman. Ini + termasuk OS, server web/aplikasi, sistem manajemen basis data (DBMS), + aplikasi, API dan semua komponen, lingkungan runtime, dan pustaka. + +- Jika Anda tidak memindai kerentanan secara teratur dan berlangganan + buletin keamanan yang terkait dengan komponen yang Anda gunakan. + +- Jika Anda tidak memperbaiki atau meningkatkan platform, kerangka kerja, + dan dependensi yang mendasarinya secara tepat waktu dan berbasis risiko. + Ini biasanya terjadi di lingkungan ketika patch adalah tugas bulanan atau + triwulanan dibawah kendali perubahan, membiarkan organisasi terbuka selama + berhari-hari atau berbulan-bulan terpapar secara tidak perlu atas + kerentanan-kerentanan yang telah diperbaiki. + +- Jika pengembang perangkat lunak tidak menguji kompatibilitas pustaka- + pustaka yang diperbarui, ditingkatkan, atau di-patch. + +- Jika Anda tidak mengamankan konfigurasi komponen (lihat + [A05:2021-Security Misconfiguration](A05_2021-Security_Misconfiguration.id.md)). ## Cara Mencegah Harus ada proses manajemen patch untuk: -- Menghapus dependensi, fitur, komponen, file, dan dokumentasi yang tidak digunakan. -- Inventarisasi versi komponen sisi klien dan sisi server secara terus menerus (mis., kerangka kerja, pustaka) dan dependensinya menggunakan alat seperti versi, OWASP Dependency Check, retire.js, dll. Memantau secara terus menerus sumber-sumber seperti Common Vulnerability and Exposures (CVE) dan National Vulnerability Database (NVD) untuk kerentanan dalam komponen. Gunakan alat analisis komposisi perangkat lunak untuk mengotomatisasi proses. Berlangganan email peringatan untuk kerentanan keamanan yang terkait dengan komponen yang Anda gunakan. -- Hanya dapatkan komponen dari sumber resmi melalui tautan yang aman. Pilih paket yang ditandatangani untuk mengurangi kemungkinan menyertakan komponen berbahaya yang dimodifikasi (Lihat A08:2021-Software and Data Integrity Failures). -- Memantau pustaka dan komponen yang tidak dirawat atau tidak membuat patch keamanan untuk versi yang lebih lama. Jika tambalan tidak memungkinkan, pertimbangkan untuk menggunakan tambalan virtual untuk memantau, mendeteksi, atau melindungi dari masalah yang ditemukan. +- Menghapus dependensi, fitur, komponen, file, dan dokumentasi yang tidak + digunakan. -Setiap organisasi harus memastikan rencana berkelanjutan untuk memantau, melakukan triase, dan menerapkan pembaruan atau perubahan konfigurasi selama masa pakai aplikasi atau portofolio. +- Inventarisasi versi komponen sisi klien dan sisi server secara terus + menerus (mis., kerangka kerja, pustaka) dan dependensinya menggunakan + alat seperti versi, OWASP Dependency Check, retire.js, dll. Memantau + secara terus menerus sumber-sumber seperti Common Vulnerability and + Exposures (CVE) dan National Vulnerability Database (NVD) untuk + kerentanan dalam komponen. Gunakan alat analisis komposisi perangkat + lunak untuk mengotomatisasi proses. Berlangganan email peringatan untuk + kerentanan keamanan yang terkait dengan komponen yang Anda gunakan. + +- Hanya dapatkan komponen dari sumber resmi melalui tautan yang aman. Pilih + paket yang ditandatangani untuk mengurangi kemungkinan menyertakan + komponen berbahaya yang dimodifikasi (Lihat [A08:2021-Software and Data + Integrity Failures](A08_2021-Software_and_Data_Integrity_Failures.id.md)). + +- Memantau pustaka dan komponen yang tidak dirawat atau tidak membuat patch + keamanan untuk versi yang lebih lama. Jika patch tidak memungkinkan, + pertimbangkan untuk menggunakan patch virtual untuk memantau, mendeteksi, + atau melindungi dari masalah yang ditemukan. + +Setiap organisasi harus memastikan rencana berkelanjutan untuk memantau, +melakukan triase, dan menerapkan pembaruan atau perubahan konfigurasi selama +masa pakai aplikasi atau portofolio. ## Contoh Skenario Serangan -**Skenario #1:** Komponen biasanya berjalan dengan hak istimewa yang sama seperti aplikasi itu sendiri, sehingga cacat pada komponen apa pun dapat mengakibatkan dampak yang serius. Jadi cacat tersebut dapat terjadi secara tidak sengaja (mis., kesalahan pengkodean) atau disengaja (mis., pintu belakang dalam suatu komponen). Beberapa contoh kerentanan komponen yang dapat dieksploitasi yang ditemukan adalah: +**Skenario #1:** Komponen biasanya berjalan dengan hak istimewa yang sama +seperti aplikasi itu sendiri, sehingga cacat pada komponen apa pun dapat +mengakibatkan dampak yang serius. Jadi cacat tersebut dapat terjadi secara +tidak sengaja (mis., kesalahan pengkodean) atau disengaja (mis., pintu +belakang dalam suatu komponen). Beberapa contoh kerentanan komponen yang +dapat dieksploitasi yang ditemukan adalah: + +- CVE-2017-5638, kerentanan eksekusi kode jarak jauh Struts 2 yang + memungkinkan eksekusi kode sembarang di server, telah disalahkan atas + pembobolan-pembobolan yang signifikan. -- CVE-2017-5638, kerentanan eksekusi kode jarak jauh Struts 2 yang memungkinkan eksekusi kode sembarang di server, telah disalahkan atas pembobolan-pembobolan yang signifikan. -- Sementara internet of things (IoT) seringkali sangat sulit untuk ditambal, pentingnya menambal bisa sangat besar (mis., perangkat biomedis). +- Sementara internet of things (IoT) seringkali sangat sulit untuk di-patch, + pentingnya mem-patch bisa sangat besar (mis., perangkat biomedis). -Ada alat otomatis untuk membantu penyerang menemukan sesuatu yang belum ditambal atau sistem yang salah konfigurasi. Misalnya, mesin pencari Shodan IoT dapat membantu Anda menemukan perangkat yang masih mengalami kerentanan Heartbleed yang ditambal pada April 2014. +Ada alat otomatis untuk membantu penyerang menemukan sesuatu yang belum +di-patch atau sistem yang salah konfigurasi. Misalnya, mesin pencari Shodan +IoT dapat membantu Anda menemukan perangkat yang masih mengalami kerentanan +Heartbleed yang di-patch pada April 2014. ## Referensi diff --git a/2021/docs/A07_2021-Identification_and_Authentication_Failures.id.md b/2021/docs/A07_2021-Identification_and_Authentication_Failures.id.md index 0f3b7dcc6..7bbcf2fe7 100644 --- a/2021/docs/A07_2021-Identification_and_Authentication_Failures.id.md +++ b/2021/docs/A07_2021-Identification_and_Authentication_Failures.id.md @@ -1,66 +1,74 @@ -# A07:2021 – Kegagalan Identifikasi dan Otentikasi +# A07:2021 – Kegagalan Identifikasi dan Otentikasi ![icon](assets/TOP_10_Icons_Final_Identification_and_Authentication_Failures.png){: style="height:80px;width:80px" align="right"} ## Faktor -| Klasifikasi CWE | Tingkat Kejadian Maksimum | Rata - Rata Tingkat kejadian | Cakupan Maksimum | Rata - Rata Cakupan | Rata-rata Bobot Eksploitasi | Rata - Rata Bobot Dampak | Total Kejadian | Total CVEs | +| CWE Dipetakan | Tingkat Kejadian Maksimum | Rata-rata Tingkat kejadian | Rata-rata Eksploitasi Terbobot | Rata-rata Dampak Terbobot | Cakupan Maksimum | Rata-rata Cakupan | Total Kejadian | Total CVE | |:-------------:|:--------------------:|:--------------------:|:--------------:|:--------------:|:----------------------:|:---------------------:|:-------------------:|:------------:| -| 22 | 14.84% | 2.55% | 79.51% | 45.72% | 7.40 | 6.50 | 132,195 | 3,897 | - +| 22 | 14,84% | 2,55% | 7,40 | 6,50 | 79,51% | 45,72% | 132.195 | 3.897 | ## Ikhtisar Sebelumnya dikenal sebagai *Broken Authentication*, kategori ini turun -dari posisi kedua dan sekarang mencakup CWE yang terkait dengan kegagalan identifikasi. CWE terkenal yang disertakan adalah *CWE-297: Improper Validation of +dari posisi kedua dan sekarang mencakup Common Weakness +Enumerations (CWE) yang terkait dengan kegagalan identifikasi. CWE terkenal +yang disertakan adalah *CWE-297: Improper Validation of Certificate with Host Mismatch*, *CWE-287: Improper Authentication*, dan *CWE-384: Session Fixation*. ## Deskripsi -Konfirmasi identitas pengguna, otentikasi, dan sesi manajemen sangat penting untuk melindungi dari serangan terkait otentikasi. -Mungkin ada kelemahan otentikasi jika aplikasi: +Konfirmasi identitas pengguna, otentikasi, dan sesi manajemen sangat penting +untuk melindungi dari serangan terkait otentikasi. Mungkin ada kelemahan +otentikasi jika aplikasi: -- Mengizinkan serangan otomatis seperti isian kredensial, di mana +- Mengizinkan serangan otomatis seperti credential stuffing, dimana penyerang memiliki daftar nama pengguna dan kata sandi yang valid. - Mengizinkan brute force atau serangan otomatis lainnya. -- Mengizinkan kata sandi bawaan, lemah, atau kata sandi yang terkenal, seperti "Password1" atau "admin/admin." +- Mengizinkan kata sandi bawaan, lemah, atau kata sandi yang terkenal, + seperti "Password1" atau "admin/admin." -- Menggunakan pemulihan kredensial yang lemah atau tidak efektif dan proses lupa kata sandi, seperti "jawaban berbasis pengetahuan", yang tidak dapat dibuat - aman. +- Menggunakan proses lupa kata sandi dan pemulihan kredensial yang lemah + atau tidak efektif, seperti "jawaban berbasis pengetahuan", yang tidak + dapat dibuat aman. -- Menggunakan kata sandi teks biasa, terenkripsi, atau dengan hash yang lemah (lihat - A3:2017-Sensitive Data Exposure). +- Menggunakan kata sandi teks polos, terenkripsi, atau dengan hash yang + lemah (lihat [A02:2021-Cryptographic + Failures](A02_2021-Cryptographic_Failures.id.md)). -- Memiliki otentikasi multi-faktor yang hilang atau tidak efektif. +- Memiliki otentikasi multi-faktor tidak efektif, atau tidak memilikinya. -- Mengekspos ID Sesi di URL (misalnya, penulisan ulang URL). +- Mengekspos ID Sesi di URL. -- Jangan memutar ID Sesi setelah login berhasil. +- Memakai kembali ID Sesi setelah login berhasil. - Tidak membatalkan ID Sesi dengan benar. Sesi pengguna atau token autentikasi (terutama token single sign-on (SSO)) tidak - divalidasi dengan benar selama logout atau periode tidak aktif. + di-invalidasi dengan benar selama logout atau periode tidak aktif. ## Cara Mencegah - Jika memungkinkan, terapkan otentikasi multi-faktor untuk mencegah - pengisian kredensial otomatis, brute force, dan dan serangan penggunaan kembali kredensial yang dicuri. + credential stuffing otomatis, brute force, dan dan serangan penggunaan + kembali kredensial curian. -- Jangan mengirim atau menyebarkan dengan kredensial bawaan apa pun, terutama untuk - pengguna admin. +- Jangan mengirim atau menyebarkan dengan kredensial bawaan apa pun, + terutama untuk pengguna admin. -- Menerapkan pemeriksaan kata sandi yang lemah, seperti menguji kata sandi baru atau yang diubah terhadap 10.000 daftar kata sandi terburuk +- Menerapkan pemeriksaan kata sandi yang lemah, seperti menguji kata sandi + baru atau yang diubah terhadap 10.000 daftar kata sandi terburuk -- Sejajarkan panjang sandi, kompleksitas, dan kebijakan rotasi dengan pedoman NIST - 800-63b di bagian 5.1.1 untuk Rahasia yang Dihafal atau kebijakan kata sandi modern berbasis bukti lainnya. +- Selaraskan kebijakan panjang kata sandi, kompleksitas, dan rotasi dengan + pedoman NIST 800-63b di bagian 5.1.1 untuk Rahasia yang Dihafal atau + kebijakan kata sandi modern berbasis bukti lainnya. -- Pastikan pendaftaran, pemulihan kredensial, dan jalur API - diperkuat terhadap serangan enumerasi akun dengan menggunakan pesan yang sama +- Pastikan pendaftaran, pemulihan kredensial, dan jalur API diperkuat + terhadap serangan enumerasi akun dengan menggunakan pesan yang sama untuk semua hasil. - Batasi atau semakin tunda upaya login yang gagal. Catat semua kegagalan - dan peringatkan administrator ketika pengisian kredensial, brute force, atau - serangan lainnya terdeteksi. + dan peringatkan administrator ketika credential stuffing, brute force, + atau serangan lainnya terdeteksi. - Gunakan pengelola sesi built-in sisi server, aman, yang menghasilkan ID sesi acak baru dengan entropi tinggi setelah login. ID sesi @@ -69,18 +77,23 @@ Mungkin ada kelemahan otentikasi jika aplikasi: ## Contoh Skenario Serangan -**Skenario #1:** Pengisian Kredensial, penggunaan daftar kata sandi yang diketahui -adalah serangan yang umum. Misalkan aplikasi tidak menerapkan -perlindungan terhadap ancaman atau pengisian kredensial otomatis. Dalam hal ini, -aplikasi dapat digunakan sebagai kata sandi oracle untuk menentukan apakah -kredensial itu valid. +**Skenario #1:** Credential Stuffing, penggunaan daftar kata sandi yang +diketahui adalah serangan yang umum. Misalkan aplikasi tidak menerapkan +perlindungan terhadap ancaman atau credential stuffing otomatis. Dalam hal +ini, aplikasi dapat digunakan sebagai oracle kata sandi untuk menentukan +apakah kredensial itu valid. **Skenario #2:** Sebagian besar serangan autentikasi terjadi karena terus -menggunakan sandi sebagai satu-satunya faktor. Setelah dipertimbangkan, praktik terbaik, rotasi kata sandi, dan persyaratan kompleksitas mendorong pengguna untuk menggunakan kembali kata sandi yang lemah. Organisasi disarankan untuk menghentikan praktik ini per NIST 800-63 dan menggunakan otentikasi multi-faktor. +menggunakan sandi sebagai satu-satunya faktor. Pernah dianggap sebagai, +praktik terbaik, rotasi kata sandi, dan persyaratan kompleksitas mendorong +pengguna untuk menggunakan kembali kata sandi yang lemah. Organisasi +disarankan untuk menghentikan praktik ini per NIST 800-63 dan menggunakan +otentikasi multi-faktor. **Skenario #3:** Waktu tunggu sesi aplikasi tidak disetel dengan benar. Seorang pengguna menggunakan komputer publik untuk mengakses aplikasi. Alih-alih -memilih "logout", pengguna cukup menutup tab browser dan pergi. Penyerang menggunakan browser yang sama satu jam kemudian, dan pengguna masih diautentikasi. +memilih "logout", pengguna cukup menutup tab browser dan pergi. Penyerang +menggunakan browser yang sama satu jam kemudian, dan pengguna masih diautentikasi. ## Referensi @@ -93,65 +106,66 @@ memilih "logout", pengguna cukup menutup tab browser dan pergi. Penyerang menggu - [OWASP Application Security Verification Standard: V3 Session Management](https://owasp.org/www-project-application-security-verification-standard) -- OWASP Testing Guide: Identity, Authentication +- [OWASP Testing Guide: Identity](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/03-Identity_Management_Testing/README), [Authentication](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/04-Authentication_Testing/README) - [OWASP Cheat Sheet: Authentication](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html) -- OWASP Cheat Sheet: Credential Stuffing +- [OWASP Cheat Sheet: Credential Stuffing](https://cheatsheetseries.owasp.org/cheatsheets/Credential_Stuffing_Prevention_Cheat_Sheet.html) - [OWASP Cheat Sheet: Forgot Password](https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html) -- OWASP Cheat Sheet: Session Management +- [OWASP Cheat Sheet: Session Management](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html) - [OWASP Automated Threats Handbook](https://owasp.org/www-project-automated-threats-to-web-applications/) - NIST 800-63b: 5.1.1 Memorized Secrets -## Daftar Klasifikasi CWE +## Daftar CWE yang Dipetakan + +[CWE-255 Credentials Management Errors](https://cwe.mitre.org/data/definitions/255.html) -CWE-255 Credentials Management Errors +[CWE-259 Use of Hard-coded Password](https://cwe.mitre.org/data/definitions/259.html) -CWE-259 Use of Hard-coded Password +[CWE-287 Improper Authentication](https://cwe.mitre.org/data/definitions/287.html) -CWE-287 Improper Authentication +[CWE-288 Authentication Bypass Using an Alternate Path or Channel](https://cwe.mitre.org/data/definitions/288.html) -CWE-288 Authentication Bypass Using an Alternate Path or Channel +[CWE-290 Authentication Bypass by Spoofing](https://cwe.mitre.org/data/definitions/290.html) -CWE-290 Authentication Bypass by Spoofing +[CWE-294 Authentication Bypass by Capture-replay](https://cwe.mitre.org/data/definitions/294.html) -CWE-294 Authentication Bypass by Capture-replay +[CWE-295 Improper Certificate Validation](https://cwe.mitre.org/data/definitions/295.html) -CWE-295 Improper Certificate Validation +[CWE-297 Improper Validation of Certificate with Host Mismatch](https://cwe.mitre.org/data/definitions/297.html) -CWE-297 Improper Validation of Certificate with Host Mismatch +[CWE-300 Channel Accessible by Non-Endpoint](https://cwe.mitre.org/data/definitions/300.html) -CWE-300 Channel Accessible by Non-Endpoint +[CWE-302 Authentication Bypass by Assumed-Immutable Data](https://cwe.mitre.org/data/definitions/302.html) -CWE-302 Authentication Bypass by Assumed-Immutable Data +[CWE-304 Missing Critical Step in Authentication](https://cwe.mitre.org/data/definitions/304.html) -CWE-304 Missing Critical Step in Authentication +[CWE-306 Missing Authentication for Critical Function](https://cwe.mitre.org/data/definitions/306.html) -CWE-306 Missing Authentication for Critical Function +[CWE-307 Improper Restriction of Excessive Authentication Attempts](https://cwe.mitre.org/data/definitions/307.html) -CWE-307 Improper Restriction of Excessive Authentication Attempts +[CWE-346 Origin Validation Error](https://cwe.mitre.org/data/definitions/346.html) -CWE-346 Origin Validation Error +[CWE-384 Session Fixation](https://cwe.mitre.org/data/definitions/384.html) -CWE-384 Session Fixation +[CWE-521 Weak Password Requirements](https://cwe.mitre.org/data/definitions/521.html) -CWE-521 Weak Password Requirements +[CWE-613 Insufficient Session Expiration](https://cwe.mitre.org/data/definitions/613.html) -CWE-613 Insufficient Session Expiration +[CWE-620 Unverified Password Change](https://cwe.mitre.org/data/definitions/620.html) -CWE-620 Unverified Password Change +[CWE-640 Weak Password Recovery Mechanism for Forgotten Password](https://cwe.mitre.org/data/definitions/640.html) -CWE-640 Weak Password Recovery Mechanism for Forgotten Password +[CWE-798 Use of Hard-coded Credentials](https://cwe.mitre.org/data/definitions/798.html) -CWE-798 Use of Hard-coded Credentials +[CWE-940 Improper Verification of Source of a Communication Channel](https://cwe.mitre.org/data/definitions/940.html) -CWE-940 Improper Verification of Source of a Communication Channel +[CWE-1216 Lockout Mechanism Errors](https://cwe.mitre.org/data/definitions/1216.html) -CWE-1216 Lockout Mechanism Errors diff --git a/2021/docs/A08_2021-Software_and_Data_Integrity_Failures.id.md b/2021/docs/A08_2021-Software_and_Data_Integrity_Failures.id.md index 9e486522b..987e201a4 100644 --- a/2021/docs/A08_2021-Software_and_Data_Integrity_Failures.id.md +++ b/2021/docs/A08_2021-Software_and_Data_Integrity_Failures.id.md @@ -1,58 +1,97 @@ -# A08:2021 - Kegagalan Integritas Data dan Perangkat Lunak -icon +# A08:2021 - Kegagalan Integritas Data dan Perangkat Lunak ![icon](assets/TOP_10_Icons_Final_Software_and_Data_Integrity_Failures.png){: style="height:80px;width:80px" align="right"} ## Faktor -| Klasifikasi CWE | Tingkat Kejadian Maksimum | Rata-rata Tingkat Kejadian | Cakupan Maksimum | Rata-rata Cakupan | Rata-rata Bobot Exploitasi | Rata-rata Bobot Dampak | Total Kejadian | Total CVEs | +| CWE Dipetakan | Tingkat Kejadian Maksimum | Rata-rata Tingkat Kejadian | Rata-rata Exploitasi Terbobot | Rata-rata Dampak Terbobot | Cakupan Maksimum | Rata-rata Cakupan | Total Kejadian | Total CVE | |:-------------:|:--------------------:|:--------------------:|:--------------:|:--------------:|:----------------------:|:---------------------:|:-------------------:|:------------:| -| 10 | 16.67% | 2.05% | 75.04% | 45.35% | 6.94 | 7.94 | 47,972 | 1,152 | +| 10 | 16,67% | 2,05% | 6,94 | 7,94 | 75,04% | 45,35% | 47.972 | 1.152 | -## Penjelasan Singkat +## Ringkasan -Kategori baru pada tahun 2021 yang berfokus pada membuat asumsi terkait pembaruan perangkat lunak, data kritis, dan pipeline CI/CD tanpa memverifikasi integritas. Satu dari dampak dibobot tertinggi dari data Common Vulnerability and Exposures/Common Vulnerability Scoring System (CVE/CVSS). CWE yang patut diperhatikan *CWE-829: Inclusion of Functionality from Untrusted Control Sphere*, *CWE-494: Download of Code Without Integrity Check*, dan *CWE-502: Deserialization of Untrusted Data*. +Kategori baru pada tahun 2021 yang berfokus pada membuat asumsi terkait +pembaruan perangkat lunak, data kritis, dan pipeline CI/CD tanpa memverifikasi +integritas. Satu dari dampak dibobot tertinggi dari data Common Vulnerability +and Exposures/Common Vulnerability Scoring System (CVE/CVSS). CWE yang patut +diperhatikan *CWE-829: Inclusion of Functionality from Untrusted Control +Sphere*, *CWE-494: Download of Code Without Integrity Check*, dan *CWE-502: +Deserialization of Untrusted Data*. ## Deskripsi -_Software and data integrity failures relate to code and infrastructure that does not protect against integrity violations. An example of this is where an application relies upon plugins, libraries, or modules from untrusted sources, repositories, and content delivery networks (CDNs). An insecure CI/CD pipeline can introduce the potential for unauthorized access, malicious code, or system compromise. Lastly, many applications now include auto-update functionality, where updates are downloaded without sufficient integrity verification and applied to the previously trusted application. Attackers could potentially upload their own updates to be distributed and run on all installations. Another example is where objects or data are encoded or serialized into a structure that an attacker can see and modify is vulnerable to insecure deserialization._ -Gagalnya Menjaga Integritas Data dan Perangkat Lunak disebabkan oleh kode dan infrastruktur yang tidak mencegah terjadinya pelanggaran integritas. -Contohnya sebuah objek/data yang telah di enkoding/diserialisasi di dalam struktur yang dapat dilihat dan dimodifikasi oleh penyerang rentan terhadap deserialisasi yang tidak aman. - -Contoh lainnya adalah aplikasi yang bergantung pada *plugins*, *libraries*, atau *modules* yang asalnya dari sumber yang tidak dipercaya, repositori - repositori, *Content Delivery Network (CDNs)*. -*CI/CD Pipeline* yang tidak aman dapat menyebabkan munculnya akses illegal/tidak sah, kode yang berbahaya, atau kerusakan sistem. - -Terakhir, aplikasi sekarang banyak yang memiliki fitur pembaharuan otomatis, yang dimana pembaharuan - pembaharuan yang ada diunduh tanpa adanya verifikasi integritas dan diterapkan/digunakan terhadap aplikasi yang sebelumnya terpercaya. -Penyerang memiliki kemungkinan besar untuk mengunggah pembaharuan milik mereka sendiri untuk di distribusikan dan dijalankan/diterapkan pada semua instalasi/pembaharuan. - -## Bagaimana Cara Mencegahnya - -- Gunakan tanda tangan digital atau mekanisme yang sama untuk memverifikasi bahwa perangkat lunak atau data berasal dari sumber yang diharapkan dan tidak di manipulasi. - -- Pastikan *libaries* dan dependensi seperti npm atau Maven menggunakan repositori yang terpercaya. Apabila anda merupakan target berisiko tinggi, pertimbangkan untuk hos repositori yang dikenal baik dan sudah di periksa kepercayaannya. - -- Pastikan alat keamanan rantai pasokan perangkat lunak, seperti OWASP Dependency Check atau OWASP CycloneDX digunakan untuk memverifikasi bahwa komponen komponen tersebut tidak memiliki kerentanan yang sudah diketahui. - -- Pastikan adanya proses review ketika mengubah kode dan konfigurasi untuk meminimalisir kemungkinan kode atau konfigurasi berbahaya masuk ke dalam *pipeline* perangkat lunak anda. - -- Pastikan *CI/CD pipeline* anda memiliki metode pemisahan, konfigurasi dan akses kontrol yang tepat untuk memastikan integritas kode yang masuk mulai dari proses *build* / pembangunan hinga proses *deployment* / penyebaran perangkat lunak. - -- Pastikan data yang belum di tanda tangani atau tidak terenkripsi ini tidak terkirim ke klien yang tidak dipercaya tanpa adanya pengecekan integritas atau tanda tangan digital untuk mendeteksi apakah data telah di manipulasi atau pemutaran ulang data yang telah di serialisasi. +Kegagalan integritas data dan perangkat lunak berhubungan dengan kode dan +infrastruktur yang tidak melindungi terhadap pelanggaran integritas. Suatu +contoh ini adalah dimana suatu aplikasi mengandalkan pada plugin, pustaka, atau +modul dari sumber-sumber, repostori, dan content delivery network (CDN) yang +tidak terpercaya. Suatu pipeline CI/CD yang tidak aman bisa memperkenalkan +potensi akses tanpa otorisasi, kode jahat, atau terkomprominya sistem. +Terakhir, banyak aplikasi sekarang menyertakan fungsionalitas pembaruan +otomatis, dimana pembaruan diunduh tanpa adanya verifikasi integritas yang +cukup dan diterapkan terhadap aplikasi yang sebelumnya terpercaya. +Penyerang bisa berpotensi mengunggah pembaruan milik mereka sendiri untuk +didistribusikan dan dijalankan pada semua instalasi. Contoh lain adalah dimana +objek atau data yang dienkoding/diserialisasi ke dalam struktur yang dapat +dilihat dan dimodifikasi oleh penyerang rentan terhadap deserialisasi yang +tidak aman. + +## Bagaimana Mencegah + +- Gunakan tanda tangan digital atau mekanisme serupa untuk memverifikasi + bahwa perangkat lunak atau data berasal dari sumber yang diharapkan dan + tidak diubah. + +- Pastikan pustaka dan dependensi, seperti npm atau Maven, menggunakan + repositori yang terpercaya. Apabila Anda punya profil dengan risiko lebih + tinggi, pertimbangkan untuk mewadahi suatu repositori internal yang + diketahui baik yang diperiksa. + +- Pastikan alat keamanan rantai pasokan perangkat lunak, seperti OWASP + Dependency Check atau OWASP CycloneDX digunakan untuk memverifikasi bahwa + komponen tidak memiliki kerentanan yang sudah diketahui. + +- Pastikan adanya proses peninjauan ketika mengubah kode dan konfigurasi + untuk meminimalisir kemungkinan kode atau konfigurasi berbahaya masuk ke + dalam *pipeline* perangkat lunak Anda. + +- Pastikan *CI/CD pipeline* Anda memiliki segregasi, konfigurasi, dan + kontrol akses yang tepat untuk memastikan integritas kode yang masuk + mulai dari proses *build* hingga proses *deployment*/penggelaran. + +- Pastikan data terserialisasi yang tidak ditanda-tangani atau tidak + terenkripsi ini tidak terkirim ke klien yang tidak dipercaya tanpa + adanya pengecekan integritas atau tanda tangan digital untuk mendeteksi + pengubahan atau pemutaran ulang data yang telah diserialisasi. ## Contoh Skenario Penyerangan -**Skenario #1 Pembaharuan tanpa tanda tangan**: Mayoritas dari router rumahan, decoder, firmware perangkat, dan perangkat lainnya tidak memverifikasi pembaharuan lewat firmware yang telah di tandatangani/sudah valid. -Firmware yang tidak ditandatangani / tidak valid merupakan target yang menarik bagi penyerang dan diperkirakan daya tariknya semakin lama akan semakin tinggi -Hal ini merupakan persoalan/ancaman yang cukup besar karena seringkali tidak ada mekanisme untuk memulihkan/memperbaiki selain memperbaikinya menggunakan versi firmware yang baru dan menunggu versi firmware sebelumnya kadaluarsa. - - -**Skenario #2 Pembaharuan berbahaya SolarWinds**: Serangan siber bertingkat nasional atau serangan yang melibatkan suatu negara / bangsa terkenal dengan serangannya terhadap mekanisme pembaharuan, **SolarWinds Orion attack** merupakan salah satu serangan bertingkat nasional yang patut diperhatikan. Perlu diketahui perusahaan yang mengembangkan SolarWinds memiliki proses pembaharuan yang berintegritas atau aman dan proses pembuatan perangkat lunak yang aman. Meskipun demikian proses yang aman ini masih dapat di tumbangkan atau diganggu, dan selama beberapa bulan perusahaan ini mendistribusikan pembaharuan berbahaya yang ditargetkan ke lebih dari 18.000 organisasi, sekitar 100 atau lebih organisasi terkena dampak dari pembaharuan ini. -Insiden ini termasuk salah satu insiden yang konsekuensi nya dapat berpengaruh besar, mempengaruhi banyak hal dan salah satu insiden yang paling signifikan dalam sejarah **Gagalnya Menjaga Integritas Data dan Perangkat Lunak**. - -**Skenario #3 Deserialisasi Yang Tidak Aman**: Aplikasi React memanggil satu set layanan mikro Spring Boot. Sebagai programmer fungsional, mereka mencoba memastikan bahwa kode mereka tidak dapat diubah. Solusi yang mereka hasilkan adalah membuat serial status pengguna dan meneruskannya bolak-balik dengan setiap permintaan. Seorang penyerang memperhatikan tanda tangan objek Java "R00", dan menggunakan alat Pembunuh Serial Java untuk mendapatkan eksekusi kode jarak jauh pada server aplikasi. +**Skenario #1 Pembaruan tanpa tanda tangan**: Banyak router rumahan, set top +box, firmware perangkat, dan lainnya tidak memverifikasi pembaruan lewat +firmware yang telah ditandatangani. Firmware yang tidak ditandatangani +merupakan target yang semakin berkembang bagi penyerang dan diperkirakan akan +semakin parah. Ini merupakan persoalan/ancaman yang cukup besar karena sering +kali tidak ada mekanisme untuk remediasi selain memperbaikinya pada versi +mendatang dan menunggu versi sebelumnya kedaluwarsa. + +**Skenario #2 Pembaharuan berbahaya SolarWinds**: Nation-state telah diketahui +menyerang mekanisme pembaruan, dengan serangan terkini yang patut diperhatikan +adalah serangan SolarWinds Orion. Perusahaan yang mengembangkan perangkat lunak +tersebut memiliki proses build dan integritas pembaruan yang aman. Namun, ini +berhasil dibelokkan, dan selama beberapa bulan, perusahaan mendistribusikan +suatu pembaruan jahat yang sangat ditargetkan ke lebih dari 18.000 organisasi, +yang sekitar 100 di antaranya terdampak. Ini adalah satu dari pembobolan yang +paling merentang luas dan paling signifikan dari sifat ini dalam sejarah. + +**Skenario #3 Deserialisasi Yang Tidak Aman**: Aplikasi React memanggil satu +set layanan mikro Spring Boot. Sebagai programmer fungsional, mereka mencoba +memastikan bahwa kode mereka tidak dapat diubah. Solusi yang mereka hasilkan +adalah men-serial-kan keadaan pengguna dan meneruskannya bolak-balik dengan +setiap permintaan. Seorang penyerang memperhatikan tanda tangan objek Java +"rO0" (dalam base64), dan menggunakan alat Java Serial Killer untuk mendapatkan +eksekusi kode jarak jauh pada server aplikasi. ## Referensi -- [OWASP Cheat Sheet: Software Supply Chain Security] (Akan Segera Datang) -- [OWASP Cheat Sheet: Secure build and deployment] (Akan Segera Datang) +- [OWASP Cheat Sheet: Software Supply Chain Security](Akan Segera Datang) +- [OWASP Cheat Sheet: Secure build and deployment](Akan Segera Datang) - [OWASP Cheat Sheet: Infrastructure as Code](https://cheatsheetseries.owasp.org/cheatsheets/Infrastructure_as_Code_Security_Cheat_Sheet.html) - [OWASP Cheat Sheet: Deserialization](https://www.owasp.org/index.php/Deserialization_Cheat_Sheet) - [SAFECode Software Integrity Controls](https://safecode.org/publication/SAFECode_Software_Integrity_Controls0610.pdf) @@ -60,7 +99,7 @@ Insiden ini termasuk salah satu insiden yang konsekuensi nya dapat berpengaruh b - [CodeCov Bash Uploader Compromise](https://about.codecov.io/security-update) - [Securing DevOps by Julien Vehent](https://www.manning.com/books/securing-devops) -## Daftar Klasifikasi CWE +## Daftar CWE yang Dipetakan [CWE-345 Insufficient Verification of Data Authenticity](https://cwe.mitre.org/data/definitions/345.html) [CWE-353 Missing Support for Integrity Check](https://cwe.mitre.org/data/definitions/353.html) diff --git a/2021/docs/A09_2021-Security_Logging_and_Monitoring_Failures.id.md b/2021/docs/A09_2021-Security_Logging_and_Monitoring_Failures.id.md index 5ab51bc7b..8b59f2d30 100644 --- a/2021/docs/A09_2021-Security_Logging_and_Monitoring_Failures.id.md +++ b/2021/docs/A09_2021-Security_Logging_and_Monitoring_Failures.id.md @@ -1,136 +1,148 @@ -# A09:2021 – Kegagalan dalam Keamanan Logging dan Monitoring +# A09:2021 – Kegagalan Pemantauan dan Pencatatan Log Keamanan ![icon](assets/TOP_10_Icons_Final_Security_Logging_and_Monitoring_Failures.png){: style="height:80px;width:80px" align="right"} ## Faktor-Faktor -| Klasifikasi CWE | Tingkat Kejadian Maksimum | Rata - Rata Tingkat kejadian | Cakupan Maksimum | Rata - Rata Cakupan | Rata-rata Bobot Eksploitasi | Rata - Rata Bobot Dampak | Total Kejadian | Total CVEs | +| CWE Dipetakan | Tingkat Kejadian Maksimum | Rata-rata Tingkat kejadian | Rata-rata Eksploitasi Terbobot | Rata-rata Dampak Terbobot | Cakupan Maksimum | Rata-rata Cakupan | Total Kejadian | Total CVE | |:-------------:|:--------------------:|:--------------------:|:--------------:|:--------------:|:----------------------:|:---------------------:|:-------------------:|:------------:| -| 4 | 19.23% | 6.51% | 53.67% | 39.97% | 6.87 | 4.99 | 53,615 | 242 | - -## Tinjauan - -Kegagalan dalam Keamanan Logging dan Monitoring datang dari survey industri (#3), naik -sedikit dari posisi ke-10 di dalam OWASP top 10 2017. Mencatat dan memonitor dapat menjadi -sebuah kesulitan untuk melakukan testing, seringkali harus menggunakan tindakan seperti -wawancara atau bertanya bila serangan telah terdeksi selama tes penetrasi. -Dalam kategori ini juga tidak terlalu banyak data CVE/CVSS yang ada, -tetapi dalam mendeteksi kemudian merespon dalam penjebolan sangatlah krusial. -visibilitas, peringatan insiden, dan forensik sangatlah berdampak pada hal tersebut. -kategori ini memperluas *CWE-778 Insufficient Logging* dengan memasukan *CWE-117 Improper Output Neutralization -for Logs*, *CWE-223 Omission of Security-relevant Information*, dan *CWE-532 Insertion of Sensitive Information into Log File*. +| 4 | 19,23% | 6,51% | 6,87 | 4,99 | 53,67% | 39,97% | 53.615 | 242 | + +## Ringkasan + +Kegagalan Pemantauan dan Pencatatan Log Keamanan datang dari survey komunitas +Top 10 (#3), naik sedikit dari posisi ke-10 di dalam OWASP Top 10 2017. +Pencatatan log dan pemantaun bisa sulit diuji, sering kali melibatkan +wawancara atau bertanya apakah serangan telah terdeksi selama uji penetrasi. +Tidak banyak data CVE/CVSS yang ada untuk kategori ini, tetapi mendeteksi dan +merespon penjebolan sangatlah penting. Itu bisa sangat berdampak bagi +akuntabilitas, visibilitas, peringatan insiden, dan forensik. +Kategori ini memperluas lebih dari *CWE-778 Insufficient Logging* dengan +memasukan *CWE-117 Improper Output Neutralization for Logs*, *CWE-223 Omission +of Security-relevant Information*, dan *CWE-532 Insertion of Sensitive +Information into Log File*. ## Deskripsi -Kembali ke OWASP Top 2021, Kategori ini membantu untuk mendeteksi, meningkatkan dan respon -terhadap penjebolan yang sedang aktif. Tanpa mencatat dan memonitor, penjebolan tidak -dapat dideteksi. Ketidakcukup melakukan log, deteksi, memonitor dan respon aktif terjadi setiap waktu: +Kembali ke OWASP Top 10 2021, kategori ini membantu untuk mendeteksi, +mengeskalasi, dan merespon terhadap penjebolan yang sedang aktif. Tanpa +pencatatan log dan pemantauan, penjebolan tidak dapat dideteksi. Pencatatan +log, deteksi, pemantauan, dan respon aktif yang tidak memadai terjadi setiap +kali: -- Kejadian yang dapat di Audit, seperti login, - kegagalan login dan transaksi dengan nilai yang tinggi tidak di catat. +- Kejadian yang dapat diaudit, seperti login, kegagalan login, dan transaksi + dengan nilai tinggi tidak dicatat. -- Peringatan dan Error tidak menghasilkan pencatatan yang - memadai atau catatan pesan yang tidak jelas. +- Peringatan dan error tidak menghasilkan pencatatan, pencatatan yang tidak + memadai, atau catatan pesan yang tidak jelas. -- Log dari aplikasi dan API tidak di monitor untuk aktifitas mencurigakan. +- Log dari aplikasi dan API tidak dipantau untuk aktivitas mencurigakan. - Log hanya disimpan secara lokal. -- Threshold peringatan yang sesuai dan proses dari respon eskalasi tidak efektif. +- Ambang batas peringatan yang sesuai dan proses eskalasi respon tidak siap + atau tidak efektif. -- Tool Penetration testing dan Scan dari dynamic application security testing (DAST) (seperti OWASP ZAP) tidak memicu peringatan. +- Alat uji penetrasi dan pemindaian dari dynamic application security + testing (DAST) (seperti OWASP ZAP) tidak memicu peringatan. -- Aplikasi tidak dapat mendeteksi, mengeskalasi atau memperingati untuk serangan aktif - di waktu sebenarnya(real-time) atau bahkan mendekati waktu sebenarnya. +- Aplikasi tidak dapat mendeteksi, mengeskalasi, atau memperingati adanya + serangan aktif seketika (real-time) atau hampir seketika (near real-time). -Anda sangatlah rentan terhadap kebocoran data saat pencatatan dan peringatan kejadian -terlihat kepada user atau bahkan penyerang (lihat A01:2021 - Broken Access Control) +Anda sangatlah rentan terhadap kebocoran informasi dengan membuat kejadian +pencatatan log dan peringatan terlihat kepada user atau bahkan penyerang +(lihat [A01:2021 - Broken Access Control](A01_2021-Broken_Access_Control.id.md)) ## Cara Mencegah Pengembang harus mengimplementasikan beberapa atau semua kontrol dibawah ini yang tergantung pada risiko dari aplikasi: -- Pastikan semua kesalahan login, kontrol akses dan validasi input dari server-side - dapat di catat dengan konteks pengguna yang cukup untuk mengidentifikasikan - akun yang mencurigakan atau jahat serta catatan tersebut di simpan - dengan waktu yang cukup untuk analisa forensik yang terlambat. +- Pastikan semua kegagalan login, kontrol akses, dan validasi masukan + sisi server dapat dicatat dengan konteks pengguna yang cukup untuk + mengidentifikasi akun yang mencurigakan atau jahat serta disimpan + dalam waktu yang cukup untuk analisa forensik yang tertunda. -- Pastikan semua catatan dihasilkan dalam format dimana - solusi pengelola catatan dapat dengan mudah digunakan. +- Pastikan semua log dihasilkan dalam format dimana + solusi manajemen log dapat dengan mudah memakainya. -- Pastikan data catatan telah di encode dengan benar untuk - mencegah injeksi atau serangan pada pencatatan atau sistem monitor. +- Pastikan data log telah di-encode dengan benar untuk mencegah injeksi + atau serangan pada sistem pencatatan log atau pemantauan. -- Pastikan transaksi dengan nilai yang tinggi - memiliki jejak audit dengan kontrol integritas - untuk mencegah gangguan dan penghapusan, - seperti hanya dapat ditambahkan ke database atau yang mirip seperti itu. +- Pastikan transaksi nilai tinggi memiliki jejak audit dengan kontrol + integritas untuk mencegah gangguan dan penghapusan, + seperti database yang *append-only* atau yang serupa. -- Tim DevSecOps harus membuat monitoring secara efektif dalam memonitor dan memperingati - aktifitas mencurigakan yang terdeteksi dan merespon secara cepat. +- Tim DevSecOps harus membuat pemantauan dan pemberi peringatan yang + efektif sehingga aktivitas mencurigakan terdeteksi dan direspon secara + cepat. -- Membuat atau adopsi sebuah respon insiden dan rencana pemulihan, - seperti NIST 800-61r2 atau versi atas nya. +- Membuat atau adopsi sebuah rencana respon insiden dan pemulihan, + seperti National Institute of Standards and Technology (NIST) 800-61r2 + atau versi setelahnya. -There are commercial and open-source application protection frameworks -such as the OWASP ModSecurity Core Rule Set, and open-source log -correlation software, such as the ELK stack, that feature custom -dashboards and alerting. +Ada kerangka kerja proteksi aplikasi komersil dan open source seperti misalnya +OWASP ModSecurity Core Rule Set, dan perangkat lunak korelasi log open source, +seperti stack ELK, yang memiliki fitur dasbor dan pemberian peringatan yang +dapat disesuaikan. ## Contoh Skenario Penyerangan -**Skenario #1:** oeprator website Provider Rencana Kesehatan anak-anak -tidak dapat mendeteksi penerobosan dikarenakan kurang nya dalam memonitor -dan mencatat. pihak luar menginformasikan kepada provider bahwa penyerang -memiliki akses dan telah memodifikasi ribuan rekam medis yang sensitif -dari 3.5 juta anak. tinjauan pasca insiden telah menemukan bahwa -pengembang website tidak menindak kerentanan yang signifikan. -seperti disana tidak ada pencatatan atau pemonitoran dari sistem, -penjebolan data telah berperkembang dari tahun 2013, penjebolan -telah aktif lebih dari periode tujuh tahun. - -**Skenario #2:** Sebuah perusahaan penerbangan india besar telah terbobol yang -lebih dari 10 tahun melibatkan jutaan data penumpang. termasuk -passport dan data kartu kredit. Pembobolan data terjadi saat -third party cloud dari hosting provider, tidak menotifikasi -bahwa sistem penerbangan tersebut telah di bobol untuk beberapa waktu. - -**Skenario #3:** Sebuah perusahaan penerbangan eropa besar menderita sebuah kebobolan -laporan GDPR yang dapat dilaporkan. Kebobolan tersebut telah dikabrkan -dikarenakan oleh kerentanan aplikasi keamanan pembayaran di eksploitasi -penyerang yang telah memanen lebih dari 400.000 rekam pembayaran pelanggan. -perushaan penerbangan tersebut telah di denda sebesar 20 juta pound -sehingga menghasilkan pengatur privacy. +**Skenario #1:** Operator situs web penyedia rencana kesehatan anak-anak +tidak dapat mendeteksi penerobosan karena ketiadaan pemantauan dan pencatatan +log. Pihak luar menginformasikan kepada penyedia bahwa penyerang telah +mengakses dan memodifikasi ribuan rekam medis yang sensitif dari 3.5 juta +anak. Tinjauan pasca insiden telah menemukan bahwa pengembang situs web belum +mengatasi kerentanan yang signifikan. Karena tidak ada pencatatan log atau +pemantauan sistem, penjebolan data mungkin telah berlangsung sejak 2013, suatu +perioda lebih dari tujuh tahun. + +**Skenario #2:** Sebuah perusahaan penerbangan India besar telah terbobol +selama lebih dari sepuluh tahun melibatkan data pribadi jutaan penumpang, +termasuk paspor dan data kartu kredit. Pembobolan data terjadi pada +penyedia hosting cloud pihak ketiga, yang memberitahu ke perusahaan penerbangan +tentang pembobolan setelah sekian lama. + +**Skenario #3:** Sebuah perusahaan penerbangan Eropa besar mengalami kebobolan +GDPR yang dapat dilaporkan. Kebobolan tersebut dikabarkan disebabkan oleh +kerentanan aplikasi keamanan pembayaran yang dieksploitasi oleh penyerang, +yang telah memanen lebih dari 400.000 rekam pembayaran pelanggan. +Perusahaan penerbangan tersebut telah didenda sebesar 20 juta pound sebagai +akibatnya oleh regulator privasi. ## Referensi -- [OWASP kontrol proaktif OWASP Proactive Controls: Mengimplementasi - Pencatatan dan Pemonitoran](https://owasp.org/www-project-proactive-controls/v3/en/c9-security-logging.html) +- [OWASP Proactive Controls: Implement Logging and + Monitoring](https://owasp.org/www-project-proactive-controls/v3/en/c9-security-logging.html) -- [OWASP standart verifikasi keamanan: Pencatatan V8 dan - Pemonitoran](https://owasp.org/www-project-application-security-verification-standard) +- [OWASP Application Security Verification Standard: V7 Logging and + Monitoring](https://owasp.org/www-project-application-security-verification-standard) -- [OWASP Panduan melakukan Tes: Tes untuk code Error yang - mendetil ](https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Application_Security_Testing/08-Testing_for_Error_Handling/01-Testing_for_Error_Code) +- [OWASP Testing Guide: Testing for Detailed Error + Code](https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Application_Security_Testing/08-Testing_for_Error_Handling/01-Testing_for_Error_Code) + +- [OWASP Cheat Sheet: + Application Logging Vocabulary](https://cheatsheetseries.owasp.org/cheatsheets/Application_Logging_Vocabulary_Cheat_Sheet.html) - [OWASP Cheat Sheet: Logging](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html) -- [Integritas Data: Pemulihan dari ransomware dan peristiwa - destruktif](https://csrc.nist.gov/publications/detail/sp/1800-11/final) +- [Data Integrity: Recovering from Ransomware and Other Destructive + Events](https://csrc.nist.gov/publications/detail/sp/1800-11/final) + +- [Data Integrity: Identifying and Protecting Assets Against + Ransomware and Other Destructive + Events](https://csrc.nist.gov/publications/detail/sp/1800-25/final) -- [Integritas Data: Identifikasi dan melindungi asset dari - ransomware dan hal peristiwa destruktif - lainnya](https://csrc.nist.gov/publications/detail/sp/1800-25/final) +- [Data Integrity: Detecting and Responding to Ransomware and Other + Destructive + Events](https://csrc.nist.gov/publications/detail/sp/1800-26/final) -- [Integritas Data: Mendeteksi dan Merespon untuk ransomware dan peristiwa - destruktif lainnya](https://csrc.nist.gov/publications/detail/sp/1800-26/final) +## Daftar CWE yang Dipetakan -## Daftar Klasifikasi CWE +[CWE-117 Improper Output Neutralization for Logs](https://cwe.mitre.org/data/definitions/117.html) -CWE-117 Improper Output Neutralization for Logs +[CWE-223 Omission of Security-relevant Information](https://cwe.mitre.org/data/definitions/223.html) -CWE-223 Omission of Security-relevant Information +[CWE-532 Insertion of Sensitive Information into Log File](https://cwe.mitre.org/data/definitions/532.html) -CWE-532 Insertion of Sensitive Information into Log File +[CWE-778 Insufficient Logging](https://cwe.mitre.org/data/definitions/778.html) -CWE-778 Insufficient Logging diff --git a/2021/docs/A10_2021-Server-Side_Request_Forgery_(SSRF).id.md b/2021/docs/A10_2021-Server-Side_Request_Forgery_(SSRF).id.md index ca13220c2..20a9dad19 100644 --- a/2021/docs/A10_2021-Server-Side_Request_Forgery_(SSRF).id.md +++ b/2021/docs/A10_2021-Server-Side_Request_Forgery_(SSRF).id.md @@ -1,69 +1,106 @@ -# A10:2021 – Server-Side Request Forgery (SSRF) -icon +# A10:2021 – Server-Side Request Forgery (SSRF) ![icon](assets/TOP_10_Icons_Final_SSRF.png){: style="height:80px;width:80px" align="right"} ## Faktor-Faktor -| Klasifikasi CWE | Tingkat Kejadian Maksimum | Rata - Rata Tingkat Kejadian | Cakupan Maximum | Rata - Rata Cakupan | Rata - Rata Bobot Exploitasi | Rata - Rata Bobot Dampak | Total Kejadian | Total CVEs | +| CWE Dipetakan | Tingkat Kejadian Maksimum | Rata-rata Tingkat Kejadian | Rata-rata Exploitasi Terbobot | Rata-rata Dampak Terbobot | Cakupan Maximum | Rata-rata Cakupan | Total Kejadian | Total CVE | |:-------------:|:--------------------:|:--------------------:|:--------------:|:--------------:|:----------------------:|:---------------------:|:-------------------:|:------------:| -| 1 | 2.72% | 2.72% | 67.72% | 67.72% | 8.28 | 6.72 | 9,503 | 385 | +| 1 | 2,72% | 2,72% | 8,28 | 6,72 | 67,72% | 67,72% | 9.503 | 385 | -## Penjelasan Singkat -Kategori ini ditambahkan dari survei 10 komunitas teratas (#1). Data ini menunjukan tingkat insiden yang relatif rendah dengan cakupan pengujian di atas rata-rata serta -nilai dampak dan potensial eksploitasi di atas rata-rata. Entri-entri baru kemungkinan besar menjadi cluster kecil atau tunggal dari CWE - CWE karena tingkat atensi dan tingkat kesadarannya, harapannnya entri-entri baru ini dapat menjadi fokusan riset keamanan dan dapat digolongkan/dimasukkan kedalam kategori/cluster yang lebih besar di edisi mendatang. +## Ringkasan + +Kategori ini ditambahkan dari survei komunitas Top 10 (#1). Data ini +menunjukan tingkat insiden yang relatif rendah dengan cakupan pengujian +di atas rata-rata serta nilai dampak dan potensial eksploitasi di atas +rata-rata. Entri-entri baru kemungkinan besar menjadi cluster kecil atau +tunggal dari Common Weakness Enumerations (CWE) karena tingkat atensi dan +tingkat kesadarannya, harapannnya entri-entri baru ini dapat menjadi fokus +dimasukkan ke dalam kategori yang lebih besar di edisi mendatang. ## Deskripsi -Kecacatan _SSRF_ muncul saat sebuah aplikasi web meminta _remote resource_ tanpa melakukan validasi URL yang di berikan oleh pengguna. Ini memperbolehkan penyerang untuk memaksa aplikasi untuk mengirim _crafted request_ ke destinasi yang tidak diharapkan, meskipun sudah dilindungi oleh _firewall_, VPN, atau tipe lain dari daftar aturan akses jaringan - _Access Control List_ (ACL). +Cacat _SSRF_ muncul saat sebuah aplikasi web meminta _remote resource_ tanpa +melakukan validasi URL yang diberikan oleh pengguna. Ini memperbolehkan +penyerang untuk memaksa aplikasi untuk mengirim _crafted request_ ke destinasi +yang tidak diharapkan, meskipun sudah dilindungi oleh _firewall_, VPN, atau +tipe lain dari _Access Control List_ (ACL) jaringan. -Aplikasi web saat ini menyediakan fitur yang nyaman bagi pengguna akhir, sehingga proses meminta URL menjadi hal yang lumrah. Oleh karena itu, insiden _SSRF_ semakin meningkat. Selain itu, tingkat keparahan _SSRF_ semakin meningkat karena layanan-layanan _cloud_ dan tingkat komplexitas arsitektur _cloud_. +Karena aplikasi web saat ini menyediakan fitur yang nyaman bagi pengguna akhir, +proses meminta URL menjadi hal yang lumrah. Oleh karena itu, insiden _SSRF_ +semakin meningkat. Selain itu, tingkat keparahan _SSRF_ semakin meningkat +karena layanan-layanan _cloud_ dan tingkat komplexitas arsitektur. -## Bagaimana Cara Mencegahnya +## Bagaimana Mencegah +Pengembang dapat mencegah terjadinya _SSRF_ dengan mengimplementasikan +beberapa atau semua tindakan kontrol pertahanan berlapis berikut: -Pengembang dapat mencegah terjadinya _SSRF_ dengan mengimplementasikan beberapa atau semua tindakan kontrol pertahanan berikut: +### **Dari Lapisan Jaringan** -### Dari Network Layer +- Segmentasikan fungsionalitas _remote resource access_ di jaringan yang + berbeda untuk mengurangi dampak dari _SSRF_. -- Segmentasi fitur/fungsi _remote resource access_ di jaringan yang berbeda untuk mengurangi dampak dari _SSRF_. -- Terapkan kebijakan firewall _deny by default_ atau aturan kontrol akses jaringan untuk memblokir semua lalu lintas eksternal kecuali lalu lintas intranet yang penting. - _Petunjuk:_ - ~ Buat / Bangunlah siklus hidup dan hak kepemilikan untuk peraturan firewall berdasarkan aplikasinya. - ~ Catat semua akses jaringan yang melewati firewall baik akses jaringan yang diterima ataupun yang diblokir/tolak (lihat [A09:2021-Security Logging and Monitoring Failures](A09_2021 Security_Logging_and_Monitoring_Failures.md)). +- Terapkan kebijakan firewall _deny by default_ atau aturan kontrol akses + jaringan untuk memblokir semua lalu lintas eksternal kecuali lalu lintas + intranet yang esensial.
+ *Petunjuk:*
+ ~ Jalin kepemilikan dan siklus hidup untuk aturan firewall berdasarkan + aplikasinya.
+ ~ Catat semua aliran jaringan pada firewall yang diterima *dan* yang diblokir + (lihat [A09:2021-Security Logging and Monitoring + Failures](A09_2021-Security_Logging_and_Monitoring_Failures.id.md)). -### Dari Application Layer +### **Dari Lapisan Aplikasi** -- Bersihkan dan validasi semua data inputan yang dimasukkan oleh klien +- Bersihkan dan validasi semua data masukan yang dimasukkan oleh klien -- Terapkan skema URL, port, dan destinasi dengan daftar izin positif +- Paksakan skema URL, port, dan destinasi dengan daftar izin positif - Jangan mengirim respon mentah ke klien - Nonaktifkan pengalihan HTTP -- Perhatikan konsistensi URL untuk menghindari serangan _DNS rebinding_ dan serangan _(TOCTOU) time of check, time of use_ +- Perhatikan konsistensi URL untuk menghindari serangan _DNS rebinding_ + dan serangan *race condition* _(TOCTOU) time of check, time of use_ -Jangan gunakan daftar penolakan atau ekspresi reguler untuk mitigasi _SSRF_. Penyerang mempunyai daftar muatan, alat, dan kemampuan untuk membobol/melewati daftar penolakan. +Jangan gunakan daftar penolakan atau ekspresi reguler untuk mitigasi _SSRF_. +Penyerang mempunyai daftar muatan, alat, dan kemampuan untuk melewati daftar +penolakan. -### Tindakan Lainnya Yang Dapat Dipertimbangkan +### **Tindakan Lain yang dapat dipertimbangkan:** -- Jangan _deploy_ layanan yang berhubungan dengan keamanan pada sistem yang berada di barisan depan, contohnya _OpenId_. Kontrol lalu lintas lokal pada sistem ini (Localhost). +- Jangan _deploy_ layanan yang berhubungan dengan keamanan pada sistem yang + berada di barisan depan (mis. _OpenId_). Kendalikan lalu lintas lokal pada + sistem ini (mis. localhost). -- Khusus untuk _frontends_ dengan pengguna/grup pengguna yang loyal atau berdedikasi serta dapat dikelola gunakanlah enkripsi jaringan (VPN) pada sistem independen mengingat adanya kebutuhan proteksi yang sangat tinggi. +- Untuk _frontend_ dengan pengguna/grup pengguna berdedikasi serta dapat + dikelola gunakanlah enkripsi jaringan (mis. VPN) pada sistem independen + mengingat adanya kebutuhan proteksi yang sangat tinggi. ## Contoh Skenario Penyerangan -Penyerang dapat menggunakan _SSRF_ untuk menyerang sitem yang telah dilindungi dibalik firewall aplikasi web, firewall,atau jaringan ACL dengan skenario-skenario penyerangan sebagai berikut: +Penyerang dapat menggunakan _SSRF_ untuk menyerang sitem yang telah dilindungi +di balik firewall aplikasi web, firewall, atau ACL jaringan dengan skenario +sebagai berikut: -**Skenario #1:** Memindai port server internal. Apabila arsitektur jaringan tidak tersegmentasi, penyerang dapat mendapatkan gambaran bagaimana jaringan internal terbentuk -dan dapat menentukan port-port mana yang terbuka atau tertutup pada server internal berdasarkan hasil koneksi, waktu yang dibutuhkan untuk melakukan koneksi atau waktu yang dibutuhkan untuk menolak koneksi yang bermuatan _SSRF_. +**Skenario #1:** Memindai port server internal – Apabila arsitektur jaringan +tidak tersegmentasi, penyerang bisa memetakan jaringan internal dan dapat +menentukan port-port mana yang terbuka atau tertutup pada server internal dari +hasil koneksi atau waktu yang dibutuhkan untuk melakukan koneksi atau untuk +menolak koneksi yang bermuatan _SSRF_. -**Skenario #2:** Kebocoran data sensitif. Penyerang dapat mengakses file lokal seperti `file:///etc/passwd` dan `http://localhost:28017/`. +**Skenario #2:** Pengungkapan data sensitif – Penyerang dapat mengakses file +lokal atau layanan internal untuk memperoleh informasi sensitif seperti +`file:///etc/passwd` dan `http://localhost:28017/`. -**Skenario #3:** Akses penyimpanan metadata dari layanan cloud - Mayoritas penyedia layanan cloud memiliki penyimpanan metadata seperti `http://169/254.169.254/`. -Seorang penyerang dapat membaca metada tersebut untuk mendapatkan informasi sensitif. +**Skenario #3:** Mengakses penyimpanan metadata dari layanan cloud – Mayoritas +penyedia layanan cloud memiliki penyimpanan metadata seperti +`http://169/254.169.254/`. Seorang penyerang dapat membaca metadata tersebut +untuk mendapatkan informasi sensitif. -**Skenario #4:** Penyusupan layanan internal - Penyerang dapat menyalahgunakan layanan internal untuk melakukan serangan lebih lanjut seperti _Remote Code Execution (RCE)_ atau _Denial Of Service (DOS)_. +**Skenario #4:** Penyusupan layanan internal – Penyerang dapat menyalahgunakan +layanan internal untuk melakukan serangan lebih lanjut seperti _Remote Code +Execution (RCE)_ atau _Denial Of Service (DOS)_. ## Referensi diff --git a/2021/docs/A11_2021-Next_Steps.id.md b/2021/docs/A11_2021-Next_Steps.id.md index dd67582d1..46d635884 100644 --- a/2021/docs/A11_2021-Next_Steps.id.md +++ b/2021/docs/A11_2021-Next_Steps.id.md @@ -1,14 +1,14 @@ # A11:2021 – Langkah Selanjutnya -Secara desaiin, OWASP Top 10 secara bawaan terbatas ke 10 risiko yang paling signifikan. Setiap OWASP Top 10 memiliki risiko-risiko yang lama dipertimbangkan untuk disertakan dan nyaris lolos, tapi pada akhirnya, mereka tidak berhasil. Tak peduli bagaimana kami mencoba menginterpretasi atau memelintir data, risiko-risiko lain lebih unggul dan berdampak. +Secara desain, OWASP Top 10 secara bawaan terbatas ke 10 risiko yang paling signifikan. Setiap OWASP Top 10 memiliki risiko-risiko yang lama dipertimbangkan untuk disertakan dan nyaris lolos, tapi pada akhirnya, mereka tidak berhasil. Tak peduli bagaimana kami mencoba menginterpretasi atau memelintir data, risiko-risiko lain lebih unggul dan berdampak. Bagi organisasi yang sedang menuju ke program appsec yang matang atau konsultasi keamanan atau vendor peralatan yang berharap mengembangkan cakupan bagi tawaran mereka, empat masalah berikut layak ditempuh untuk diidentifikasi dan diperbaiki. ## Masalah-masalah Kualitas Kode -| Klasifikasi CWE | Tingkat Kejadian Maks | Rerata Tingkat kejadian | Rerate Eksploatasi Terbobot | Rerata Dampak Terbobot | Cakupan Maks | Rerata Cakupan | Total Kejadian | Total CVE | +| CWE Dipetakan | Tingkat Kejadian Maks | Rerata Tingkat kejadian | Rerate Eksploatasi Terbobot | Rerata Dampak Terbobot | Cakupan Maks | Rerata Cakupan | Total Kejadian | Total CVE | |:-------------:|:--------------------:|:--------------------:|:--------------:|:--------------:|:----------------------:|:---------------------:|:-------------------:|:------------:| -| 38 | 49.46% | 2.22% | 7.1 | 6.7 | 60.85% | 23.42% | 101736 | 7564 | +| 38 | 49,46% | 2,22% | 7,1 | 6,7 | 60,85% | 23,42% | 101736 | 7564 | - **Deskripsi.** Masalah kualitas kode termasuk pola atau cacat keamanan, memakai ulang variabel untuk berbagai kegunaan, eksposur informasi sensitif dalam luaran pengawakutuan, kesalahan off-by-one, kondisi race saat pemeriksaan/saat penggunaan (time of check/time of use, TOCTOU), kesalahan konversi unsigned atau signed, use after free, dan lebih banyak lagi. Ciri khas bagian ini adalah mereka biasanya bisa diidentifikasi dengan flag kompiler yang ketat, alat analisis kode statik, dan plugin IDE linter. Bahasa-bahasa modern dari desain mengeliminasi banyak masalah ini, seperti konsep peminjaman dan kepemilikan memori Rust, desain thread Rust, dan penentuan tipe ketat dan pemeriksaan batas Go. @@ -24,9 +24,9 @@ Bagi organisasi yang sedang menuju ke program appsec yang matang atau konsultasi ## Denial of Service -| Klasifikasi CWE | Tingkat Kejadian Maks | Rerata Tingkat kejadian | Rerate Eksploatasi Terbobot | Rerata Dampak Terbobot | Cakupan Maks | Rerata Cakupan | Total Kejadian | Total CVE | +| CWE Dipetakan | Tingkat Kejadian Maks | Rerata Tingkat kejadian | Rerate Eksploatasi Terbobot | Rerata Dampak Terbobot | Cakupan Maks | Rerata Cakupan | Total Kejadian | Total CVE | |:-------------:|:--------------------:|:--------------------:|:--------------:|:--------------:|:----------------------:|:---------------------:|:-------------------:|:------------:| -| 8 | 17.54% | 4.89% | 8.3 | 5.9 | 79.58% | 33.26% | 66985 | 973 | +| 8 | 17,54% | 4,89% | 8,3 | 5,9 | 79,58% | 33,26% | 66985 | 973 | - **Deskripsi**. Denial of service selalu mungkin dengan sumber daya yang cukup. Namun, desain dan praktek pengodan memiliki hubungan yang signifikan pada magnituda dari penyangkalan layanan. Misalkan seseorang dengan tautan dapat mengakses sebuah berkas besar, atau transaksi yang mahal secara komputasi terjadi pada setiap halaman. Dalam kasus itu, penyangkalan layanan memerlukan upaya lebih sedikit untuk dijalankan. @@ -41,15 +41,15 @@ Bagi organisasi yang sedang menuju ke program appsec yang matang atau konsultasi ## Kesalahan Manajemen Memori -| Klasifikasi CWE | Tingkat Kejadian Maks | Rerata Tingkat kejadian | Rerate Eksploatasi Terbobot | Rerata Dampak Terbobot | Cakupan Maks | Rerata Cakupan | Total Kejadian | Total CVE | +| CWE Dipetakan | Tingkat Kejadian Maks | Rerata Tingkat kejadian | Rerate Eksploatasi Terbobot | Rerata Dampak Terbobot | Cakupan Maks | Rerata Cakupan | Total Kejadian | Total CVE | |:-------------:|:--------------------:|:--------------------:|:--------------:|:--------------:|:----------------------:|:---------------------:|:-------------------:|:------------:| -| 14 | 7.03% | 1.16% | 6.7 | 8.1 | 56.06% | 31.74% | 26576 | 16184 | +| 14 | 7,03% | 1,16% | 6,7 | 8,1 | 56,06% | 31,74% | 26576 | 16184 | - **Deskripsi**. Aplikasi web cenderung ditulis dalam bahasa-bahasa yang memorinya dikelola, seperti Java, .NET, atau node.js (JavaScript atau TypeScript). Namun, bahasa-bahasa ini ditulis dalam bahasa sistem yang memiliki masalah-masalah manajemen memori, seperti buffer overflow atau heap overflow, use after free, integer overflow, dan lebih banyak lagi. Ada banyak 'sandbox escape' selama bertahun-tahun yang membuktikan bahwa karena bahasa aplikasi web secara nominal "aman" memori, landasannya tidak. - **Bagaimana mencegahnya**. Banyak API modern yang kini ditulis dalam bahasa-bahasa yang aman-memori seperti Rust atau Go. Dalam kasus Rust, keamanan memori adalah fitur sangat penting dari bahasa. Untuk kode yang telah ada, penggunaan flag compiler yang ketat, penentuan tipe yang kuat, analisis kode statik, dan uji fuzz bisa menguntungkan dalam mengidentifikasi kebocoran memori, memori, dan array overrun, dan lebih banyak lagi. -- **Contoh skenario serangan**. Buffer overflow dan heap overflow masih menjadi andalah para penyerang selama bertahun-tahun. Penyerang mengirim data ke suatu program, yang disimpannya dalam buffer stack yang berukuran terlalu kecil. Hasilnya adalah informasi pada call stack ditimpa, termasuk pointer balik fungsi. Data menata nilai pointer balik sehingga ketika fungsi kembali, itu memindah kendali ke kode jahat yang dimuat dalam data penyerang. +- **Contoh skenario serangan**. Buffer overflow dan heap overflow masih menjadi andalan para penyerang selama bertahun-tahun. Penyerang mengirim data ke suatu program, yang disimpannya dalam buffer stack yang berukuran terlalu kecil. Hasilnya adalah informasi pada call stack ditimpa, termasuk pointer balik fungsi. Data menata nilai pointer balik sehingga ketika fungsi kembali, itu memindah kendali ke kode jahat yang dimuat dalam data penyerang. - **Referensi** - [OWASP Vulnerabilities: Buffer Overflow](https://owasp.org/www-community/vulnerabilities/Buffer_Overflow) diff --git a/2021/docs/index.id.md b/2021/docs/index.id.md index 2a01d5970..773803dbe 100644 --- a/2021/docs/index.id.md +++ b/2021/docs/index.id.md @@ -10,94 +10,88 @@ Terima kasih sebesar-besarnya ke semua orang yang menyumbangkan waktu dan data m ## Apa yang berubah di Top 10 untuk 2021 -Terdapat tiga kategori baru, empat kategori dengan penamaan dan perbuahan ruang lingkup, dan beberapa konsolidasi baru di Top 10 untuk 2021 +Terdapat tiga kategori baru, empat kategori dengan penamaan dan perubahan ruang lingkup, dan beberapa konsolidasi baru di Top 10 untuk 2021. Kami telah mengubah nama ketika diperlukan untuk berfokus pada akar masalah daripada gejala. -![license](assets/mapping.png) +![Mapping](assets/mapping.png) -- **A01:2021-Broken Access Control** naik dari posisi kelima; 94% dari aplikasi yang telah diuji dengan broken access kontrol dalam beberapa bentuk. 34 CWE yang dipetakan ke Broken Access Control memiliki lebih banyak kemunculan dalam aplikasi daripada kategori lainnya. -- **A02:2021-Cryptographic Failures** menggeser satu posisi menjadi #2, sebelumnya dikenal sebagai Pengungkapan Data Sensitif, yang merupakan gejala luas dan bukan penyebab utama. Fokus baru di sini adalah pada kegagalan yang terkait dengan Kriptografi yang sering mengarah pada Pengungkapan Data Sensitif atau sistem yang telah terinfeksi oleh hacker. -- **A03:2021-Injection** turun ke posisi ketiga. 94% aplikasi diuji untuk beberapa bentuk injeksi, dan 33 CWE yang dipetakan ke dalam kategori ini memiliki kejadian terbanyak kedua dalam aplikasi. Skrip cross-site sekarang menjadi bagian dari kategori ini dalam edisi ini. -- **A04:2021-Insecure Design** adalah kategori baru untuk tahun 2021, dengan fokus pada resiko yang terkait dengan kekurangan desain. Jika kita ingin benar-benar bergerak sebagai industri, itu membutuhkan lebih banyak penggunaan pemodelan ancaman, pola dan desain yang aman, dan arsitektur referensi -- **A05:2021-Security Misconfiguration** naik dari #6 di edisi sebelumnya; 90% aplikasi diuji untuk beberapa bentuk kesalahan konfigurasi. Dengan lebih banyak perubahan ke software dengan konfigurasi yang banyak, tidak mengherankan melihat kategori ini naik. Kategori sebelumnya untuk XML External Entities (XXE) sekarang menjadi bagian dari kategori ini. -- **A06:2021-Vulnerable and Outdated Components** sebelumnya berjudul Using Components with Known Vulnerabilities dan #2 dalam survei industri, tapi juga memiliki cukup data untuk masuk TOP 10 melalui analisis data. Kategori ini naik dari #9 di tahun 2017 dan merupakan masalah umum yang kami perjuangkan untuk menguji dan menilai resiko. Ini adalah satu-satunya kategori yang tidak memiliki CVE yang dipetakan ke CWE yang disertakan, jadi eksploitasi default dan bobot dampak 5.0 diperhitungkan dalam skornya. -- **A07:2021-Identification and Authentication Failures** sebelumnya dalah Broken Authentication dan turun dari posisi kedua, dan sekarang termasuk CWE yang lebih terkait dengan kegagalan identifikasi. Kategori ini masih merupakan bagian integral dari Top 10, tetapi peningkatan ketersediaan framework yang telah distandarisasi tampaknya membantu. -- **A08:2021-Software and Data Integrity Failures** adalah kategori baru untuk tahun 2021, yang berfokus pada pembuatan asusmsi terkait pembaruan perangkat lunak, data penting, dan pipeline CI/CD tanpa memverifikasi integritas. Salah satu dampak tertinggi dari CVE/CVSS yang dipetakan ke 10 CWE dalam kategori ini. Insecure Deserialization dari tahun 2017 sekarang menjadi bagian dari kategori yang lebih besar ini. -- **A09:2021-Security Logging and Monitoring Failures** sebelumnya Logging dan Monitoring tidak memadai dan ditambahkan dari survei industri (#3), naik dari #10 sebelumnya. Kategori ini diperluas untuk mencakup lebih banyak jenis kegagalan, suatu tantangan untuk diiuji, dan tidak terwakili dengan baik dalam data CVE/CVSS. Namun, kegagalan dalam kategori ini dapat secara langsung mempengaruhi visibilitas, alert pada insiden, dan forensik -- **A10:2021-Server-Side Request Forgery** ditambahkan dari survei industri (#1). Data menunjukkan tingkat insiden yang relatif rendah dengan cakupan pengujian di atas rata-rata, bersama dengan peringkat di atas rata-rata untuk potensi eksploitasi dan dampak. Kategori ini mewakili skenario di mana para profesional industri memberi tahu kami bahwa ini penting, meskipun tidak diilustrasikan dalam data saat ini. +- **[A01:2021-Broken Access Control](A01_2021-Broken_Access_Control.id.md)** naik dari posisi kelima ke kategori dengan risiko keamanan aplikasi web paling serius; data yang disumbangkan mengindikasikan bahwa rata-rata, 3,81% aplikasi yang diuji memiliki satu atau lebih Common Weakness Enumeration (CWE) dengan lebih dari 318k kemunculan CWE dalam kategori risiko ini. 34 CWE yang dipetakan ke Broken Access Control memiliki lebih banyak kemunculan dalam aplikasi daripada kategori lainnya. +- **[A02:2021-Cryptographic Failures](A02_2021-Cryptographic_Failures.id.md)** naik satu posisi menjadi #2, sebelumnya dikenal sebagai **A3:2017-Pengungkapan Data Sensitif**, yang merupakan gejala luas dan bukan akar masalah. Nama yang diperbarui di sini berfokus pada kegagalan yang terkait dengan kriptografi seperti yang sebelumnya tersirat. Kategori ini sering mengarah pada pengungkapan data sensitif atau sistem terkompromi. +- **[A03:2021-Injection](A03_2021-Injection.id.md)** turun ke posisi ketiga. 94% aplikasi diuji untuk beberapa bentuk injeksi dengan laju insidensi maks 19%, laju insidensi rata-rata 3,37%, dan 33 CWE yang dipetakan ke dalam kategori ini memiliki kejadian terbanyak kedua dalam aplikasi dengan 274k kemunculan. Cross-site Scripting sekarang menjadi bagian dari kategori ini dalam edisi ini. +- **[A04:2021-Insecure Design](A04_2021-Insecure_Design.id.md)** adalah kategori baru untuk tahun 2021, dengan fokus pada risiko yang terkait dengan cacat desain. Jika kita ingin benar-benar "bergerak ke kiri" sebagai industri, itu membutuhkan lebih banyak pemodelan ancaman, prinsip dan pola desain yang aman, dan arsitektur referensi. Suatu desain yang tidak aman tidak bisa diperbaiki dengan suatu implementasi sempurna karena secara definisi, kendali keamanan yang diperlukan tidak pernah diciptakan untuk bertahan atas serangan spesifik. +- **[A05:2021-Security Misconfiguration](A05_2021-Security_Misconfiguration.id.md)** naik dari #6 di edisi sebelumnya; 90% aplikasi diuji untuk beberapa bentuk kesalahan konfigurasi, dengan laju insidensi rata-rata 4,5%, dan lebih dari 208k kemunculan dari CWE yang dipetakan ke kategori risiko ini. Dengan lebih banyak pergeseran ke software yang sangat bisa dikonfigurasi, tidak mengherankan melihat kategori ini naik. Kategori sebelumnya untuk **A4:2017-XML External Entities (XXE)** sekarang menjadi bagian dari kategori risiko ini. +- **[A06:2021-Vulnerable and Outdated Components](A06_2021-Vulnerable_and_Outdated_Components.id.md)** sebelumnya berjudul Using Components with Known Vulnerabilities dan #2 dalam survei komunitas, tapi juga memiliki cukup data untuk masuk TOP 10 melalui analisis data. Kategori ini naik dari #9 di tahun 2017 dan merupakan masalah yang telah dikenal, yang kami mengalami kesulitan untuk menguji dan menilai risikonya. Ini adalah satu-satunya kategori yang tidak memiliki CVE yang dipetakan ke CWE yang disertakan, jadi eksploitasi default dan bobot dampak 5.0 diperhitungkan dalam skornya. +- **[A07:2021-Identification and Authentication Failures](A07_2021-Identification_and_Authentication_Failures.id.md)** sebelumnya dalah **A2:2017-Broken Authentication** dan turun dari posisi kedua, dan sekarang termasuk CWE yang lebih terkait dengan kegagalan identifikasi. Kategori ini masih merupakan bagian integral dari Top 10, tetapi peningkatan ketersediaan framework yang telah distandarisasi tampaknya membantu. +- **[A08:2021-Software and Data Integrity Failures](A08_2021-Software_and_Data_Integrity_Failures.id.md)** adalah kategori baru untuk tahun 2021, yang berfokus pada pembuatan asumsi terkait pembaruan perangkat lunak, data penting, dan pipeline CI/CD tanpa memverifikasi integritas. Salah satu dampak tertinggi dari Common Vulnerability and Exposures/Common Vulnerability Scoring System (CVE/CVSS) yang dipetakan ke 10 CWE dalam kategori ini. **A8:2017-Insecure Deserialization** dari tahun 2017 sekarang menjadi bagian dari kategori yang lebih besar ini. +- **[A09:2021-Security Logging and Monitoring Failures](A09_2021-Security_Logging_and_Monitoring_Failures.id.md)** sebelumnya **A10:2017-Logging dan Monitoring** dan ditambahkan dari survei komunitas Top 10 (#3), naik dari #10 sebelumnya. Kategori ini diperluas untuk mencakup lebih banyak jenis kegagalan, suatu tantangan untuk diiuji, dan tidak terwakili dengan baik dalam data CVE/CVSS. Namun, kegagalan dalam kategori ini dapat secara langsung mempengaruhi visibilitas, alert atas insiden, dan forensik. +- **[A10:2021-Server-Side Request Forgery](A10_2021-Server-Side_Request_Forgery.id.md)** ditambahkan dari survei komunitas Top 10 (#1). Data menunjukkan tingkat insiden yang relatif rendah dengan cakupan pengujian di atas rata-rata, bersama dengan peringkat di atas rata-rata untuk potensi Eksploitasi dan Dampak. Kategori ini mewakili skenario di mana para anggota komunitas keamanan memberi tahu kami bahwa ini penting, meskipun tidak diilustrasikan dalam data saat ini. ## Metodologi -Penyusunan dari Top 10 ini lebih didorong oleh data daripada sebelumnya tetapi tidak didorong oleh data yang tidak di verifikasi dahulu. Kami memilih delapan dari sepuluh kategori dari kontribusi data dan 2 kategori dari survei industri tingkat tinggi. Kami melakukan ini karena alasan mendasar, melihat data yang telah dikumpulkan sama dengan melihat ke masa lalu. Peneliti AppSec membutuhkan waktu untuk menemukan kerentanan baru dan cara baru untuk mengujinya. Dibutuhkan waktu untuk mengintegrasikan tes ini ke dalam alat dan proses. Pada saat kita dapat dengan andal menguji kelemahan dalam skala, tahun-tahun kemungkinan telah berlalu. Untuk menyeimbangkan pandangan itu, kami menggunakan survei industri untuk bertanya kepada orang-orang di garis depan apa yang mereka lihat sebagai kelemahan penting yang mungkin belum ditunjukkan oleh data. +Penyusunan dari Top 10 ini lebih didorong oleh data daripada sebelumnya tetapi tidak membabi-buta didorong data. Kami memilih delapan dari sepuluh kategori dari kontribusi data dan 2 kategori dari survei komunitas Top 10 pada tingkat tinggi. Kami melakukan ini karena alasan mendasar, melihat data yang telah dikumpulkan sama dengan melihat ke masa lalu. Peneliti AppSec membutuhkan waktu untuk menemukan kerentanan baru dan cara-cara baru untuk mengujinya. Dibutuhkan waktu untuk mengintegrasikan tes ini ke dalam alat dan proses. Pada saat kita dapat dengan andal menguji kelemahan dalam skala, mungkin beberapa tahun telah berlalu. Untuk menyeimbangkan pandangan itu, kami menggunakan survei komunitas untuk bertanya kepada para pakar pengembangan dan keamanan aplikasi di garis depan, apa yang mereka lihat sebagai kelemahan penting yang mungkin belum ditunjukkan oleh data. Ada beberapa perubahan penting yang kami adopsi untuk terus mematangkan Top 10. -## Bagaimana kategori disusun +## Bagaimana kategori distrukturkan -Beberapa kategori telah berubah dari pemasangan OWASP Top 10 sebelumnya. Berikut adalah ringkasan tingkat tinggi dari perubahan kategori +Beberapa kategori telah berubah dari pemasangan OWASP Top 10 sebelumnya. Berikut adalah ringkasan tingkat tinggi dari perubahan kategori. -Upaya pengumpulan data sebelumnya difokuskan pada subset yang ditentukan sekitar 30 CWE dengan bidang yang meminta temuan tambahan. Kami mengetahui bahwa organisasi akan fokus hanya pada 30 CWE tersebut dan jarang menambahkan CWE tambahan yang mereka lihat. Dalam iterasi ini, kami membukanya dan hanya meminta data, tanpa batasan pada CWE. Kami meminta jumlah aplikasi yang diuji untuk tahun tertentu (mulai 2017), dan jumlah aplikasi dengan setidaknya satu contoh CWE yang ditemukan dalam pengujian. Format ini memungkinkan kami untuk melacak seberapa lazim setiap CWE dalam populasi aplikasi. Kami mengabaikan frekuensi untuk tujuan kami; sementara mungkin diperlukan untuk situasi lain, itu hanya menyembunyikan prevalensi aktual dalam populasi aplikasi. Apakah sebuah aplikasi memiliki empat instans CWE atau 4.000 instans bukanlah bagian dari perhitungan untuk 10 Besar. Kami beralih dari sekitar 30 CWE menjadi hampir 400 CWE untuk dianalisis dalam kumpulan data. Kami berencana untuk melakukan analisis data tambahan sebagai suplemen di masa depan. Peningkatan jumlah CWE yang signifikan ini memerlukan perubahan pada struktur kategori. +Upaya pengumpulan data sebelumnya difokuskan pada subset yang ditentukan dari sekitar 30 CWE dengan bidang yang meminta temuan tambahan. Kami mengetahui bahwa organisasi akan fokus hanya pada 30 CWE tersebut dan jarang menambahkan CWE lain yang mereka lihat. Dalam iterasi ini, kami membukanya dan hanya meminta data, tanpa batasan pada CWE. Kami meminta jumlah aplikasi yang diuji untuk tahun tertentu (mulai 2017), dan jumlah aplikasi dengan setidaknya satu contoh CWE yang ditemukan dalam pengujian. Format ini memungkinkan kami untuk melacak seberapa lazim setiap CWE dalam populasi aplikasi. Kami mengabaikan frekuensi untuk tujuan kami; sementara mungkin diperlukan untuk situasi lain, itu hanya menyembunyikan prevalensi aktual dalam populasi aplikasi. Apakah sebuah aplikasi memiliki empat instansi CWE atau 4.000 instansi bukanlah bagian dari perhitungan untuk Top 10. Kami berubah dari sekitar 30 CWE menjadi hampir 400 CWE untuk dianalisis dalam kumpulan data. Kami berrencana untuk melakukan analisis data tambahan sebagai suplemen di masa depan. Peningkatan jumlah CWE yang signifikan ini memerlukan perubahan pada bagaimana kategori distrukturkan. -Kami menghabiskan beberapa bulan untuk mengelompokkan dan mengkategorikan CWE dan dapat melanjutkannya selama beberapa bulan lagi. Kami harus berhenti di beberapa titik. Ada akar penyebab dan jenis gejala CWE, di mana jenis akar penyebab seperti "Kegagalan Kriptografis" dan "Kesalahan Konfigurasi" kontras dengan jenis gejala seperti "Pengungkapan Data Sensitif" dan "Penolakan Layanan." Kami memutuskan untuk fokus pada akar penyebab bila memungkinkan karena lebih logis untuk memberikan panduan identifikasi dan perbaikan. Berfokus pada akar penyebab di atas gejala bukanlah konsep baru; Sepuluh Besar telah menjadi campuran gejala dan akar penyebab. CWE juga merupakan campuran dari gejala dan akar penyebab; kami hanya menjadi lebih berhati-hati tentang hal itu dan menyebutnya. Ada rata-rata 19,6 CWE per kategori dalam pemasangan ini, dengan batas bawah pada 1 CWE untuk A10:2021-Server-Side Request Forgery (SSRF) hingga 40 CWE dalam A04:2021-Insecure Design. Struktur kategori yang diperbarui ini menawarkan manfaat pelatihan tambahan karena perusahaan dapat fokus pada CWE yang masuk akal untuk bahasa/kerangka kerja. +Kami menghabiskan beberapa bulan untuk mengelompokkan dan mengkategorikan CWE dan dapat melanjutkannya selama beberapa bulan lagi. Kami harus berhenti di beberapa titik. Ada tipe CWE *akar masalah* dan *gejala*, di mana jenis *akar masalah* adalah seperti "Kegagalan Kriptografis" dan "Kesalahan Konfigurasi" dibandingkan dengan jenis *gejala* seperti "Pengungkapan Data Sensitif" dan "Penolakan Layanan." Kami memutuskan untuk fokus pada *akar masalah* bila memungkinkan karena lebih logis untuk memberikan panduan identifikasi dan perbaikan. Berfokus pada *akar masalah* di atas *gejala* bukanlah konsep baru; Top 10 telah menjadi campuran *gejala* dan *akar masalah*. CWE juga merupakan campuran dari *gejala* dan *akar masalah*; kami hanya menjadi lebih berhati-hati tentang hal itu dan menyebutnya. Ada rata-rata 19,6 CWE per kategori dalam pemasangan ini, dengan batas bawah pada 1 CWE untuk **A10:2021-Server-Side Request Forgery (SSRF)** hingga 40 CWE dalam **A04:2021-Insecure Design**. Struktur kategori yang diperbarui ini menawarkan manfaat pelatihan tambahan karena perusahaan dapat fokus pada CWE yang masuk akal untuk bahasa/kerangka kerja. ## Bagaimana data digunakan untuk memilih kategori -Pada tahun 2017, kami memilih kategori berdasarkan tingkat insiden untuk menentukan kemungkinan, lalu memeringkatnya berdasarkan diskusi tim berdasarkan pengalaman puluhan tahun untuk Exploitability, Detectability (juga kemungkinan), dan Dampak Teknis. Untuk tahun 2021, kami ingin menggunakan data untuk Exploitability and Impact jika memungkinkan. +Pada tahun 2017, kami memilih kategori berdasarkan tingkat insiden untuk menentukan kemungkinan, lalu memeringkatnya menurut diskusi tim berdasarkan pengalaman puluhan tahun untuk *Exploitability, Detectability* (juga *kemungkinan*), dan *Dampak Teknis*. Untuk tahun 2021, kami ingin menggunakan data untuk *Exploitability* and *Impact (Teknis)* jika memungkinkan. Kami mengunduh Pemeriksaan Ketergantungan OWASP dan mengekstrak Eksploitasi CVSS, dan skor Dampak yang dikelompokkan berdasarkan CWE terkait. Butuh sedikit riset dan usaha karena semua CVE memiliki skor CVSSv2, tetapi ada kekurangan dalam CVSSv2 yang harus diatasi oleh CVSSv3. Setelah titik waktu tertentu, semua CVE juga diberi skor CVSSv3. Selain itu, rentang penilaian dan formula diperbarui antara CVSSv2 dan CVSSv3. -Di CVSSv2, Eksploitasi dan Dampak bisa mencapai 10,0, tetapi rumusnya akan menjatuhkannya hingga 60% untuk Eksploitasi dan 40% untuk Dampak. Di CVSSv3, maks secara teori dibatasi hingga 6,0 untuk Eksploitasi dan 4,0 untuk Dampak. Dengan mempertimbangkan pembobotan, skor Dampak bergeser lebih tinggi, rata-rata hampir satu setengah poin di CVSSv3, dan kemampuan eksploitasi turun rata-rata hampir setengah poin. +Di CVSSv2, *Eksploitasi* dan *Dampak (Teknis)* bisa mencapai 10,0, tetapi rumusnya akan menjatuhkannya hingga 60% untuk *Eksploitasi* dan 40% untuk *Dampak*. Di CVSSv3, maks secara teori dibatasi hingga 6,0 untuk *Eksploitasi* dan 4,0 untuk *Dampak*. Dengan mempertimbangkan pembobotan, skor Dampak bergeser lebih tinggi, rata-rata hampir satu setengah poin di CVSSv3, dan kemampuan eksploitasi turun rata-rata hampir setengah poin. -Ada 125 ribu catatan CVE yang dipetakan ke CWE dalam data NVD yang diekstraksi dari OWASP Dependency Check, dan ada 241 CWE unik yang dipetakan ke CVE. Peta CWE 62 ribu memiliki skor CVSSv3, yang kira-kira setengah dari populasi dalam kumpulan data. +Ada 125 ribu catatan CVE yang dipetakan ke CWE dalam data NVD yang diekstraksi dari OWASP Dependency Check, dan ada 241 CWE unik yang dipetakan ke CVE. 62 ribu peta CWE memiliki skor CVSSv3, yang kira-kira setengah dari populasi dalam kumpulan data. -Untuk Top 10, kami menghitung rata-rata skor eksploitasi dan dampak dengan cara berikut. Kami mengelompokkan semua CVE dengan skor CVSS berdasarkan CWE dan memberi bobot pada skor eksploitasi dan dampak berdasarkan persentase populasi yang memiliki skor CVSSv3 + populasi yang tersisa dari skor CVSSv2 untuk mendapatkan rata-rata keseluruhan. Kami memetakan rata-rata ini ke CWE dalam kumpulan data untuk digunakan sebagai skor Eksploitasi dan Dampak untuk separuh persamaan risiko lainnya. +Untuk Top 10 2021, kami menghitung rata-rata skor *eksploitasi* dan *dampak* dengan cara berikut. Kami mengelompokkan semua CVE dengan skor CVSS berdasarkan CWE dan memberi bobot pada skor *eksploitasi* dan *dampak* berdasarkan persentase populasi yang memiliki skor CVSSv3 + populasi yang tersisa dari skor CVSSv2 untuk mendapatkan rata-rata keseluruhan. Kami memetakan rata-rata ini ke CWE dalam kumpulan data untuk digunakan sebagai skor *Eksploitasi* dan *Dampak (Teknis)* untuk separuh persamaan risiko lainnya. -## Kenapa tidak hanya bersumber dari data statistik murni? +## Kenapa tidak hanya data statistik murni? -Hasil dalam data utamanya terbatas pada apa yang dapat kami uji secara otomatis. Bicaralah dengan seorang Profesional AppSec, dan mereka akan memberi tahu Anda tentang hal-hal yang mereka temukan dan tren yang mereka lihat yang belum ada dalam data. Dibutuhkan waktu bagi orang untuk mengembangkan metodologi pengujian untuk jenis kerentanan tertentu dan kemudian lebih banyak waktu agar pengujian tersebut diotomatisasi dan dijalankan terhadap populasi aplikasi yang besar. Semua yang kami temukan adalah melihat kembali ke masa lalu dan mungkin kehilangan tren dari tahun lalu, yang tidak ada dalam data. +Hasil dalam data utamanya terbatas pada apa yang dapat kami uji secara otomatis. Bicaralah dengan seorang Profesional AppSec yang berpengalaman, dan mereka akan memberi tahu Anda tentang hal-hal yang mereka temukan dan tren yang mereka lihat yang belum ada dalam data. Dibutuhkan waktu bagi orang untuk mengembangkan metodologi pengujian untuk jenis kerentanan tertentu dan kemudian lebih banyak waktu agar pengujian tersebut diotomatisasi dan dijalankan terhadap populasi aplikasi yang besar. Semua yang kami temukan adalah melihat kembali ke masa lalu dan mungkin kehilangan tren dari tahun lalu, yang tidak ada dalam data. -Oleh karena itu, kami hanya memilih delapan dari sepuluh kategori dari data karena tidak lengkap. Dua kategori lainnya berasal dari survei industri. Hal ini memungkinkan para praktisi di garis depan untuk memilih apa yang mereka lihat sebagai risiko tertinggi yang mungkin tidak ada dalam data (dan mungkin tidak pernah diungkapkan dalam data). +Oleh karena itu, kami hanya memilih delapan dari sepuluh kategori dari data karena tidak lengkap. Dua kategori lainnya berasal dari survei komunitas Top 10. Hal ini memungkinkan para praktisi di garis depan untuk memilih apa yang mereka lihat sebagai risiko tertinggi yang mungkin tidak ada dalam data (dan mungkin tidak akan pernah diungkapkan dalam data). -## Mengapa tingkatan insiden bukan bersumber dari frekuensi? +## Mengapa tingkatan insiden, bukan frekuensi? Ada tiga sumber data utama. Kami mengidentifikasi mereka sebagai Human-assisted Tooling (HaT), Tool-assisted Human (TaH), dan raw Tooling. Tooling dan HaT adalah generator pencarian frekuensi tinggi. Alat akan mencari kerentanan tertentu dan tanpa lelah berusaha untuk menemukan setiap contoh kerentanan itu dan akan menghasilkan jumlah temuan yang tinggi untuk beberapa jenis kerentanan. Lihatlah Cross-Site Scripting, yang biasanya merupakan salah satu dari dua rasa: itu kesalahan kecil yang terisolasi atau masalah sistemik. Jika ini merupakan masalah sistemik, jumlah temuan bisa mencapai ribuan untuk sebuah aplikasi. Frekuensi tinggi ini menenggelamkan sebagian besar kerentanan lain yang ditemukan dalam laporan atau data. -TaH, di sisi lain, akan menemukan jenis kerentanan yang lebih luas tetapi pada frekuensi yang jauh lebih rendah karena kendala waktu. Ketika manusia menguji aplikasi dan melihat sesuatu seperti Cross-Site Scripting, mereka biasanya akan menemukan tiga atau empat instance dan berhenti. Mereka dapat menentukan temuan sistemik dan menuliskannya dengan rekomendasi untuk diperbaiki pada skala aplikasi yang luas. Tidak perlu (atau waktu) untuk menemukan setiap contoh. -Misalkan kita mengambil dua kumpulan data yang berbeda ini dan mencoba menggabungkannya pada frekuensi. Dalam hal ini, data Tooling dan HaT akan menenggelamkan data TaH yang lebih akurat (tetapi luas) dan merupakan bagian yang baik dari mengapa sesuatu seperti Cross-Site Scripting memiliki peringkat yang sangat tinggi di banyak daftar ketika dampaknya umumnya rendah hingga sedang. Itu karena banyaknya temuan. (Cross-Site Scripting juga cukup mudah untuk diuji, jadi ada lebih banyak tes untuk itu juga). -Pada tahun 2017, kami memperkenalkan penggunaan tingkat insiden sebagai gantinya untuk melihat data baru dan menggabungkan data Tooling dan HaT dengan data TaH dengan rapi. Tingkat insiden menanyakan berapa persentase populasi aplikasi yang memiliki setidaknya satu contoh jenis kerentanan. Kami tidak peduli apakah itu satu kali atau sistemik. Itu tidak relevan untuk tujuan kita; kita hanya perlu mengetahui berapa banyak aplikasi yang memiliki setidaknya satu instance, yang membantu memberikan pandangan yang lebih jelas tentang pengujian temuan di beberapa jenis pengujian tanpa menenggelamkan data dalam hasil frekuensi tinggi. +TaH, di sisi lain, akan menemukan jenis kerentanan yang lebih luas tetapi pada frekuensi yang jauh lebih rendah karena kendala waktu. Ketika manusia menguji aplikasi dan melihat sesuatu seperti Cross-Site Scripting, mereka biasanya akan menemukan tiga atau empat instansi dan berhenti. Mereka dapat menentukan temuan sistemik dan menuliskannya dengan rekomendasi untuk diperbaiki pada skala seluruh aplikasi. Tidak ada kebutuhan (atau waktu) untuk menemukan setiap instansi. + +Misalkan kita mengambil dua kumpulan data yang berbeda ini dan mencoba menggabungkannya pada frekuensi. Dalam hal ini, data Tooling dan HaT akan menenggelamkan data TaH yang lebih akurat (tetapi luas) dan merupakan bagian yang baik dari mengapa sesuatu seperti Cross-Site Scripting memiliki peringkat yang sangat tinggi di banyak daftar ketika dampaknya umumnya rendah hingga sedang. Itu karena demikian banyaknya temuan. (Cross-Site Scripting juga cukup mudah untuk diuji, jadi ada lebih banyak tes untuk itu juga). + +Pada tahun 2017, kami memperkenalkan penggunaan tingkat insiden sebagai gantinya untuk melihat data baru dan menggabungkan data Tooling dan HaT dengan data TaH secara bersih. Tingkat insiden menanyakan berapa persentase populasi aplikasi yang memiliki setidaknya satu instansi jenis kerentanan. Kami tidak peduli apakah itu satu kali atau sistemik. Itu tidak relevan untuk tujuan kita; kita hanya perlu mengetahui berapa banyak aplikasi yang memiliki setidaknya satu instansi, yang membantu memberikan pandangan yang lebih jelas tentang pengujian temuan di beberapa jenis pengujian tanpa menenggelamkan data dalam hasil frekuensi tinggi. Ini sesuai dengan pandangan terkait risiko karena penyerang hanya membutuhkan satu instansi untuk menyerang aplikasi dengan sukses melalui kategori. ## Apa proses pengumpulan dan analisis data Anda? -Kami meresmikan proses pengumpulan data OWASP Top 10 di Open Security Summit pada 2017. Para Leader OWASP Top 10 dan komunitas telah menghabiskan dua hari untuk memformalkan proses pengumpulan data yang transparan. Edisi 2021 adalah kedua kalinya kami menggunakan metodologi ini. +Kami meresmikan proses pengumpulan data OWASP Top 10 di Open Security Summit pada 2017. Para leader OWASP Top 10 dan komunitas telah menghabiskan dua hari untuk memformalkan proses pengumpulan data yang transparan. Edisi 2021 adalah kedua kalinya kami menggunakan metodologi ini. + Kami mempublikasikan panggilan untuk data melalui saluran media sosial yang tersedia untuk kami, baik projek maupun OWASP. Pada halaman Projek OWASP, kami mencantumkan elemen dan struktur data yang kami cari dan cara mengirimkannya. Dalam proyek GitHub, kami memiliki file contoh yang berfungsi sebagai template. Kami bekerja dengan organisasi yang diperlukan untuk membantu mengetahui struktur dan pemetaan ke CWE. -Kami mendapatkan data dari organisasi yang menguji vendor berdasarkan perdagangan, vendor bug bounty, dan organisasi yang menyumbangkan data pengujian internal. Setelah kami memiliki data, kami memuatnya bersama dan menjalankan analisis fundamental tentang apa yang dipetakan CWE ke kategori risiko. Ada tumpang tindih antara beberapa CWE, dan yang lainnya sangat erat kaitannya (mis. Kerentanan kriptografis). Setiap keputusan yang terkait dengan data mentah yang dikirimkan didokumentasikan dan dipublikasikan agar terbuka dan transparan dengan cara kami menormalkan data. -Kami melihat delapan kategori dengan tingkat insiden tertinggi untuk dimasukkan dalam Top 10. Kami juga melihat hasil survei industri untuk melihat mana yang mungkin sudah ada dalam data. Dua suara teratas yang belum ada dalam data akan dipilih untuk dua tempat lainnya di Top 10. Setelah kesepuluh dipilih, kami menerapkan faktor umum untuk eksploitabilitas dan dampak; untuk membantu menentukan peringkat 10 Besar secara berurutan. +Kami mendapatkan data dari organisasi vendor pengujian, vendor bug bounty, dan organisasi yang menyumbangkan data pengujian internal. Setelah kami memiliki data, kami memuatnya bersama dan menjalankan analisis fundamental tentang apa yang dipetakan CWE ke kategori risiko. Ada tumpang tindih antara beberapa CWE, dan yang lainnya sangat erat kaitannya (mis. Kerentanan kriptografis). Setiap keputusan yang terkait dengan data mentah yang dikirimkan didokumentasikan dan dipublikasikan agar terbuka dan transparan dengan cara kami menormalkan data. + +Kami melihat delapan kategori dengan tingkat insiden tertinggi untuk dimasukkan dalam Top 10. Kami juga melihat hasil survei komunitas Top 10 untuk melihat mana yang mungkin sudah ada dalam data. Dua suara teratas yang belum ada dalam data akan dipilih untuk dua tempat lainnya di Top 10. Setelah sepuluh dipilih, kami menerapkan faktor umum untuk eksploitabilitas dan dampak; untuk membantu menentukan peringkat Top 10 2021 dalam urutan berbasis risiko. ## Faktor-faktor Data Ada data faktor yang dicantumkan untuk masing-masing dari 10 Kategori Teratas, berikut artinya: -- CWEs Mapped: Jumlah CWE yang dipetakan ke kategori oleh 10 tim teratas. -- Incidence Rate: Tingkat insiden adalah persentase aplikasi yang rentan terhadap CWE tersebut dari populasi yang diuji oleh organisasi tersebut untuk tahun tersebut. -- (Pengujian) Cakupan: Persentase aplikasi yang diuji oleh semua organisasi untuk CWE tertentu. -- Weighted Exploit: Sub-skor Eksploitasi dari skor CVSSv2 dan CVSSv3 yang ditetapkan ke CVE yang dipetakan ke CWE, dinormalisasi, dan ditempatkan pada skala 10pt. -- Weighted Impact: Sub-skor Dampak dari skor CVSSv2 dan CVSSv3 yang ditetapkan ke CVE dipetakan ke CWE, dinormalisasi, dan ditempatkan pada skala 10pt. +- CWE Dipetakan: Jumlah CWE yang dipetakan ke kategori oleh tim Top 10. +- Laju Insidensi: Tingkat insiden adalah persentase aplikasi yang rentan terhadap CWE tersebut dari populasi yang diuji oleh organisasi tersebut untuk tahun tersebut. +- Cakupan (Pengujian): Persentase aplikasi yang diuji oleh semua organisasi untuk CWE tertentu. +- Ekslpoitasi Terbobot: Sub-skor Eksploitasi dari skor CVSSv2 dan CVSSv3 yang ditetapkan ke CVE yang dipetakan ke CWE, dinormalisasi, dan ditempatkan pada skala 10. +- Dampak Terbobot: Sub-skor Dampak dari skor CVSSv2 dan CVSSv3 yang ditetapkan ke CVE dipetakan ke CWE, dinormalisasi, dan ditempatkan pada skala 10. - Total Kejadian: Jumlah total aplikasi yang ditemukan memiliki CWE yang dipetakan ke suatu kategori. - Total CVE: Jumlah total CVE dalam NVD DB yang dipetakan ke CWE yang dipetakan ke suatu kategori. -### Hubungan Kategori dari 2017 - -Ada banyak pembicaraan tentang tumpang tindih antara risiko Top 10. Menurut definisi masing-masing (daftar CWE yang termasuk), sebenarnya tidak ada tumpang tindih. Namun, secara konseptual, dapat terjadi tumpang tindih atau interaksi berdasarkan penamaan tingkat yang lebih tinggi. Diagram Venn berkali-kali digunakan untuk menunjukkan tumpang tindih seperti ini. - -Diagram Venn di atas merepresentasikan interaksi antara Sepuluh Kategori Risiko Teratas 2017. Saat melakukannya, beberapa poin penting menjadi jelas: - -1. Orang bisa berargumen bahwa Cross-Site Scripting pada akhirnya termasuk dalam Injeksi karena pada dasarnya adalah Injeksi Konten. Melihat data tahun 2021, semakin jelas bahwa XSS perlu pindah ke Injeksi. -2. Tumpang tindih hanya satu arah. Kita akan sering mengklasifikasikan kerentanan berdasarkan manifestasi akhir atau "gejala", bukan akar penyebab (yang berpotensi dalam). Misalnya, "Pengungkapan Data Sensitif" mungkin merupakan hasil dari "Kesalahan Konfigurasi Keamanan"; namun, Anda tidak akan melihatnya ke arah lain. Akibatnya, panah digambar di zona interaksi untuk menunjukkan arah mana itu terjadi. -3. Terkadang diagram ini digambar dengan semua yang ada di A06:2021 Menggunakan Komponen dengan Kerentanan yang Diketahui. Sementara beberapa kategori risiko ini mungkin menjadi akar penyebab kerentanan pihak ketiga, mereka umumnya dikelola secara berbeda dan dengan tanggung jawab yang berbeda. Jenis lainnya biasanya mewakili risiko pihak pertama. - -### Terima kasih kepada kontributor data kami +## Terima kasih kepada kontributor data kami Organisasi berikut (bersama dengan beberapa donor anonim) dengan baik hati menyumbangkan data untuk lebih dari 500.000 aplikasi untuk menjadikan ini kumpulan data keamanan aplikasi terbesar dan terlengkap. Tanpa Anda, ini tidak akan mungkin. @@ -114,8 +108,10 @@ Organisasi berikut (bersama dengan beberapa donor anonim) dengan baik hati menyu - Veracode - WhiteHat (NTT) -## Thank you to our sponsor +## Terima kasih kepada sponsor kami + +Tim OWASP Top 10 2021 berterimakasih atas dukungan finansial dari Secure Code Warrior dan Just Eat. -The OWASP Top 10 2021 team gratefully acknowledge the financial support of Secure Code Warrior. +[![Secure Code Warrior](assets/securecodewarrior.png){ width="256" }](https://securecodewarrior.com) -[![Secure Code Warrior](assets/securecodewarrior.png)](https://securecodewarrior.com) +[![Just Eat](assets/JustEat.png){ width="256" }](https://www.just-eat.co.uk) diff --git a/2021/mkdocs.yml b/2021/mkdocs.yml index 143e937b7..9005c8572 100644 --- a/2021/mkdocs.yml +++ b/2021/mkdocs.yml @@ -115,15 +115,15 @@ plugins: How to start an AppSec program with the OWASP Top 10: Bagaimana cara untuk memulai program AppSec dengan OWASP Top 10 About OWASP: Tentang OWASP Top 10:2021 List: Daftar Top 10:2021 - A01 Broken Access Control: A01 Kerusakan Akses Kontrol + A01 Broken Access Control: A01 Kontrol Akses yang Rusak A02 Cryptographic Failures: A02 Kegagalan Kriptografi A03 Injection: A03 Injeksi - A04 Insecure Design: A04 Insecure Design + A04 Insecure Design: A04 Rancangan Tak Aman A05 Security Misconfiguration: A05 Kesalahan Konfigurasi Keamanan A06 Vulnerable and Outdated Components: A06 Komponen yang Rentan dan Kedaluwarsa A07 Identification and Authentication Failures: A07 Kegagalan Identifikasi dan Otentikasi A08 Software and Data Integrity Failures: A08 Kegagalan Integritas Data dan Perangkat Lunak - A09 Security Logging and Monitoring Failures: A09 Kegagalan dalam Keamanan Logging dan Monitoring + A09 Security Logging and Monitoring Failures: A09 Kegagalan Pemantauan dan Pencatatan Log Keamanan A10 Server Side Request Forgery (SSRF): A10 Server-Side Request Forgery (SSRF) Next Steps: Langkah Selanjutnya it: