Celah Keamanan Websocket (Cross-Site WebSocket Hijacking)

Same-origin policy (SOP) adalah salah satu pertahanan dasar yang diterapkan dalam aplikasi web modern. Ini membatasi bagaimana skrip dari satu asal berinteraksi dengan sumber daya dari asal lain. Terakhir kali, kami berbicara tentang kebijakan asal yang sama dan bagaimana kebijakan itu melindungi data situs Anda dari akses yang tidak sah.

Namun, ada beberapa kasus yang tidak tercakup dalam SOP, yang dapat dimanfaatkan oleh penyerang untuk mencuri informasi pribadi. Hari ini, saya akan membahas salah satu kasus ini, koneksi WebSocket, dan bagaimana penyerang dapat membajak koneksi WebSocket dan membocorkan data pribadi. Mari kitas selami!

Apa itu WebSocket?

WebSocket, seperti HTTP, adalah protokol komunikasi yang memungkinkan dialog antara browser dan server web. Protokol WebSocket memungkinkan server dan browser untuk mengirim pesan satu sama lain menggunakan koneksi TCP tunggal. Ini sangat berguna saat membuat aplikasi real-time seperti game online dan live chat. Misalnya, aplikasi web Slack menggunakan koneksi WebSocket untuk menyinkronkan pesan dengan fitur obrolan.

Untuk menyinkronkan aplikasi web secara real time, server web harus dapat secara aktif mendorong data ke klien. Dan di sinilah WebSockets masuk. Secara tradisional, HTTP hanya mendukung komunikasi yang dimulai oleh klien. Ini berarti bahwa setiap kali aplikasi realtime perlu disinkronkan (misalnya, game online yang memperbarui papan peringkat langsung), browser klien harus mengirim permintaan HTTP untuk mengambil data dari server. Jika aplikasi Anda terus-menerus melakukan pembaruan jenis ini, metode tradisional ini menimbulkan banyak overhead yang tidak perlu dan pada akhirnya memperlambat aplikasi Anda.

Protokol WebSocket, di sisi lain, memecahkan masalah ini dengan membuat koneksi terus-menerus antara klien dan server yang memungkinkan transfer data yang dimulai oleh klien dan server. Selama masa koneksi WebSocket, klien dan server bebas bertukar data dalam jumlah berapa pun tanpa biaya tambahan dan penundaan penggunaan permintaan HTTP tradisional.

Cara membuat koneksi WebSocket

Koneksi WebSocket antara klien dan server dibuat melalui handshake WebSocket. Proses ini dimulai ketika klien mengirimkan permintaan HTTP atau HTTPS biasa ke server dengan header khusus "Upgrade: websocket". Jika server mendukung koneksi WebSocket, server merespons dengan kode status 101 (protokol switching). Sejak saat itu, handshake selesai dan kedua belah pihak bebas untuk mengirim data ke yang lain.

CATATAN: WebSockets menggunakan ws://skemaURL dan wss://skemaURL untuk koneksi yang aman.

Masalah WebSocket

Seperti yang disebutkan dalam artikel Kebijakan Asal yang Sama, SOP adalah cara untuk mencegah akses data yang tidak diinginkan dari domain jahat. Namun, kebijakan asal yang sama tidak berlaku untuk koneksi WebSocket, dan browser modern tidak mencegah pembacaan data melalui koneksi WebSocket antar sumber.

Artinya, jika penyerang dapat menggunakan kredensial korban untuk membuat koneksi WebSocket, koneksi tersebut akan memiliki izin yang sama dengan koneksi yang sah, terlepas dari sumbernya.

Pembajakan WebSocket Cross-Site

Serangan pembajakan WebSocket Cross-Site pada dasarnya adalah CSRF dari handshake WebSocket. Ketika pengguna masuk ke korban.com di browser mereka dan membuka penyerang.com di browser yang sama, penyerang.com dapat mencoba membuat koneksi WebSocket ke server korban.com. Permintaan handshake WebSocket yang diprakarsai oleh penyerang.com berisi kredensial sah pengguna karena browser pengguna secara otomatis mengirimkan kredensial, termasuk permintaan HTTP / HTTPS, ke korban.com. Ini berarti bahwa koneksi WebSocket yang dihasilkan (dibuat oleh penyerang.com) akan memiliki tingkat akses yang sama seperti jika berasal dari vicitm.com.

Setelah koneksi WebSocket dibuat, penyerang.com dapat berkomunikasi langsung dengan korban.com sebagai pengguna yang sah.

Struktur serangan

Untuk melakukan serangan, penyerang membuat skrip yang memulai koneksi WebSocket ke server korban. Anda kemudian dapat menyematkan skrip di halaman berbahaya untuk mengelabui pengguna agar mengakses halaman tersebut.

Saat korban mengunjungi halaman berbahaya, browser secara otomatis menyertakan cookie dalam permintaan handshake WebSocket (karena ini adalah permintaan HTTP biasa). Skrip berbahaya yang dibuat oleh penyerang dapat memperoleh akses ke koneksi WebSocket yang dibuat menggunakan kredensial korban.

Dampak pembajakan WebSocket Cross-Site

Menggunakan koneksi WebSocket yang dibajak, penyerang sekarang dapat menyelesaikan banyak hal:

WebSocket CSRF: Saat menggunakan komunikasi WebSocket untuk melakukan tindakan perubahan status sensitif, penyerang dapat menggunakan koneksi ini untuk memalsukan tindakan atas nama pengguna. Misalnya, penyerang dapat memposting pesan palsu ke grup obrolan pengguna.
Mengambil Data Pribadi: Jika informasi sensitif dapat diambil melalui permintaan klien menggunakan komunikasi WebSocket, penyerang dapat memulai permintaan palsu untuk mengambil data sensitif milik pengguna.
Kebocoran data pribadi melalui pesan server: Penyerang juga dapat mencegat pesan server dan secara pasif mengumpulkan informasi yang bocor dari pesan ini. Misalnya, penyerang dapat menggunakan koneksi ini untuk menguping notifikasi masuk pengguna. Bagaimana mencegah pembajakan WebSocket Cross-Site Untuk mencegah pembajakan WebSocket Cross-Site, aplikasi harus menolak permintaan handshake WebSocket dari sumber yang tidak dikenal. Ada dua cara untuk mencapai ini.

Bagaimana mencegah pembajakan WebSocket Cross-Site

Untuk mencegah pembajakan WebSocket Cross-Site, aplikasi harus menolak permintaan handshake WebSocket dari sumber yang tidak dikenal. Ada dua cara untuk mencapai ini.

Periksa tajuk Asal. Browser secara otomatis menyertakan header Origin. Ini dapat digunakan untuk memverifikasi dari mana permintaan handshake berasal. Saat memvalidasi sumber permintaan, gunakan daftar URL yang diizinkan daripada daftar hitam, dan gunakan ekspresi reguler yang diuji secara ketat dan ketat.
Gunakan token CSRF untuk permintaan handshake WebSocket: Aplikasi juga dapat menggunakan token acak untuk permintaan handshake WebSocket dan memvalidasinya di sisi server sebelum membuat koneksi WebSocket. Jadi, jika penyerang membocorkan atau tidak dapat memprediksi token acak, penyerang tidak akan dapat membuat koneksi.

WebSockets adalah bagian besar dari banyak aplikasi modern. Namun, sering diabaikan sebagai vektor serangan potensial.

Penting bagi pengembang dan pentester untuk menyadari perangkap umum ini dan menyadari kerentanan ini sebelum benar-benar dieksploitasi.

Seperti biasa, terima kasih telah membaca!