6 Risiko Keamanan Backend Web untuk Dipertimbangkan dalam Pembangunan

Ambil langkah-langkah dalam pengembangan untuk mengeraskan dan menjaga keamanan web Anda.


Usaha kecil, bank, dan banyak industri bergantung pada aplikasi web. Dari saat membangun aplikasi web, sangat penting untuk memastikan memiliki protokol untuk memeriksa kerentanan saat pengembangan berkembang untuk menghindari pelanggaran keamanan, kebocoran data, dan masalah keuangan.

Serangan web paling berbahaya adalah serangan yang terjadi di sisi server tempat data disimpan dan dianalisis.

Apa itu Backend?

Aplikasi web dibagi menjadi dua bagian – Frontend dan Backend.

  • Frontend adalah sisi klien, itu bagian yang berinteraksi dengan pengguna. Biasanya, itu dibangun dengan HTML, CSS, dan Javascript.
  • Backend adalah sisi server. Pada dasarnya cara kerja aplikasi, menerapkan logika bisnis, perubahan, dan pembaruan. Beberapa tumpukan teknologi sisi server yang populer melibatkan PHP, NodeJS, Java, Ruby, C, Python, database, keamanan (otentikasi, kontrol akses, dll.), Struktur, dan manajemen konten.

Pengingat kecil sebelum kita mulai – otentikasi, kontrol akses & manajemen sesi

Sudah biasa bagi kami untuk mengacaukan persyaratan. Jadi mari kita perjelas dengan cepat:

  • Otentikasi menyangkut pembuktian identitas pengguna (mis., Kata sandi, nama pengguna, keamanan pertanyaan, sidik jari)
  • Kontrol akses menyangkut apa yang pengguna dapat mengakses aplikasi. Ini memberlakukan kebijakan bahwa pengguna tidak dapat bertindak di luar izin yang dimaksudkan.
  • Manajemen sesi berkaitan dengan respons dan permintaan transaksi yang terkait dengan pengguna yang sama. Ini adalah mekanisme pertukaran yang digunakan antara pengguna dan aplikasi setelah ia berhasil diautentikasi.

Mari kita telusuri yang berikut untuk keamanan web back-end yang lebih baik.

Kelemahan injeksi

Sejak 2010, OSWAP mengklasifikasikan injeksi sebagai risiko aplikasi web # 1 yang paling berbahaya.

Kelemahan injeksi memungkinkan pengguna untuk menyediakan data yang berisi kata kunci yang akan mengubah perilaku kueri yang dibangun pada database. Misalnya, misalkan kita memiliki skrip SQL yang memeriksa apakah entri yang cocok ada di database.

uname = request.POST [‘username’]
passwd = request.POST [‘password’]
sql = "PILIH id DARI pengguna DI MANA username = ‘" + nama kamu + "’DAN kata sandi =’" + sandiwara + "’"
database.execute (sql)

Penyerang sekarang dapat memanipulasi bidang kata sandi menggunakan injeksi SQL, misalnya dengan memasukkan kata sandi ‘ATAU 1 =’ 1, yang mengarah ke permintaan SQL berikut:

sql = "PILIH id DARI pengguna DI MANA nama pengguna = ” DAN kata sandi = ‘kata sandi’ ATAU 1 = ‘1’

Dengan melakukan itu, penyerang dapat mengakses semua tabel pengguna dari basis data, kata sandi selalu valid (1 = ‘1’). Jika mereka masuk sebagai administrator, mereka dapat membuat perubahan apa pun yang diinginkannya.

Cara mencegahnya?

Itu sangat MUDAH untuk menghindari cacat injeksi.

Cara terbaik dan sederhana untuk memverifikasi jika tidak ada kekurangan injeksi adalah tinjauan kode sumber manual menyeluruh untuk memeriksa apakah pertanyaan dalam database dilakukan melalui pernyataan yang disiapkan. Anda juga dapat menggunakan alat untuk memeriksa kerentanan.

Dan Anda juga harus melakukan hal berikut.

  • Gunakan ORM (Alat Pemetaan Relasional Objek).
  • Keluar dari semua input. Bidang tanggal tidak boleh menyimpan apa pun di dalamnya kecuali tanggal.
  • Isolasi data Anda sehingga hanya hal-hal yang harus diakses dari lokasi tertentu yang disimpan di lokasi itu.
  • Tulis kode kesalahan penanganan yang baik. Jangan membuat database atau backend Anda terlalu bertele-tele.

Troy Hunt mendapat kursus cemerlang tentang injeksi SQL. Jika tertarik, Anda bisa menjelajahinya.

Otentikasi yang rusak

Seperti disebutkan sebelumnya, otentikasi berkaitan dengan kredensial yang diberikan. Ini adalah garis depan pertahanan terhadap akses tidak terbatas. Namun, implementasi yang buruk dan tidak menghargai kebijakan keamanan dapat menyebabkan otentikasi yang rusak.

Otentikasi yang rusak sebagian besar terjadi oleh tiga pola:

  • Isian kredensial: di mana penyerang memiliki daftar nama pengguna dan kata sandi yang valid dan dapat mengotomatiskan serangan untuk mencari kredensial yang valid.
  • Serangan Bruteforce: ketika aplikasi mengizinkan kata sandi yang lemah untuk pengguna atau admin.
  • Pembajakan sesi: tempat aplikasi memperlihatkan ID sesi, URL, atau tidak berputar setelah login.

Dalam semua kasus, penyerang dapat memperoleh akses ke akun penting dan bergantung pada bisnis yang dapat menyebabkan pencucian uang, pencurian identitas, atau mengungkapkan informasi yang sangat sensitif dan dilindungi secara hukum..

Cara mencegahnya?

Sebelum menerapkan sistem otentikasi, tanyakan pada diri Anda – apa yang bisa dicapai penyerang jika sistem otentikasi dikompromikan?

Dan menurut tanggapan, Anda dapat melakukan hal berikut.

  • Terapkan otentikasi multi-faktor untuk mencegah serangan otomatis.
  • Dorong (atau paksakan) pengguna untuk mengadopsi kebijakan kata sandi yang baik.
  • Batasi login yang gagal.
  • Gunakan hash algoritma yang efisien. Saat memilih suatu algoritma, pertimbangkan panjang kata sandi maksimal.
  • Tes sistem batas waktu sesi dan pastikan token sesi tidak valid setelah keluar.

Kontrol Akses Rusak

Kontrol akses ada untuk memastikan apa yang diizinkan dilakukan oleh pengguna yang diotentikasi. Otentikasi dan manajemen sesi adalah dasar atau aturan kontrol akses. Tetapi ketika aturan itu tidak ditetapkan dengan baik, ini dapat menyebabkan masalah yang signifikan.

Kelemahan kontrol akses yang umum meliputi:

  • Kesalahan konfigurasi CORS yang memungkinkan akses API tidak sah.
  • Manipulasi metadata untuk mengarahkan akses ke metode.
  • Penjelajahan paksa: Penyerang akan mencoba URL, memodifikasi jalur (mis., Http: //website.domain/user/ ke http: //website.domain/admin), dan bahkan dapat menemukan file penting.

Cara mencegahnya?

Sebagian besar, cacat akses yang rusak terjadi karena ketidaktahuan tentang persyaratan penting dari manajemen akses yang efektif.

  • Tolak secara default kecuali sumber daya publik.
  • Nonaktifkan daftar direktori server dan pastikan file cadangan tidak ada.
  • Nilai batas akses API untuk mengurangi dampak serangan otomatis.
  • Validasi token JWT setelah keluar di sisi-belakang.

Paparan Data

Juga disebut sebagai pelanggaran data, paparan data adalah ancaman dunia maya yang mengancam bisnis dan klien mereka.

Itu terjadi ketika aplikasi tidak cukup melindungi informasi seperti kredensial atau data sensitif seperti kartu kredit atau catatan kesehatan. Lebih dari 4000 catatan dilanggar setiap menit.

Dampak pada bisnis besar dari sisi keuangan: Pelanggaran rata-rata dapat menelan biaya USD 3,92 juta, menurut IBM.

Cara mencegahnya?

Sebagai pengembang backend, Anda harus bertanya informasi apa yang perlu dilindungi.

Dan kemudian untuk mencegah kekurangan tersebut:

  • Enkripsi data sensitif: Untuk data di REST, enkripsi semua. Untuk data dalam perjalanan, pastikan untuk menggunakan gateway aman (SSL)
  • Identifikasi data yang membutuhkan perlindungan ekstra dan batasi aksesibilitas hanya untuk sekelompok pengguna yang sah hanya dengan menerapkan enkripsi berbasis kunci.
  • Hindari algoritma enkripsi yang lemah: gunakan yang terbaru dan algoritma yang kuat.
  • Miliki rencana cadangan yang aman.

Deserialisasi yang tidak aman

Serialisasi dan deserialisasi adalah konsep yang digunakan ketika data dikonversi dalam format objek untuk disimpan atau dikirim ke aplikasi lain. Serialisasi terdiri dari konversi data dalam format objek seperti XML atau JSON untuk membuatnya dapat digunakan. Deserialisasi hanyalah proses sebaliknya.

Serangan terhadap deserializer dapat menyebabkan serangan penolakan layanan, kontrol akses, dan eksekusi kode jarak jauh (RCE) jika ada kelas yang dapat dimodifikasi untuk mengubah perilaku.

Contoh kedua dokumen OWASP 10 teratas memberikan ilustrasi yang baik tentang objek serializer PHP:

a: 4: {i: 0; i: 132; i: 1; s: 7:"Mallory"; i: 2; s: 4:"pengguna";
i: 3; s: 32:"b6a8b3bea87fe0e05022f8f3c88bc960";}

Ini adalah supercookie yang berisi informasi seperti ID pengguna, level pengguna, dan kata sandi hash.

Seorang penyerang dapat mengubah objek serial untuk mendapatkan akses ke hak istimewa admin:

a: 4: {i: 0; i: 1; i: 1; s: 5:"Alice"; i: 2; s: 5:"admin";
i: 3; s: 32:"b6a8b3bea87fe0e05022f8f3c88bc960";}

Cara mencegahnya?

Sangat penting untuk tidak menerima objek serial dari sumber yang tidak dipercaya.

Kamu juga harus:

  • Jangan pernah mempercayai input pengguna.
  • Validasi data: Jika aplikasi Anda kecuali string, pastikan itu adalah string sebelum menggunakannya
  • Gunakan tanda centang untuk memastikan bahwa data belum diubah. Berguna Anda mengirim data antara dua sumber tepercaya (mis., Menyimpan data sisi klien).

Server XSS

Server XSS (Cross-site scripting) adalah jenis injeksi ketika penyerang menggunakan aplikasi web untuk mengirim kode berbahaya ke pengguna yang berbeda. Itu terjadi ketika penyerang memposting beberapa data buatan yang mengandung kode berbahaya yang disimpan oleh aplikasi. Kerentanan ini adalah sisi-server; browser hanya memberikan respons.

Misalnya, dalam sebuah forum, posting pengguna disimpan dalam database, seringkali tanpa verifikasi. Penyerang mengambil kesempatan ini untuk menambahkan posting dengan skrip berbahaya. Selanjutnya, pengguna lain menerima tautan ini melalui email atau melihat posting yang dimaksud dan mengkliknya.

Cara mencegahnya?

Setelah identifikasi utama semua operasi yang berpotensi berisiko XSS dan yang perlu dilindungi, Anda harus mempertimbangkan yang berikut ini.

  • Input validasi: periksa panjang input, gunakan pencocokan regex, dan hanya mengizinkan serangkaian karakter tertentu.
  • Validasi output: Jika aplikasi menyalin responsnya ke item data apa pun yang berasal dari beberapa pengguna atau pihak ketiga, data ini harus dikodekan-HTML untuk membersihkan karakter yang berpotensi berbahaya.
  • Izinkan batas HTML: misalnya, jika Anda memiliki sistem blog komentar, hanya izinkan penggunaan tag tertentu. Jika Anda bisa, gunakan kerangka kerja yang sesuai untuk markup HTML yang disediakan pengguna untuk mencoba memastikan bahwa itu tidak mengandung sarana untuk mengeksekusi JavaScript.

Kesimpulan

Tahap pengembangan sangat penting untuk keamanan aplikasi web. Dan, Anda harus mempertimbangkan untuk memasukkan pemindai kerentanan keamanan dalam siklus hidup pengembangan, sehingga masalah yang diidentifikasi diperbaiki sebelum produksi.

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map