Get best of the week

Tentang menyimpan token JWT di browser


Standar terbuka JWT secara resmi muncul pada 2015 ( rfc7519 ) menjanjikan fitur menarik dan prospek luas. Penyimpanan yang tepat dari token Access sangat penting untuk membangun sistem otorisasi dan otentikasi di Web modern, di mana situs yang dibangun menggunakan teknologi SPA menjadi lebih populer.

Penyimpanan token yang salah menyebabkan pencurian dan penggunaan kembali oleh penyerang.

Jadi ke mana harus menyimpan?


Pertimbangkan opsi utama untuk menyimpan token JWT Access di browser:

  1. Penyimpanan Lokal / Penyimpanan Sesi - metode ini tidak aman dan rentan terhadap serangan seperti XSS, terutama jika Anda menghubungkan skrip dari CDN pihak ketiga (menambahkan atribut integritas tidak dapat menjamin keamanan 100%), atau Anda tidak yakin apakah skrip yang Anda sambungkan tidak memiliki kemampuan untuk "menggabungkan" data dari penyimpanan ke samping. Selain itu, jika Penyimpanan Lokal tersedia di antara tab, maka Penyimpanan Sesi hanya tersedia di satu tab dan membuka situs di tab baru hanya akan menyebabkan putaran baru token / otorisasi akses.
  2. , , fetch . – .
  3. Cookies. «» cookie sessions. Access cookie CSRF. XSS . CSRF Cookie SameSite Strict– , , credentials, CSRF .
    – Access JS httpOnly, Secure .

    Poin penting adalah mengatur cookie hanya untuk domain / jalur api sehingga permintaan untuk statika publik tidak mengandung overhead di header.

Apa hasilnya?


Cookie, ketika digunakan dengan benar, adalah solusi yang tepat dan teraman untuk menyimpan token JWT Access saat ini dan harus mengikuti aturan berikut:

  1. Dipasang untuk domain / jalur API untuk menghindari overhead saat meminta file statis (file gambar / gaya / js publik).
  2. Memiliki bendera Aman (hanya untuk transfer via https).
  3. Memiliki tanda httpOnly (untuk ketidakmampuan mengakses dari JavaScript).
  4. Atribut SameSite harus Ketat untuk melindungi terhadap serangan CSRF, melarang transfer cookie jika transisi ke API Anda bukan dari domain yang ditentukan dalam cookie.

Di sisi server, itu juga harus dikonfigurasi:

  1. Content-Security-Policy - batasi domain tepercaya untuk mencegah kemungkinan serangan XSS
  2. Header X-Frame-Options untuk melindungi dari serangan clickjacking.
  3. X-XSS-Protection - memaksakan mekanisme perlindungan built-in browser dari serangan XSS.
  4. X-Content-Type-Options - untuk melindungi dari penggantian tipe MIME.

Kepatuhan terhadap langkah-langkah ini, ditambah dengan rotasi token Akses / Refresh yang sering, harus membantu memastikan tingkat keamanan yang tinggi di situs.

Keterbatasan


Terlepas dari kenyataan bahwa atribut SameSite didukung di banyak browser populer , ada juga browser yang tidak mendukungnya atau mendukung sebagiannya (halo IE dan Safari untuk Mac). Untuk kasus-kasus ini, Anda harus mundur ke token CSRF. Dalam hal ini, bersama dengan permintaan ke API, token CSRF juga harus ditransmisikan. Token CSRF yang benar harus dihasilkan oleh server dengan mempertimbangkan sidik jari pengguna untuk meminimalkan kemungkinan penggantiannya.

More articles:


All Articles