10 Kerentanan Keamanan Web Paling Umum

OWASP atau Open Web Security Project adalah organisasi amal nirlaba yang berfokus pada peningkatan keamanan perangkat lunak dan aplikasi web.

Organisasi tersebut menerbitkan daftar kerentanan keamanan web teratas berdasarkan data dari berbagai organisasi keamanan.

Kerentanan keamanan web diprioritaskan tergantung pada kemampuan eksploitasi, kemampuan deteksi, dan dampaknya terhadap perangkat lunak.

  • Eksploitasi –Apa yang diperlukan untuk mengeksploitasi kerentanan keamanan? Eksploitasi tertinggi ketika serangan hanya memerlukan browser web dan terendah adalah pemrograman dan alat canggih.
  • Deteksi – Seberapa mudahkah untuk mendeteksi ancaman? Yang paling mudah adalah informasi yang ditampilkan pada URL, Formulir atau Pesan Kesalahan dan yang paling mudah adalah kode sumber.
  • Dampak atau Kerusakan –Berapa banyak kerusakan yang akan terjadi jika kerentanan keamanan terekspos atau diserang? Yang tertinggi adalah kerusakan sistem yang lengkap dan yang terendah adalah tidak ada sama sekali.

Tujuan utama OWASP Top 10 adalah untuk mendidik para pengembang, desainer, manajer, arsitek dan organisasi tentang kerentanan keamanan yang paling penting.

10 Kerentanan Keamanan Teratas menurut OWASP Top 10 adalah:

SQL Injection

SQL Injection

Description

Injeksi adalah kerentanan keamanan yang memungkinkan penyerang mengubah backend SQL pernyataan dengan memanipulasi data yang disediakan pengguna.

Injeksi terjadi ketika input pengguna dikirim ke juru bahasa sebagai bagian dari perintah atau kueri dan mengelabui juru bahasa agar menjalankan perintah yang tidak diinginkan dan memberikan akses ke data yang tidak sah.

Perintah SQL yang bila dijalankan oleh aplikasi web juga dapat mengekspos database back-end.

Implikasi

  • Penyerang dapat memasukkan konten berbahaya ke dalam bidang yang rentan.
  • Data sensitif seperti Nama Pengguna, Kata Sandi, dll. dapat dibaca dari database.
  • Data database dapat diubah (Sisipkan/Perbarui/Hapus).
  • Administrasi Operations dapat dieksekusi pada database

Objek Rentan

  • Bidang Masukan
  • URL berinteraksi dengan database.

contoh:

Masuk ke aplikasi tanpa memiliki kredensial yang valid.

Nama pengguna yang valid tersedia, dan kata sandi tidak tersedia.

URL pengujian: http://demo.testfire.net/default.aspx

Nama Pengguna: sjones

Kata sandi: 1=1′ atau pass123

Kueri SQL dibuat dan dikirim ke Interpreter seperti di bawah ini

PILIH * DARI Pengguna DIMANA Nama_Pengguna = sjones DAN Kata Sandi = 1=1′ atau pass123;

Rekomendasi

  1. Daftar putih bidang input
  2. Hindari menampilkan pesan kesalahan mendetail yang berguna bagi penyerang.

Skrip Lintas Situs

Description

Cross Site Scripting juga dikenal sebagai XSS.

Kerentanan XSS menargetkan skrip yang tertanam di halaman yang dieksekusi di sisi klien yaitu browser pengguna, bukan di sisi server. Kelemahan ini dapat terjadi ketika aplikasi mengambil data yang tidak dipercaya dan mengirimkannya ke browser web tanpa validasi yang tepat.

Penyerang dapat menggunakan XSS untuk mengeksekusi skrip berbahaya pada pengguna dalam hal ini browser korban. Karena browser tidak dapat mengetahui apakah skrip tersebut dapat dipercaya atau tidak, skrip tersebut akan dieksekusi, dan penyerang dapat membajak cookie sesi, merusak situs web, atau mengarahkan pengguna ke situs web yang tidak diinginkan dan berbahaya.

XSS adalah serangan yang memungkinkan penyerang mengeksekusi skrip pada browser korban.

Implikasi:

  • Memanfaatkan kerentanan keamanan ini, penyerang dapat memasukkan skrip ke dalam aplikasi, mencuri cookie sesi, merusak situs web, dan dapat menjalankan malware di mesin korban.

Objek Rentan

  • Bidang Masukan
  • URL

contoh

1. http://www.vulnerablesite.com/home?”<script>alert(“xss”)</script>

Skrip di atas ketika dijalankan di browser, kotak pesan akan ditampilkan jika situs tersebut rentan terhadap XSS.

Serangan yang lebih serius dapat dilakukan jika penyerang ingin menampilkan atau menyimpan session cookie.

2. http://demo.testfire.net/search.aspx?txtSearch <iframe> http://google.com lebar = 500 tinggi 500>

Script di atas ketika dijalankan, browser akan memuat frame tak kasat mata yang mengarah ke http://google.com.

Serangan ini dapat menjadi serius dengan menjalankan skrip berbahaya di browser.

Rekomendasi

  1. Bidang masukan Daftar Putih
  2. Pengodean masukan keluaran

Otentikasi Rusak dan Manajemen Sesi

Description

Situs web biasanya membuat cookie sesi dan ID sesi untuk setiap sesi yang valid, dan cookie ini berisi data sensitif seperti nama pengguna, kata sandi, dll. Ketika sesi diakhiri baik dengan logout atau browser ditutup secara tiba-tiba, cookie ini harus dibatalkan yaitu untuk setiap sesi harusnya ada kue baru.

Jika cookie tidak dibatalkan, data sensitif akan ada di sistem. Misalnya, pengguna yang menggunakan komputer umum (Cyber ​​Cafe), cookie dari situs yang rentan berada di sistem dan diekspos ke penyerang. Seorang penyerang menggunakan komputer publik yang sama setelah beberapa waktu, data sensitif disusupi.

Dengan cara yang sama, pengguna yang menggunakan komputer umum, alih-alih logout, ia malah menutup browser secara tiba-tiba. Seorang penyerang menggunakan sistem yang sama, ketika menjelajahi situs rentan yang sama, sesi korban sebelumnya akan dibuka. Penyerang dapat melakukan apa pun yang dia ingin lakukan mulai dari mencuri informasi profil, informasi kartu kredit, dll.

Pemeriksaan harus dilakukan untuk menemukan kekuatan otentikasi dan manajemen sesi. Kunci, token sesi, cookie harus diterapkan dengan benar tanpa mengorbankan kata sandi.

Objek Rentan

  • ID sesi yang terekspos pada URL dapat menyebabkan serangan fiksasi sesi.
  • ID Sesi sama sebelum dan sesudah logout dan login.
  • Batas Waktu Sesi tidak diterapkan dengan benar.
  • Aplikasi menetapkan ID sesi yang sama untuk setiap sesi baru.
  • Bagian aplikasi yang diautentikasi dilindungi menggunakan SSL dan kata sandi disimpan dalam format hash atau terenkripsi.
  • Sesi ini dapat digunakan kembali oleh pengguna dengan hak istimewa rendah.

Implikasi

  • Memanfaatkan kerentanan ini, penyerang dapat membajak sesi, mendapatkan akses tidak sah ke sistem yang memungkinkan pengungkapan dan modifikasi informasi tidak sah.
  • Sesi dapat di-jack tinggi menggunakan cookie yang dicuri atau sesi menggunakan XSS.

contoh

  1. Aplikasi reservasi maskapai penerbangan mendukung penulisan ulang URL, memasukkan ID sesi di URL:http://Examples.com/sale/saleitems;jsessionid=2P0OC2oJM0DPXSNQPLME34SERTBG/dest=Maldives (Penjualan tiket ke Maladewa)Pengguna situs yang terautentikasi ingin memberi tahu teman-temannya tentang penjualan tersebut dan mengirimkan email. Teman-teman tersebut menerima ID sesi dan dapat digunakan untuk melakukan modifikasi yang tidak sah atau menyalahgunakan detail kartu kredit yang tersimpan.
  2. Sebuah aplikasi rentan terhadap XSS, dimana penyerang dapat mengakses ID sesi dan dapat digunakan untuk membajak sesi tersebut.
  3. Batas waktu aplikasi tidak diatur dengan benar. Pengguna menggunakan komputer umum dan menutup browser alih-alih keluar dan pergi. Penyerang menggunakan browser yang sama beberapa saat kemudian, dan sesi tersebut diautentikasi.

Rekomendasi

  1. Semua persyaratan autentikasi dan manajemen sesi harus ditetapkan sesuai Standar Verifikasi Keamanan Aplikasi OWASP.
  2. Jangan pernah mengekspos kredensial apa pun di URL atau Log.
  3. Upaya keras juga harus dilakukan untuk menghindari kelemahan XSS yang dapat digunakan untuk mencuri ID sesi.

Referensi Objek Langsung Tidak Aman

Description

Hal ini terjadi ketika pengembang memaparkan referensi ke objek implementasi internal, seperti file, direktori, atau kunci database seperti di URL atau sebagai parameter FORM. Penyerang dapat menggunakan informasi ini untuk mengakses objek lain dan dapat membuat serangan di masa depan untuk mengakses data yang tidak sah.

Implikasi

  • Dengan menggunakan kerentanan ini, penyerang dapat memperoleh akses ke objek internal yang tidak sah, dapat mengubah data, atau menyusupi aplikasi.

Objek Rentan

  • Di URL.

contoh:

Mengubah “userid” di URL berikut dapat menyebabkan penyerang melihat informasi pengguna lain.

http://www.vulnerablesite.com/userid=123 Dimodifikasi menjadi http://www.vulnerablesite.com/userid=124

Seorang penyerang dapat melihat informasi orang lain dengan mengubah nilai id pengguna.

Rekomendasi:

  1. Menerapkan pemeriksaan kontrol akses.
  2. Hindari mengekspos referensi objek di URL.
  3. Verifikasi otorisasi ke semua objek referensi.

Pemalsuan Permintaan Lintas Situs

Description

Pemalsuan Permintaan Lintas Situs adalah permintaan palsu yang berasal dari lintas situs.

Serangan CSRF adalah serangan yang terjadi ketika situs web, email, atau program berbahaya menyebabkan browser pengguna melakukan tindakan yang tidak diinginkan di situs tepercaya tempat pengguna saat ini diautentikasi.

Serangan CSRF memaksa browser korban yang login untuk mengirimkan permintaan HTTP palsu, termasuk cookie sesi korban dan informasi autentikasi lainnya yang disertakan secara otomatis, ke aplikasi web yang rentan.

Tautan akan dikirimkan oleh penyerang kepada korban ketika pengguna mengklik URL saat login ke situs web asli, data akan dicuri dari situs web tersebut.

Implikasi

  • Menggunakan kerentanan ini sebagai penyerang dapat mengubah informasi profil pengguna, mengubah status, membuat pengguna baru atas nama admin, dll.

Objek Rentan

  • Halaman Profil Pengguna
  • Formulir akun pengguna
  • Halaman transaksi bisnis

contoh

Korban masuk ke situs web bank menggunakan kredensial yang valid. Ia menerima email dari penyerang yang mengatakan "Silakan klik di sini untuk menyumbangkan $1 untuk tujuan ini."

Ketika korban mengkliknya, permintaan yang valid akan dibuat untuk menyumbangkan $1 ke akun tertentu.

http://www.vulnerablebank.com/transfer.do?account=cause&amount=1

Penyerang menangkap permintaan ini dan membuat permintaan di bawah ini dan menyematkannya di tombol yang bertuliskan “Saya Mendukung Penyebab.”

http://www.vulnerablebank.com/transfer.do?account=Attacker&amount=1000

Karena sesi diautentikasi dan permintaan datang melalui situs web bank, server akan mentransfer $1000 dolar ke penyerang.

Rekomendasi

  1. Mengamanatkan kehadiran pengguna saat melakukan tindakan sensitif.
  2. Menerapkan mekanisme seperti CAPTCHA, Otentikasi Ulang, dan Token Permintaan Unik.

Kesalahan Konfigurasi Keamanan

Description

Konfigurasi Keamanan harus ditetapkan dan diterapkan untuk aplikasi, kerangka kerja, server aplikasi, server web, server basis data, dan platform. Jika ini dikonfigurasi dengan benar, penyerang dapat memiliki akses tidak sah ke data atau fungsi sensitif.

Terkadang kelemahan seperti itu mengakibatkan kompromi sistem secara menyeluruh. Menjaga perangkat lunak tetap mutakhir juga merupakan keamanan yang baik.

Implikasi

  • Memanfaatkan kerentanan ini, penyerang dapat menghitung teknologi yang mendasarinya dan informasi versi server aplikasi, informasi database dan mendapatkan informasi tentang aplikasi untuk melakukan beberapa serangan lagi.

Objek yang rentan

  • URL
  • Formulir Bidang
  • Bidang masukan

contoh

  1. Konsol admin server aplikasi diinstal secara otomatis dan tidak dihapus. Akun default tidak diubah. Penyerang dapat masuk dengan kata sandi default dan dapat memperoleh akses tidak sah.
  2. Daftar Direktori tidak dinonaktifkan di server Anda. Penyerang menemukan dan dapat dengan mudah membuat daftar direktori untuk menemukan file apa pun.

Rekomendasi

  1. Arsitektur aplikasi yang kuat yang menyediakan pemisahan dan keamanan yang baik antara komponen-komponen.
  2. Ubah nama pengguna dan kata sandi default.
  3. Nonaktifkan daftar direktori dan terapkan pemeriksaan kontrol akses.

Penyimpanan Kriptografi Tidak Aman

Description

Penyimpanan kriptografi yang tidak aman adalah kerentanan umum yang muncul ketika data sensitif tidak disimpan dengan aman.

Kredensial pengguna, informasi profil, rincian kesehatan, informasi kartu kredit, dll. termasuk dalam informasi data sensitif di situs web.

Data ini akan disimpan pada database aplikasi. Jika data ini disimpan secara tidak benar dengan tidak menggunakan enkripsi atau hashing*, maka akan rentan terhadap penyerang.

(*Hashing adalah transformasi karakter string menjadi string yang lebih pendek dengan panjang tetap atau kunci. Untuk mendekripsi string, algoritma yang digunakan untuk membentuk kunci harus tersedia)

Implikasi

  • Dengan menggunakan kerentanan ini, penyerang dapat mencuri, memodifikasi data yang dilindungi dengan lemah untuk melakukan pencurian identitas, penipuan kartu kredit, atau kejahatan lainnya.

Objek yang rentan

  • Basis data aplikasi.

contoh

Di salah satu aplikasi perbankan, basis data kata sandi menggunakan hash tanpa garam * untuk menyimpan kata sandi semua orang. Cacat injeksi SQL memungkinkan penyerang mengambil file kata sandi. Semua hash yang tidak diasinkan dapat dipaksakan dalam waktu singkat, sedangkan kata sandi yang diasinkan akan memakan waktu ribuan tahun.

(*Unsalted Hashes – Salt adalah data acak yang ditambahkan ke data asli. Salt ditambahkan ke kata sandi sebelum hashing)

Rekomendasi

  1. Pastikan algoritma standar yang kuat dan sesuai. Jangan membuat algoritma kriptografi sendiri. Gunakan hanya algoritma publik yang disetujui seperti AES, kriptografi kunci publik RSA, dan SHA-256, dll.
  2. Pastikan pencadangan di luar lokasi dienkripsi, namun kuncinya dikelola dan dicadangkan secara terpisah.

Kegagalan membatasi Akses URL

Description

Aplikasi web memeriksa hak akses URL sebelum merender tautan dan tombol yang dilindungi. Aplikasi perlu melakukan pemeriksaan kontrol akses serupa setiap kali halaman ini diakses.

Di sebagian besar aplikasi, halaman, lokasi, dan sumber daya yang memiliki hak istimewa tidak disajikan kepada pengguna yang memiliki hak istimewa.

Dengan tebakan cerdas, penyerang dapat mengakses halaman hak istimewa. Penyerang dapat mengakses halaman sensitif, menjalankan fungsi, dan melihat informasi rahasia.

Implikasi

  • Memanfaatkan kerentanan ini, penyerang dapat memperoleh akses ke URL yang tidak sah, tanpa masuk ke aplikasi dan mengeksploitasi kerentanan. Penyerang dapat mengakses halaman sensitif, menjalankan fungsi, dan melihat informasi rahasia.

Objek yang rentan:

  • URL

contoh

  1. Penyerang memperhatikan bahwa URL menunjukkan peran sebagai “/user/getaccounts.” Dia memodifikasi sebagai "/admin/getaccounts".
  2. Penyerang dapat menambahkan peran ke URL.

http://www.vulnerablsite.com dapat dimodifikasi sebagai http://www.vulnerablesite.com/admin

Rekomendasi

  1. Terapkan pemeriksaan kontrol akses yang kuat.
  2. Kebijakan autentikasi dan otorisasi harus berbasis peran.
  3. Batasi akses ke URL yang tidak diinginkan.

Perlindungan Lapisan Transportasi Tidak Memadai

Description

Berurusan dengan pertukaran informasi antara pengguna (klien) dan server (aplikasi). Aplikasi sering kali mengirimkan informasi sensitif seperti detail autentikasi, informasi kartu kredit, dan token sesi melalui jaringan.

Dengan menggunakan algoritme yang lemah atau menggunakan sertifikat yang kedaluwarsa atau tidak valid atau tidak menggunakan SSL, komunikasi dapat terekspos ke pengguna yang tidak tepercaya, yang dapat membahayakan aplikasi web dan atau mencuri informasi sensitif.

Implikasi

  • Memanfaatkan kerentanan keamanan web ini, penyerang dapat mengendus kredensial pengguna yang sah dan mendapatkan akses ke aplikasi.
  • Dapat mencuri informasi kartu kredit.

Objek yang rentan

  • Data dikirim melalui jaringan.

Rekomendasi

  1. Aktifkan HTTP aman dan terapkan transfer kredensial hanya melalui HTTPS.
  2. Pastikan sertifikat Anda valid dan tidak kedaluwarsa.

contoh:

1. Aplikasi yang tidak menggunakan SSL, penyerang hanya akan memantau lalu lintas jaringan dan mengamati cookie sesi korban yang diautentikasi. Seorang penyerang dapat mencuri cookie itu dan melakukan serangan Man-in-the-Middle.

Pengalihan dan Penerusan yang Tidak Divalidasi

Description

Aplikasi web menggunakan beberapa metode untuk mengarahkan dan meneruskan pengguna ke halaman lain untuk tujuan yang dimaksudkan.

Jika tidak ada validasi yang tepat saat mengalihkan ke halaman lain, penyerang dapat memanfaatkan ini dan mengarahkan korban ke situs phishing atau malware, atau menggunakan penerusan untuk mengakses halaman yang tidak sah.

Implikasi

  • Penyerang dapat mengirimkan URL ke pengguna yang berisi URL asli yang ditambahkan dengan URL berbahaya yang disandikan. Seorang pengguna hanya dengan melihat bagian asli dari URL yang dikirimkan penyerang dapat menelusurinya dan mungkin menjadi korban.

contoh

1.http://www.vulnerablesite.com/login.aspx?redirectURL=ownsite.com

Dimodifikasi menjadi

http://www.vulnerablesite.com/login.aspx?redirectURL=evilsite.com

Rekomendasi

  1. Cukup hindari penggunaan pengalihan dan penerusan dalam aplikasi. Jika digunakan, jangan melibatkan penggunaan parameter pengguna dalam menghitung tujuan.
  2. Jika parameter tujuan tidak dapat dihindari, pastikan nilai yang diberikan valid dan diotorisasi untuk pengguna.