Celah XSS dan JWT Sebuah Kombinasi yang Buruk

2 min read

Celah XSS dan JWT Token
Photo by Clint Patterson on Unsplash

TeknoCerdas.com – Salam cerdas untuk kita semua. Pada tulisan ini tidak akan dibahas apa itu JWT karena fokus pada tulisan ini adalah dampak berbahaya JWT jika digunakan sebagai session otentikasi dan jika terdapat celah XSS. Jika terdapat celah XSS dan JWT digunakan sebagai otentikasi maka itu adalah kombinasi kejadian yang buruk.

Sebelum membaca tulisan ini ada baiknya anda memahami apa itu JWT dan serangan XSS (Cross-Site Scripting). Referensi berikut ini mungkin membantu.

Tujuan Attacker Mencuri Session

Tujuan utama attacker mencuri session salah satunya sudah pasti adalah untuk bertindak (impersonate) sebagai sebagai user yang menjadi korban serangan.

Ketika attacker berhasil mendapatkan session yang mungkin didapat dari celah XSS pada website maka dia bisa bertindak sebagai user tersebut. Jika korban adalah administrator dari website maka dampaknya tentu sangat besar karena si attacker dapat melakukan apapun di website.

Jika korban adalah user dengan role biasa maka serangan attacker dibatasi hanya dapat melakukan aksi sesuai role tersebut, misal jika dia membajak session user pada website social media maka dia dapat update status, mengirim pesan sebagai korban. Ini tentu membahayakan korban terlebih jika penyerang berpura-pura sebagai korban dan mulai meminjam uang dan sebagainya. Dimana itu lazim kita temukan dilakukan oleh si attacker.

Ketika JWT Token Dicuri

JWT adalah Stateless

Lantas kenapa sangat berbahaya jika JWT token bisa di-hijack oleh attacker? Hal itu karena sifat dari JWT yaitu stateless. Dimana pada sebuah token JWT biasanya sudah terdapat informasi data dari user pemilik token tersebut.

Sehingga pada sisi server tidak dilakukan pengecekan ulang setelah dilakukan decoding pada token tersebut. Server biasanya berasumsi selama token tersebut belum expired maka token tersebut dipastikan valid.

Hal ini adalah sisi keuntungan dari stateless token sekaligus kerugiannya.

Ketika seorang attacker menemukan celah XSS pada website yang menggunakan JWT sebagai session otentikasi. Maka kemungkinan dia bisa membaca JWT tersebut yang umumnya disimpan pada Cookie atau Local Storage.

Ketika attacker berhasil mendapatkan token JWT entah dari Cookie atau Local Storage maka selesai sudah. Server akan melakukan decoding token dan percaya bahwa token tersebut adalah milik korban padahal yang melakukan aksi sebenarnya adalah attacker.

Menambah Keamanan JWT Token

Jika aplikasi web percaya seratus persen pada data yang ada pada token JWT maka itu adalah blunder dan sebuah keputusan buruk.

Karena ketika token jatuh kepada tangan attacker bagaimana melakukan validasinya? Untuk mencegah hal itu harus ada data pembanding agar server dapat melakukan validasi. Dua data utama yang dapat dilakukan untuk validasi adalah IP dan User Agent (browser) dari pemilik token.

Umumnya untuk mencegah session hijacking server akan melakukan hal berikut.

  1. Mengecek apakah IP user sama dengan IP yang disimpan pada payload data.
  2. Mengecek apakah user-agent (browser) sama dengan user-agent yang disimpan pada payload data.

Sehingga setelah sebuah JWT Token didecode oleh server maka perlu dicek juga nilai dari IP dan User-Agent dari si pengirim token. Jika tidak sama dengan data yang ada dalam token berarti diasumsikan token tersebut tidak valid.

Pengecekan nomor 1 dan 2 adalah sangat krusial. Ketika attacker berusaha untuk mengubah mengubah data IP dan User-Agent yang ada dalam token otomatis signature JWT menjadi tidak valid.

Kesimpulan

JWT Token dapat dikatakan aman apabila digunakan untuk API, namun jika digunakan sebagai session otentikasi pada website ada hal-hal yang perlu dijadikan perhatian.

Untuk itu pastikan selalu menambahkan payload data IP da User-Agent saat membuat JWT Token.

{
  "sub": "1234567890",
  "name": "John Doe",
  "ip": "1.2.3.4",
  "user-agent": "Mozilla/1.2",
  "iat": 1516239022,
  "jti": "9f7fed17-1ba8-4b0c-aa16-fb58bfd3a11a",
  "exp": 1612142543
}

Ketika token tersebut ditamper atau diubah otomatis signature token tidak valid. Sehingga attacker terpaksa menggunakan token apa adanya. Namun disisi server token tersebut setelah didecode akan dilakukan double check yaitu pengecekan IP dan User-Agent.