OWASP Top 10 yang baru membantu menjaga Keamanan Aplikasi Web Anda.

Apa itu OWASP?

Itu Buka Proyek Keamanan Aplikasi Web, atau OWASP, adalah organisasi nirlaba internasional yang didedikasikan untuk keamanan aplikasi web. Salah satu prinsip inti OWASP adalah bahwa semua materi mereka tersedia secara bebas dan mudah diakses di situs web mereka, sehingga memungkinkan siapa saja untuk meningkatkan keamanan aplikasi web mereka sendiri. Materi yang mereka tawarkan meliputi dokumentasi, alat, video, dan forum. Mungkin proyek mereka yang paling terkenal adalah OWASP Top 10.

Apa itu 10 Teratas OWASP?

OWASP Top 10 adalah laporan yang diperbarui secara berkala yang menguraikan masalah keamanan untuk keamanan aplikasi web, dengan fokus pada 10 risiko paling kritis. Laporan ini disusun oleh tim ahli keamanan dari seluruh dunia. OWASP mengacu pada Top 10 sebagai 'dokumen kesadaran' dan mereka merekomendasikan agar semua perusahaan memasukkan laporan ke dalam proses mereka untuk meminimalkan dan/atau mengurangi risiko keamanan.

10 Teratas OWASP -2021

Berikut adalah risiko keamanan yang dilaporkan dalam laporan OWASP Top 10 2021:

1. Kontrol Akses Rusak

Kontrol akses memberlakukan kebijakan sehingga pengguna tidak dapat bertindak di luar izin yang dimaksudkan. Kegagalan biasanya menyebabkan pengungkapan informasi yang tidak sah, modifikasi, atau penghancuran semua data atau melakukan fungsi bisnis di luar batas pengguna. Kerentanan kontrol akses umum meliputi:

  • Pelanggaran prinsip hak istimewa paling rendah atau penolakan secara default, di mana akses hanya boleh diberikan untuk kemampuan, peran, atau pengguna tertentu, tetapi tersedia untuk siapa saja.
  • Mengabaikan pemeriksaan kontrol akses dengan memodifikasi URL (pengubahan parameter atau penjelajahan paksa), status aplikasi internal, atau halaman HTML, atau dengan menggunakan alat serangan untuk mengubah permintaan API.
  • Mengizinkan melihat atau mengedit akun orang lain, dengan memberikan pengenal uniknya (referensi objek langsung yang tidak aman)
  • Mengakses API dengan kontrol akses yang hilang untuk POST, PUT, dan DELETE.
  • Ketinggian hak istimewa. Bertindak sebagai pengguna tanpa login atau bertindak sebagai admin saat login sebagai pengguna.
  • Manipulasi metadata, seperti memutar ulang atau merusak token kontrol akses JSON Web Token (JWT), atau cookie atau bidang tersembunyi yang dimanipulasi untuk meningkatkan hak istimewa atau menyalahgunakan pembatalan JWT.
  • Kesalahan konfigurasi CORS memungkinkan akses API dari sumber yang tidak sah/tidak dipercaya.
  • Memaksa penjelajahan ke halaman yang diautentikasi sebagai pengguna yang tidak diautentikasi atau ke halaman yang diistimewakan sebagai pengguna standar.

2. Kegagalan Kriptografi

Hal pertama yang harus dilakukan adalah menentukan kebutuhan proteksi data in transit dan at rest. Misalnya, kata sandi, nomor kartu kredit, catatan kesehatan, informasi pribadi, dan rahasia bisnis memerlukan perlindungan ekstra, terutama jika data tersebut termasuk dalam undang-undang privasi, misalnya, Peraturan Perlindungan Data Umum (GDPR) UE, atau peraturan, misalnya, perlindungan data keuangan seperti Standar Keamanan Data PCI (PCI DSS). Untuk semua data tersebut:

  • Apakah ada data yang dikirimkan dalam bentuk teks yang jelas? Ini menyangkut protokol seperti HTTP, SMTP, dan FTP juga menggunakan peningkatan TLS seperti STARTTLS. Lalu lintas internet eksternal berbahaya. Verifikasi semua lalu lintas internal, misalnya, antara penyeimbang beban, server web, atau sistem back-end.
  • Apakah ada algoritma atau protokol kriptografi lama atau lemah yang digunakan baik secara default atau dalam kode yang lebih lama?
  • Apakah kunci kripto default sedang digunakan, kunci kripto yang lemah dihasilkan atau digunakan kembali, atau apakah manajemen atau rotasi kunci yang tepat hilang? Apakah kunci kripto diperiksa ke dalam repositori kode sumber?
  • Apakah enkripsi tidak diterapkan, misalnya, apakah ada arahan keamanan (browser) header HTTP atau header yang hilang?
  • Apakah sertifikat server yang diterima dan rantai kepercayaan divalidasi dengan benar?
  • Apakah vektor inisialisasi diabaikan, digunakan kembali, atau tidak dibuat cukup aman untuk mode operasi kriptografi? Apakah mode operasi tidak aman seperti ECB sedang digunakan? Apakah enkripsi digunakan ketika enkripsi yang diautentikasi lebih tepat?
  • Apakah kata sandi digunakan sebagai kunci kriptografi tanpa adanya fungsi derivasi kunci berbasis kata sandi?
  • Apakah keacakan digunakan untuk tujuan kriptografi yang tidak dirancang untuk memenuhi persyaratan kriptografi? Bahkan jika fungsi yang benar dipilih, apakah itu perlu diunggulkan oleh pengembang, dan jika tidak, apakah pengembang telah menulis ulang fungsi penyemaian yang kuat yang dibangun di dalamnya dengan benih yang tidak memiliki entropi/ketidakpastian yang cukup?
  • Apakah fungsi hash yang tidak digunakan lagi seperti MD5 atau SHA1 sedang digunakan, atau apakah fungsi hash non-kriptografi digunakan saat fungsi hash kriptografis diperlukan?
  • Apakah metode padding kriptografi yang tidak digunakan lagi seperti PKCS nomor 1 v1.5 sedang digunakan?
  • Apakah pesan kesalahan kriptografi atau informasi saluran samping dapat dieksploitasi, misalnya dalam bentuk serangan oracle padding?

3. Injeksi

Sebuah aplikasi rentan terhadap serangan ketika:

  • Data yang disediakan pengguna tidak divalidasi, difilter, atau disanitasi oleh aplikasi.
  • Kueri dinamis atau panggilan non-parameter tanpa pelolosan kontekstual digunakan langsung di penerjemah.
  • Data bermusuhan digunakan dalam parameter pencarian pemetaan relasional objek (ORM) untuk mengekstrak catatan sensitif tambahan.
  • Data bermusuhan langsung digunakan atau digabungkan. SQL atau perintah berisi struktur dan data berbahaya dalam kueri dinamis, perintah, atau prosedur tersimpan.

Beberapa injeksi yang lebih umum adalah injeksi SQL, NoSQL, OS command, Object Relational Mapping (ORM), LDAP, dan Expression Language (EL) atau Object Graph Navigation Library (OGNL). Konsepnya identik di antara semua penafsir. Tinjauan kode sumber adalah metode terbaik untuk mendeteksi apakah aplikasi rentan terhadap injeksi. Pengujian otomatis dari semua parameter, header, URL, cookie, JSON, SOAP, dan input data XML sangat dianjurkan. Organisasi dapat menyertakan alat pengujian keamanan aplikasi statis (SAST), dinamis (DAST), dan interaktif (IAST) ke dalam pipa CI/CD untuk mengidentifikasi kelemahan injeksi yang diperkenalkan sebelum penyebaran produksi.

4. Desain Tidak Aman

Desain tidak aman adalah kategori luas yang mewakili berbagai kelemahan, yang dinyatakan sebagai “desain kontrol yang hilang atau tidak efektif”. Desain yang tidak aman bukanlah sumber untuk semua 10 kategori risiko Teratas lainnya. Ada perbedaan antara desain yang tidak aman dan implementasi yang tidak aman. Kami membedakan antara cacat desain dan cacat implementasi karena suatu alasan, mereka memiliki akar penyebab dan perbaikan yang berbeda. Desain yang aman masih dapat memiliki cacat implementasi yang mengarah ke kerentanan yang dapat dieksploitasi. Desain yang tidak aman tidak dapat diperbaiki dengan implementasi yang sempurna karena menurut definisi, kontrol keamanan yang diperlukan tidak pernah dibuat untuk bertahan dari serangan tertentu. Salah satu faktor yang berkontribusi pada desain yang tidak aman adalah kurangnya profil risiko bisnis yang melekat pada perangkat lunak atau sistem yang sedang dikembangkan, dan dengan demikian kegagalan untuk menentukan tingkat desain keamanan apa yang diperlukan.

Persyaratan dan Manajemen Sumber Daya

Kumpulkan dan negosiasikan persyaratan bisnis untuk aplikasi dengan bisnis, termasuk persyaratan perlindungan mengenai kerahasiaan, integritas, ketersediaan, dan keaslian semua aset data dan logika bisnis yang diharapkan. Memperhitungkan seberapa terbuka aplikasi Anda dan jika Anda memerlukan pemisahan penyewa (selain untuk kontrol akses). Menyusun persyaratan teknis, termasuk persyaratan keamanan fungsional dan non-fungsional. Merencanakan dan menegosiasikan anggaran yang mencakup semua desain, pembuatan, pengujian, dan pengoperasian, termasuk aktivitas keamanan.

Desain Aman

Desain aman adalah budaya dan metodologi yang terus-menerus mengevaluasi ancaman dan memastikan bahwa kode dirancang dan diuji dengan kuat untuk mencegah metode serangan yang diketahui. Pemodelan ancaman harus diintegrasikan ke dalam sesi perbaikan (atau kegiatan serupa); mencari perubahan aliran data dan kontrol akses atau kontrol keamanan lainnya. Dalam pengembangan cerita pengguna, tentukan aliran dan status kegagalan yang benar, dan pastikan mereka dipahami dengan baik dan disetujui oleh pihak yang bertanggung jawab dan terkena dampak. Analisis asumsi dan kondisi untuk aliran yang diharapkan dan aliran kegagalan, dan pastikan asumsi dan kondisi tersebut masih akurat dan diinginkan. Tentukan bagaimana memvalidasi asumsi dan menegakkan kondisi yang diperlukan untuk perilaku yang tepat. Pastikan hasilnya didokumentasikan dalam cerita pengguna. Belajar dari kesalahan dan tawarkan insentif positif untuk mendorong perbaikan. Desain yang aman bukanlah add-on atau alat yang dapat Anda tambahkan ke perangkat lunak.

Siklus Hidup Pengembangan yang Aman

Perangkat lunak yang aman memerlukan siklus hidup pengembangan yang aman, beberapa bentuk pola desain yang aman, metodologi jalan beraspal, pustaka komponen yang aman, perkakas, dan pemodelan ancaman. Hubungi spesialis keamanan Anda di awal proyek perangkat lunak di seluruh proyek dan pemeliharaan perangkat lunak Anda. Pertimbangkan untuk memanfaatkan Model Kematangan Jaminan Perangkat Lunak (SAMM) OWASP untuk membantu menyusun upaya pengembangan perangkat lunak Anda yang aman.

5. Kesalahan Konfigurasi Keamanan

Aplikasi mungkin rentan jika aplikasi tersebut:

  • Pengerasan keamanan yang sesuai tidak ada di bagian mana pun dari tumpukan aplikasi atau izin yang tidak dikonfigurasi dengan benar pada layanan cloud.
  • Fitur yang tidak perlu diaktifkan atau diinstal (misalnya, port, layanan, halaman, akun, atau hak istimewa yang tidak perlu).
  • Akun default dan kata sandinya masih diaktifkan dan tidak berubah.
  • Penanganan kesalahan mengungkapkan jejak tumpukan atau pesan kesalahan lain yang terlalu informatif kepada pengguna.
  • Untuk sistem yang ditingkatkan, fitur keamanan terbaru dinonaktifkan atau tidak dikonfigurasi dengan aman.
  • Pengaturan keamanan di server aplikasi, kerangka kerja aplikasi (misalnya, Struts, Spring, ASP.NET), perpustakaan, database, dll., tidak disetel ke nilai aman.
  • Server tidak mengirim header atau arahan keamanan, atau tidak disetel ke nilai aman.
  • Perangkat lunak sudah kedaluwarsa atau rentan.

Tanpa proses konfigurasi keamanan aplikasi yang berulang dan terpadu, sistem berada pada risiko yang lebih tinggi.

6. Komponen Rentan dan Kedaluwarsa

Anda mungkin rentan:

  • Jika Anda tidak mengetahui versi semua komponen yang Anda gunakan (baik sisi klien maupun sisi server). Ini termasuk komponen yang Anda gunakan secara langsung serta dependensi bersarang.
  • Jika perangkat lunak rentan, tidak didukung, atau kedaluwarsa. Ini termasuk OS, server web/aplikasi, sistem manajemen basis data (DBMS), aplikasi, API dan semua komponen, lingkungan runtime, dan perpustakaan.
  • 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 patching adalah tugas bulanan atau triwulanan di bawah kendali perubahan, membuat organisasi terbuka untuk berhari-hari atau berbulan-bulan terpapar kerentanan tetap yang tidak perlu.
  • Jika pengembang perangkat lunak tidak menguji kompatibilitas pustaka yang diperbarui, ditingkatkan, atau ditambal.
  • Jika Anda tidak mengamankan konfigurasi komponen.

7. Kegagalan Identifikasi dan Otentikasi

Konfirmasi identitas pengguna, otentikasi, dan manajemen sesi sangat penting untuk melindungi dari serangan terkait otentikasi. Mungkin ada kelemahan otentikasi jika aplikasi:

  • Mengizinkan serangan otomatis seperti isian kredensial, di mana penyerang memiliki daftar nama pengguna dan kata sandi yang valid.
  • Mengizinkan kekerasan atau serangan otomatis lainnya.
  • Mengizinkan kata sandi default, lemah, atau terkenal, seperti "Kata Sandi1" 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 penyimpanan data kata sandi teks biasa, terenkripsi, atau hash lemah.
  • Memiliki otentikasi multi-faktor yang hilang atau tidak efektif.
  • Mengekspos pengenal sesi di URL.
  • Gunakan kembali pengenal 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.

8. Kegagalan Integritas Perangkat Lunak dan Data

Kegagalan integritas perangkat lunak dan data berhubungan dengan kode dan infrastruktur yang tidak melindungi dari pelanggaran integritas. Contohnya adalah saat aplikasi bergantung pada plugin, pustaka, atau modul dari sumber, repositori, dan jaringan pengiriman konten (CDN) yang tidak tepercaya. Pipeline CI/CD yang tidak aman dapat menimbulkan potensi akses tidak sah, kode berbahaya, atau kompromi sistem. Terakhir, banyak aplikasi sekarang menyertakan fungsionalitas pembaruan otomatis, di mana pembaruan diunduh tanpa verifikasi integritas yang memadai dan diterapkan ke aplikasi tepercaya sebelumnya. Penyerang berpotensi mengunggah pembaruan mereka sendiri untuk didistribusikan dan dijalankan di semua instalasi. Contoh lain adalah di mana objek atau data dikodekan atau diserialkan ke dalam struktur yang dapat dilihat dan dimodifikasi oleh penyerang, rentan terhadap deserialisasi yang tidak aman.

9. Kegagalan Pencatatan dan Pemantauan Keamanan

Kegagalan Pencatatan dan Pemantauan Keamanan adalah untuk membantu mendeteksi, mengeskalasi, dan menanggapi pelanggaran aktif. Tanpa pencatatan dan pemantauan, pelanggaran tidak dapat dideteksi. Pencatatan, deteksi, pemantauan, dan respons aktif yang tidak memadai terjadi kapan saja:

  • Peristiwa yang dapat diaudit, seperti login, login yang gagal, dan transaksi bernilai tinggi, tidak dicatat.
  • Peringatan dan kesalahan tidak menghasilkan pesan log yang tidak, tidak memadai, atau tidak jelas.
  • Log aplikasi dan API tidak dipantau untuk aktivitas yang mencurigakan.
  • Log hanya disimpan secara lokal.
  • Ambang batas peringatan yang tepat dan proses eskalasi respons tidak ada atau tidak efektif.
  • Pengujian penetrasi dan pemindaian oleh alat pengujian keamanan aplikasi dinamis (DAST) (seperti OWASP ZAP) tidak memicu peringatan.
  • Aplikasi tidak dapat mendeteksi, meningkatkan, atau memperingatkan serangan aktif secara real-time atau mendekati real-time.

Anda rentan terhadap kebocoran informasi dengan membuat peristiwa pencatatan dan peringatan terlihat oleh pengguna atau penyerang

10. Pemalsuan Permintaan Sisi Server (SSRF)

Cacat SSRF terjadi setiap kali aplikasi web mengambil sumber daya jarak jauh tanpa memvalidasi URL yang disediakan pengguna. Ini memungkinkan penyerang untuk memaksa aplikasi untuk mengirim permintaan yang dibuat ke tujuan yang tidak terduga, bahkan ketika dilindungi oleh firewall, VPN, atau jenis lain dari daftar kontrol akses jaringan (ACL).

Karena aplikasi web modern menyediakan fitur yang nyaman bagi pengguna akhir, mengambil URL menjadi skenario umum. Akibatnya, kejadian SSRF meningkat. Juga, tingkat keparahan SSRF menjadi lebih tinggi karena layanan cloud dan kompleksitas arsitektur.

Jika Anda ingin mempelajari lebih lanjut tentang keamanan web, silakan periksa situs web OWASP.

Pos terkait

Tinggalkan Balasan

Alamat email Anda tidak akan dipublikasikan.

Buletin

Berlangganan buletin kami dan dapatkan info terbaru tentang penawaran dan penawaran kami!

Kami berkomitmen untuk melindungi privasi Anda

Posting Populer