Haruskah JWT disimpan di Penyimpanan lokal atau cookie? [duplikat]

105

Untuk tujuan mengamankan REST API menggunakan JWT, menurut beberapa materi (seperti panduan ini dan pertanyaan ini ), JWT dapat disimpan di Penyimpanan lokal atau Cookie . Berdasarkan pemahaman saya:

localStorage tunduk pada XSS dan umumnya tidak disarankan untuk menyimpan informasi sensitif di dalamnya.
Dengan Cookies kita dapat menerapkan bendera "httpOnly" yang mengurangi risiko XSS. Namun jika kami membaca JWT dari Cookie di backend, kami akan dikenai CSRF.

Jadi berdasarkan premis di atas - akan lebih baik jika kita menyimpan JWT dalam Cookies. Pada setiap permintaan ke server, JWT akan dibaca dari Cookies dan ditambahkan di header Otorisasi menggunakan skema Bearer. Server kemudian dapat memverifikasi JWT di header permintaan (bukan membacanya dari cookie).

Apakah pemahaman saya benar? Jika ya, apakah pendekatan di atas memiliki masalah keamanan? Atau sebenarnya kita bisa lolos dengan menggunakan localStorage di tempat pertama?

— pkid169
sumber

4

periksa ini: cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions

— corlaez

@ lrn2prgrm sebagai seseorang tidak boleh menggunakan (stateless) JWT dan semantik sesi (stateful) bersama-sama.

— ozanmuyes

@corlaez Saya menggunakan JWT dan saya berencana untuk menggunakan header Otentikasi "Bearer mytoken" di sisi server untuk memverifikasi jwt saya. Kebingungan saya adalah ini: Jika saya mengirim jwt asli dalam cookie pada login pertama (dikirim dari server ke browser) dengan bendera httpOnly, bagaimana cara mengekstrak jwt dari sisi klien untuk dimasukkan ke dalam header Otentikasi saya untuk permintaan selanjutnya? Bukankah bendera httpOnly akan melarang saya mengekstrak informasi dari cookie di sisi klien?

— Harshit Trehan

60

Saya suka metode XSRF Double Submit Cookies yang disebutkan dalam artikel yang dikatakan @ pkid169, tetapi ada satu hal yang tidak diberitahukan artikel tersebut kepada Anda. Anda masih belum terlindungi dari XSS karena apa yang dapat dilakukan penyerang adalah menyuntikkan skrip yang membaca cookie CSRF Anda (yang bukan HttpOnly) dan kemudian membuat permintaan ke salah satu titik akhir API Anda menggunakan token CSRF ini dengan cookie JWT dikirim secara otomatis.

Jadi pada kenyataannya Anda masih rentan terhadap XSS, hanya saja penyerang tidak dapat mencuri token JWT Anda untuk digunakan nanti, tetapi dia tetap dapat membuat permintaan atas nama pengguna Anda menggunakan XSS.

Baik Anda menyimpan JWT di Penyimpanan lokal atau menyimpan token XSRF Anda bukan hanya dalam cookie http, keduanya dapat diambil dengan mudah oleh XSS. Bahkan JWT Anda dalam cookie HttpOnly dapat diambil dengan serangan XSS tingkat lanjut.

Jadi selain metode Double Submit Cookies, Anda harus selalu mengikuti praktik terbaik terhadap XSS termasuk meng-escape konten. Ini berarti menghapus kode yang dapat dieksekusi yang akan menyebabkan browser melakukan sesuatu yang tidak Anda inginkan. Biasanya ini berarti menghapus // <! [CDATA [tag dan atribut HTML yang menyebabkan JavaScript dievaluasi.

— Iman Sedighi
sumber

12

Dapatkah Anda menjelaskan bagaimana JWT di cookie HttpOnly dapat diambil? Ini dapat digunakan oleh XSRF jika token XSRF dikompromikan oleh XSS, tetapi bisakah itu benar-benar diambil sendiri?

— Jacek Gorgoń

1

Saya tahu ini adalah posting lama, tetapi saya ingin mengajukan beberapa pertanyaan ... Apakah itu berarti skrip yang dibuat dengan baik dapat membaca localStorage dan cookie? Jika demikian, apakah aman untuk mengasumsikan bahwa JWT mungkin dapat dicuri di mana pun kami menyimpannya di browser? Lalu, saya merasa hanya mengandalkan JWT sangat berisiko.

— Hiroki

2

"Bahkan JWT Anda di cookie HttpOnly dapat diambil dengan serangan XSS tingkat lanjut." salah. Mengedit postingan asli untuk memperbaiki ini.

— java-addict301

"Bahkan JWT Anda di cookie HttpOnly dapat diambil oleh serangan XSS tingkat lanjut" Saya dapat membayangkan bahwa seseorang mengambil cookie dengan mengirimkannya ke servernya sendiri. Untuk itu dia bisa menggunakan fetch dengan nilai yang sesuai dari flag credentials. Masalah utama di sini adalah perlindungan CORS tetapi dalam beberapa keadaan saya pikir itu mungkin.

— bartnikiewi.cz

"menyuntikkan skrip yang membaca cookie CSRF Anda (yang bukan HttpOnly)" Implementasi default Html.AntiForgeryToken()di ASP.NET MVC menggunakan cookie HttpOnly untuk token CSRF. Saya pikir Anda masih rentan terhadap XSS tertentu, tetapi menurut saya ini layak untuk disebutkan.

— Lovethenakedgun

22

Sebuah posting tepat waktu dari Stormpath telah menjelaskan banyak poin saya dan menjawab pertanyaan saya.

TL; DR

Simpan JWT dalam cookie, lalu berikan JWT di header Otorisasi pada setiap permintaan seperti yang saya sebutkan, atau seperti yang disarankan artikel, andalkan backend untuk mencegah CSRF (misalnya, menggunakan xsrfTokendalam kasus Angular).

— pkid169
sumber

2

Halo, Saya tidak yakin apakah ini benar tetapi, apakah ada beberapa kerugian khusus menggunakan cookie untuk menyimpan jwt ketika Anda menerapkan CrossOrigin untuk pengontrol Anda, itu adalah adegan di mana aplikasi server saya terletak di tempat yang berbeda dan kami memanggil api dari itu di aplikasi klien kami yang terletak katakan di kota lain? Bukankah itu sebabnya banyak penyedia layanan web menahan diri dari menggunakan cookie?

— valik

CrossOrigin tidak berarti lokasi fisik. Ini mengacu pada permintaan yang datang dari domain lain. Dalam .net core ketika Anda memutuskan untuk menggunakan CORS, Anda menentukan domain mana yang akan Anda izinkan; header mana yang akan Anda izinkan, dll.

— Brian Allan West

12

Jangan simpan token Anda di LocalStorage atau SessionStorage, karena token tersebut dapat dibaca dari javascript dan oleh karena itu rentan terhadap serangan XSS.
Jangan simpan token Anda di Cookie. Cookie (dengan bendera HttpOnly) adalah opsi yang lebih baik - ini rentan terhadap XSS, tetapi rentan terhadap serangan CSRF

Sebagai gantinya, saat masuk, Anda dapat mengirimkan dua token: token akses dan token penyegaran. Token akses harus disimpan dalam memori Javascript dan token Segarkan harus disimpan di HttpOnly Cookie. Segarkan token hanya digunakan dan hanya untuk membuat token akses baru - tidak lebih.

Ketika pengguna membuka tab baru, atau pada penyegaran situs, Anda perlu melakukan permintaan untuk membuat token akses baru, berdasarkan token penyegaran yang disimpan dalam Cookie.

Saya juga sangat menyarankan untuk membaca artikel ini: https://hasura.io/blog/best-practices-of-using-jwt-with-graphql/

— devstructor
sumber

6

Mengapa kompleksitas bertambah ketika Anda hanya dapat memperlakukan token penyegaran sebagai token akses? Bagaimana pendekatan ini lebih secure diberikan saya tandai akses saya token sebagai secure, samesite: strict, http-only?

— Robot Tampan

tidak lebih aman

— Chris Hawkes

3

Untuk membantu mencegah serangan CSRF yang memanfaatkan cookie yang ada, Anda dapat mengatur cookie Anda dengan SameSitearahan. Setel ke laxatau strict.

Ini masih berupa draf dan pada 2019 tidak sepenuhnya didukung oleh semua browser saat ini , tetapi tergantung pada sensitivitas data Anda dan / atau kontrol Anda atas browser yang digunakan pengguna Anda, ini mungkin merupakan opsi yang layak. Menyetel direktif dengan SameSite=laxakan memungkinkan "navigasi tingkat atas yang menggunakan metode HTTP 'aman' ...".

— Ian Hunter
sumber