Kerentanan dan Solusi Pada Keamanan Websocket

Apa itu WebSocket?

WebSockets menjadi semakin populer karena sangat menyederhanakan komunikasi antara client dan server. Protokol WebSocket menggunakan lapisan aplikasi model OSI (Layer 7) untuk memungkinkan client dan server melakukan komunikasi dua arah (duplikat penuh). Ini memungkinkan Anda membuat aplikasi web waktu nyata yang dinamis seperti aplikasi perpesanan instan dan berbagi foto.

WebSockets mengatasi beberapa batasan komunikasi tradisional antara browser dan server:

Client requests/server responds – Server sebelumnya memiliki listener yang permananen. client (client yang menggunakan browser) tidak memiliki listener tetap untuk koneksi jangka panjang. Ini berkisar pada request client dan responds server.
Communication dependent on client – Server dapat mendorong sumber daya ke client hanya ketika client memintanya.
Continual checking – client selalu dipaksa untuk memperbarui hasil dari server. Itu sebabnya perpustakaan berfokus pada pengoptimalan semua panggilan asinkron. Mereka juga harus mengidentifikasi reaksi mereka. Solusi paling umum untuk moriginah ini adalah dengan menggunakan fungsi callback.

WebSockets mengatasi penundaan yang melekat dalam komunikasi satu arah dari client ke browser. Pada http[s]:// protocol, client memulai request dan menunggu responds. Ini disebut transaksi. Setiap request/responds memulai transaksi yang berbeda, dan setiap transaksi memiliki overhead. ws[s]:// Dalam protokol, WebSockets menggunakan beberapa request dan responds untuk memulai transaksi jangka panjang. Server juga dapat mengirim data tanpa request sebelumnya, yang membuat komunikasi jauh lebih efisien.

Kerentanan WebSocket yang paling umum

Mari kita lihat kerentanan WebSocket yang paling umum dan lihat bagaimana mereka dieksploitasi:

Kerentanan WebSocket yang paling umum meliputi:

serangan DoS
Tidak ada sertifikasi selama proses Handshake
Saluran TCP tidak terenkripsi
Kerentanan untuk memasukkan serangan data
Penyamaran data
Persetujuan/Sertifikasi
Terowongan
Mengendus serangan

serangan DoS

WebSockets memungkinkan Anda untuk mencapai jumlah koneksi yang tidak terbatas ke server Anda. Hal ini memungkinkan penyerang membanjiri server dengan serangan DOS. Ini memberikan banyak tekanan pada server dan kehabisan sumber daya di server itu. Setelah itu, situs web akan jauh lebih lambat.

Tidak ada sertifikasi selama proses Handshake

Moriginahnya di sini adalah bahwa dengan protokol WebSocket, server tidak dapat mengotentikasi client selama proses Handshake. Hanya mekanisme koneksi HTTP biasa yang tersedia. Ini termasuk otentikasi dan cookie HTTP dan TLS. Handshake yang ditingkatkan akan terus terjadi dari HTTP ke WebSockets. Namun, HTTP mengirimkan kredensial langsung ke WS. Ini dapat dieksploitasi dan serangan ini disebut pembajakan WebSocket lintas situs.

Saluran TCP tidak terenkripsi

Moriginah lain dengan WebSockets adalah mereka dapat digunakan dengan saluran TCP yang tidak terenkripsi. Ini memunculkan semua jenis moriginah yang tercantum dalam Penerbitan Data Rahasia 10 A6 Teratas OWASP.

Kerentanan Pada Input Data

Bagaimana jika komponen tersebut rentan terhadap serangan data input berbahaya? Teknik seperti skrip lintas situs. Ini adalah serangan umum tetapi sangat berbahaya yang dapat menyebabkan kerusakan signifikan pada situs web Anda.

Data Masking

Data Masking bukanlah hal yang buruk. Protokol WebSocket menggunakan ini untuk mencegah keracunan cache proxy, dll. Namun, ada moriginah. Masking memblokir tindakan seperti alat keamanan yang mengidentifikasi pola lalu lintas.

Perangkat lunak seperti DLP (Data Loss Prevention) bahkan tidak mengenali keberadaan WebSockets. Hal ini membuat tidak mungkin untuk melakukan analisis data pada lalu lintas WebSocket. Ini mencegah program perangkat lunak ini mengidentifikasi JavaScript berbahaya, pelanggaran data, dan sebagainya.

Ootorisasi/otentikasi WhenSocket

Kelemahan utama dari protokol WebSocket adalah tidak menangani otorisasi/otentikasi. Protokol tingkat aplikasi harus menangani ini satu per satu. Terutama ketika data sensitif ditransfer.

Tunneling

WebSocket memungkinkan siapa pun untuk melakukan tunnel layanan TCP apa pun. Contohnya adalah tunneling koneksi database secara langsung untuk mencapai browser. Dalam kasus serangan skrip lintas situs, itu berkembang dan menjadi pelanggaran keamanan total.

Sniffing

Transfer data melalui protokol WebSocket adalah teks biasa, mirip dengan HTTP. Oleh karena itu, data ini rentan terhadap serangan man-in-the-middle. Gunakan protokol WebSocket Secure (wss://) untuk mencegah kebocoran informasi. Seperti HTTPS, wss tidak berarti bahwa aplikasi web Anda aman, tetapi memastikan bahwa transmisi data Anda dienkripsi menggunakan Transport Layer Security (TLS).

Bagaimana meningkatkan keamanan WebSocket:

Berikut adalah beberapa panduan pencegahan untuk melindungi WebSockets:

WSS

Jangan gunakan ws://. Ini bukan transportasi yang aman. Sebagai gantinya, gunakan protokol wss:// yang jauh lebih aman. Karena WSS aman, ia mencegah serangan man-in-the-middle dan sebagainya. Transportasi yang aman mencegah banyak serangan dari awal.

Kesimpulannya, WebSocket bukanlah implementasi soket standar. WebSockets serbaguna, koneksi yang dibuat selalu terbuka, dan pesan dapat dikirim dan diterima terus menerus. Namun, serangan DOS, tidak ada otentikasi/otorisasi, dan serangan entri data semuanya rentan terhadap eksploitabilitas. Oleh karena itu, penting untuk menggunakan input client dan validasi data server, otentikasi berbasis tiket, dan WSS.

>Verifikasi Input client

Data apa saja pada Koneksi WebSocket dapat dengan mudah dibuat di luar browser. Menangani data sewenang-wenang apa pun yang terjadi. Data ini perlu divalidasi dan data lain dari client divalidasi sebelum data diproses. mengapa? Karena serangan injeksi seperti OS, SQL, dan Blind SQL dimungkinkan melalui WebSocket.

Verifikasi data server

Anda tidak perlu khawatir hanya memvalidasi data client. Data yang dikembalikan oleh server juga bisa bermoriginah. Pesan yang diterima di sisi client harus selalu diperlakukan sebagai data. Kami tidak menyarankan untuk menetapkan pesan ini secara langsung ke DOM atau mengevaluasinya sebagai kode. Untuk respons JSON, gunakan JSON.parse() dalam kombinasi dengan penanganan pengecualian dan, jika perlu, gunakan metode sanitasi khusus untuk menguraikan data dengan aman.

Otentikasi berbasis tiket

Seperti disebutkan sebelumnya, protokol WebSocket tidak menangani otorisasi atau otentikasi. Jadi bagaimana Anda meningkatkan keamanan WebSockets? Optimalkan dan lindungi koneksi Anda. WebSockets melewati semua header HTTP standar yang digunakan untuk otentikasi. Jadi mengapa tidak menggunakan mekanisme otentikasi yang digunakan untuk tampilan web pada koneksi WebSocket?

Anda tidak dapat menyesuaikan header WebSocket dari JavaScript. Sayangnya, setiap orang terbatas pada otentikasi "implisit" (cookie) yang dikirim oleh browser. Ini bukan satu-satunya server yang menangani WebSockets, karena biasanya terpisah dari server yang menangani request HTTP standar. Ini secara signifikan menghalangi header otentikasi bersama. Untungnya, ada pola yang dapat membantu moriginah otentikasi WebSocket. Sistem otentikasi berbasis tiket yang bekerja sebagai berikut:

Ketika kode sisi client mencoba membuka WebSocket, itu terhubung ke server HTTP dan memungkinkan kode sisi client untuk mendapatkan tiket (disetujui).
Ini akan menghasilkan tiket yang mencakup ID pengguna/akun, IP orang yang meminta tiket, cap waktu, dan penyimpanan catatan internal lainnya.
Tiket disimpan di server/database dan dikembalikan ke client
client sekarang dapat membuka koneksi WebSocket dan mengirim tiket ini dengan Handshake pertama.
Server sekarang memiliki opsi seperti perbandingan tiket, peringkat IP sumber, dan verifikasi keamanan tiket (jika digunakan kembali).
Jika semuanya diperiksa, koneksi WebSocket akan diverifikasi

Pencegahan Tunneling

Seperti yang telah disebutkan, tunneling layanan TCP apa pun melalui WebSockets itu mudah. Ini adalah risiko yang perlu dicegah. Apa cara terbaik untuk menghindari moriginah ini? Hindari tunneling sebanyak mungkin. Sangat disarankan untuk menggunakan protokol lain yang dilindungi dan divalidasi di WebSockets.

Rate Limiting

Batas tarif adalah cara penting untuk mencegah penyalahgunaan aplikasi atau layanan web. Lindungi diri Anda dari bot jahat, serangan pengikisan, dan serangan penolakan layanan (DoS) kecil. Dalam beberapa kasus, client yang tidak berfungsi dapat memicu serangan DoS yang tidak disengaja.

Untuk menerapkan rate limiting, tetapkan "ember" untuk semua pengguna dan tentukan parameter berikut:

Jumlah lalu lintas WebSocket yang dikirim pengguna per detik
Jumlah lalu lintas yang dapat ditangani server dengan aman per detik
Lalu lintas dari pengguna yang sama yang melebihi kapasitas server harus antri
Server harus mengizinkan periode waktu tunggu tertentu. Hal ini memungkinkan lalu lintas burst oleh client diikuti oleh periode tenang selama serverdapat memproses antrian.
Pesan dalam antrian harus dibuang setelah batas waktu

Origin Header

Standar WebSocket memungkinkan Anda untuk menentukan field origin header. Ini mirip dengan AJAX X-Requested-With header. Tentukan dari host mana koneksi WebSocket berorigin. Jika tidak, client dapat berkomunikasi dengan host mana pun melalui protokol WebSocket.

origin Header adalah saran dan dapat dipalsukan oleh penyerang. Namun, penyerang masih perlu mengubah Origin header di browser client. Ini diblokir oleh browser modern di sebagian besar situasi. Oleh karena itu, menyetel field origin adalah ide yang bagus, tetapi Anda tidak boleh memercayainya untuk autentikasi. Selalu gabungkan dengan cookie atau mekanisme otentikasi lainnya.

Keamanan WebSocket dengan Bright

Cara terbaik untuk memperbaiki kerentanan keamanan WebSocket adalah dengan menggunakan Bright, solusi pengujian keamanan kotak hitam yang melihat aplikasi, API, atau WebSocket untuk menemukan kerentanan.

Bright adalah pemindai otomatis yang secara independen mendeteksi kerentanan keamanan tanpa bantuan manusia. Ini adalah obat yang bagus karena anda dapat dengan cepat mengidentifikasi kerentanan keamanan di WebSockets, mengirim peringatan dengan panduan perbaikan ke pengembang, dan secara otomatis membuka tiket dengan alat pelacakan bug.