Чи слід зберігати JWT у localStorage чи cookie? [дублікат]

З метою захисту API REST за допомогою JWT, згідно з деякими матеріалами (наприклад, цим посібником та цим запитанням ), JWT може зберігатися як у localStorage, так і у файлах cookie . Виходячи з мого розуміння:

• localStorage піддається XSS і, як правило, не рекомендується зберігати в ній конфіденційну інформацію.
• За допомогою файлів cookie ми можемо застосувати позначку "httpOnly", яка зменшує ризик виникнення XSS. Однак якщо ми хочемо прочитати JWT з файлів cookie у серверній системі, тоді ми підлягаємо CSRF.

Отже, виходячи з вищезазначеної передумови - найкраще буде зберігати JWT у файлах cookie. На кожному запиті до сервера JWT буде зчитуватися з файлів cookie та додаватися до заголовка авторизації за допомогою схеми Bearer. Потім сервер може перевірити JWT у заголовку запиту (на відміну від читання його з файлів cookie).

Чи правильно розумію моє розуміння? Якщо так, то чи має вищезазначений підхід питання щодо безпеки? Або насправді ми можемо просто піти, використовуючи localStorage, насамперед?

Мені подобається метод подвійного надсилання файлів cookie XSRF, який згадується у статті, про яку сказав @ pkid169, але є одна річ, про яку ця стаття не розповідає. Ви все ще не захищені від XSS, оскільки зловмисник може ввести скрипт, який зчитує ваш файл cookie CSRF (який не є HttpOnly), а потім зробити запит до однієї з ваших кінцевих точок API, використовуючи цей маркер CSRF із автоматично переданим файлом cookie JWT.

Отже, насправді ви все ще сприйнятливі до XSS, просто зловмисник не може викрасти ваш токен JWT для подальшого використання, але він все одно може робити запити від імені вашого користувача за допомогою XSS.

Незалежно від того, чи зберігаєте ви свій JWT у локальному сховищі, чи зберігаєте свій маркер XSRF у файлі cookie, який не є лише http, обидва варіанти можуть бути легко схоплені XSS. Навіть ваш JWT у файлі cookie HttpOnly може бути захоплений розширеною атакою XSS.

Отже, окрім методу Double Submit Cookies, ви завжди повинні дотримуватися найкращих практик щодо XSS, включаючи екранований вміст. Це означає видалення будь-якого виконуваного коду, який змусив би браузер робити те, чого ви не хочете. Зазвичай це означає видалення тегів // <! [CDATA [та атрибутів HTML, які спричиняють оцінку JavaScript.

Своєчасна публікація від Stormpath майже повністю розробила мої зауваження та відповіла на моє запитання.

TL; DR

Зберігайте JWT у файлах cookie, а потім передайте JWT у заголовку авторизації на кожен запит, як я вже згадував, або, як пропонується в статті, покладайтеся на серверну інформацію, щоб запобігти CSRF (наприклад, використовувати xsrfTokenу випадку Angular).

• Не зберігайте свій маркер у LocalStorage або SessionStorage, оскільки такий маркер можна прочитати з javascript, і тому він вразливий для атаки XSS.
• Не зберігайте свій маркер у файлі cookie. Файл cookie (з позначкою HttpOnly) є кращим варіантом - він схильний до XSS, але це вразливо для атак CSRF

Натомість при вході ви можете доставити два маркери: маркер доступу та маркер оновлення. Маркер доступу повинен зберігатися в пам'яті Javascript, а маркер оновлення - у файлі cookie HttpOnly. Маркер оновлення використовується лише і лише для створення нових маркерів доступу - не більше того.

Коли користувач відкриває нову вкладку або під час оновлення сайту, вам потрібно виконати запит на створення нового маркера доступу на основі маркера оновлення, який зберігається в файлі cookie.

Я також настійно рекомендую прочитати цю статтю: https://hasura.io/blog/best-practices-of-using-jwt-with-graphql/

Щоб запобігти атакам CSRF, які використовують переваги існуючих файлів cookie, ви можете встановити свій файл cookie відповідно до SameSiteдирективи. Встановіть на laxабо strict.

Це все ще проект, і станом на 2019 рік не повністю підтримується всіма поточними браузерами , але залежно від чутливості ваших даних та / або вашого контролю над браузерами, якими користуються ваші користувачі, це може бути життєздатним варіантом. Встановлення директиви за допомогою SameSite=laxдозволить "навігації верхнього рівня, які використовують" безпечний "... HTTP-метод."