Нужно ли хранить токены в файлах cookie, локальном хранилище или сеансе?

Попробуйте:

\ Q и \ E в качестве якорей

Поместите условие Or в соответствие с полным словом или регулярным выражением.

Ref Ссылка: Как совместить целое слово, которое включает специальные символы в регулярном выражении

8
задан Faris Dewantoro 18 January 2019 в 16:55
поделиться

3 ответа

Согласно моему опыту, просто хранят токен в localStorage.

localStorage :

может хранить информацию до 5 МБ. Вам не нужно спрашивать у пользователя разрешения на сохранение токена в localStorage.

Единственная проблема заключается в том, поддерживает ли целевое устройство API-интерфейс localStorage.

Проверьте здесь: https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage

Широко поддерживается. Но по моему опыту, если у вас есть приложение ios, и в этом приложении есть html-страница, которая просит пользователя сохранить токен (также называемый webview), API localStorage не может быть распознан и выдает ошибку.

Решение заключается в том, что я просто помещаю токен в URL и каждый раз передаю его. В веб-просмотре URL не виден.

Cookie:

Это очень старый стиль для хранения информации локально. Хранение в cookie относительно невелико, и вам необходимо запросить разрешение пользователя для сохранения токена в cookie.

Файлы cookie отправляются с каждым запросом, поэтому они могут ухудшить производительность (особенно для мобильных соединений для передачи данных). Современные API для клиентского хранилища - это API веб-хранилища (localStorage и sessionStorage) и IndexedDB. ( https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies )

Не хранить токен в sessionStorage или redux.

Данные, сохраненные в sessionStorage, будут потеряны, если вкладка закрыта. Если пользователь случайно закрыл вкладку, токен теряется, и сервер не сможет идентифицировать текущего пользователя. Токен, сохраненный в redux, не отличается от других js-файлов. Излишнее хранилище - это просто еще один JS-файл информация, сохраненная в избыточном коде, теряется при каждом обновлении страницы.

В заключение,

большую часть времени токен сохраняется в localStorage, если используется современный стиль. В определенных сценариях вы можете хранить токен в cookie и иногда помещать его в URL. Но никогда не храните в сессии.

Надеюсь, это поможет.

0
ответ дан MING WU 18 January 2019 в 16:55
поделиться

HTTP - это протокол без сохранения состояния. Прочтите этот ответ для более подробной информации, но по сути это означает, что HTTP-серверы, такие как ваш веб-сервер, не хранят никакой информации о клиентах после срока действия одного запроса. Это проблема для веб-приложений, потому что это означает, что вы не можете вспомнить, какой пользователь вошел в систему.

Куки были изобретены как решение этой проблемы. Cookies - это текстовые данные, которые клиент и сервер отправляют взад и вперед по каждому запросу. Они позволяют эффективно поддерживать данные о состоянии приложения, так как клиент и сервер договариваются о том, что они запоминают при каждом общении.

Это означает, по сути, , что вы не можете иметь сеанс без куки . должен быть файл cookie, в котором хранится как минимум идентификатор сеанса, чтобы вы могли узнать, какой пользователь в данный момент вошел в ваше приложение, просмотрев сеанс. Вот что делает express-session: документация для основного метода session явно отмечает, что идентификатор сеанса хранится в cookie.

, поэтому мой вопрос: нужно ли мне хранить куки? потому что я могу получить к ним доступ через req.sessionID, чтобы получить необходимые данные.

Вам не нужно хранить куки. Экспресс-сессия сделает это за вас. Ваше приложение в целом действительно должно хранить куки; без этого у вас не было бы req.sessionID, чтобы искать.

0
ответ дан Effective Robot 18 January 2019 в 16:55
поделиться

Этот ответ основан на подходе без сохранения состояния, и поэтому в нем не говорится о традиционном управлении сеансами

Вы задали два совершенно разных вопроса:

    [ 1125] Корзина покупок - которая больше относится к бизнес-функциям
  1. OAuth 2 & amp; JWT - который связан с безопасностью и аутентификацией

Как пользователь веб-сайта электронной коммерции, я ожидаю, что любой товар, который я добавлю в свою корзину для покупок со своего мобильного устройства во время поездок на рабочее место, должен быть доступным в корзине, когда я захожу на сайт с моего компьютера после достижения дома. Таким образом, данные корзины должны быть сохранены во внутренней БД и связаны с моей учетной записью.

Когда речь заходит об аутентификации с использованием OAuth 2.0, токен доступа JWT и / или токен обновления необходимо хранить где-то на клиентском устройстве, поэтому, когда пользователь аутентифицирует себя, предоставляя учетные данные для входа, ему не нужно предоставлять его учетные данные снова, чтобы перемещаться по сайту. В этом контексте локальное хранилище браузера, сессионное хранилище и файлы cookie являются допустимыми параметрами. Однако обратите внимание, что здесь файл cookie не связан ни с одним сеансом на стороне сервера. Другими словами, cookie не хранит идентификатор сессии. Файл cookie просто используется в качестве хранилища для токена доступа, который передается на сервер при каждом http-запросе, и затем сервер проверяет токен с помощью цифровой подписи, чтобы убедиться, что он не был подделан и срок его действия не истек.

Хотя все три варианта хранения для доступа и / или обновления токенов популярны, cookie-файл представляется наиболее безопасным вариантом при правильном использовании.

Чтобы лучше это понять, я рекомендую вам прочитать это и это вместе со спецификацией OAuth 2.0.

Обновление: 16 февраля 2019 г.

Ранее я говорил, что файлы cookie, похоже, являются наиболее безопасными вариантами. Я хотел бы уточнить это здесь.

Причина, по которой я думаю, что браузер localStorage и sessionStorage не обеспечивают достаточную безопасность для хранения токенов аутентификации, заключается в следующем:

  1. Если XSS возникает, вредоносный скрипт может легко прочитать токены оттуда и отправьте их на удаленный сервер. На удаленном сервере или злоумышленнике не возникнет проблем с выдачей себя за пользователя-жертву.

  2. localStorage и sessionStorage не являются общими для поддоменов. Таким образом, если у нас есть два SPA, работающих на разных поддоменах, мы не получим функцию единого входа, потому что токен, сохраненный одним приложением, не будет доступен для другого приложения в организации. Есть некоторые решения, использующие iframe, но они больше похожи на обходные пути, чем на хорошее решение. И когда заголовок ответа X-Frame-Options используется, чтобы избежать атак с использованием iframe кликджекинга, любое решение с iframe исключается.

Эти риски, однако, могут быть уменьшены путем использования отпечатка пальца (как упомянуто в Шпаргал OWASP JWT ), который, в свою очередь, также требует cookie.

Идея отпечатка пальца состоит в том, чтобы генерировать криптографически сильную случайную строку байтов. Строка Base64 необработанной строки будет затем сохранена в файле cookie HttpOnly, Secure, SameSite с префиксом имени __Secure-. Надлежащие значения для атрибутов домена и пути должны использоваться в соответствии с бизнес-требованиями. Хэш строки SHA256 также будет передан в заявке JWT. Таким образом, даже если атака XSS отправляет токен доступа JWT удаленному серверу, управляемому злоумышленником, он не может отправить исходную строку в файле cookie, и в результате сервер может отклонить запрос на основании отсутствия файла cookie. Файл cookie HttpOnly не может быть прочитан сценариями XSS.

Поэтому, даже когда мы используем localStorage и sessionStorage, мы должны использовать cookie, чтобы обеспечить его безопасность. Кроме того, мы добавляем ограничение субдомена, как упомянуто выше.

Теперь единственное беспокойство по поводу использования cookie для хранения JWT - это CSRF-атака. Поскольку мы используем cookie SameSite, CSRF смягчается, потому что межсайтовые запросы (AJAX или только через гиперссылки) невозможны. Если сайт используется в каком-либо старом браузере или некоторых других не очень популярных браузерах, которые не поддерживают cookie SameSite, мы все равно можем уменьшить CSRF, дополнительно используя файл cookie CSRF с криптографически сильным случайным значением, таким образом, что каждый запрос AJAX считывает cookie значение и добавьте значение cookie в пользовательский заголовок HTTP (за исключением запросов GET и HEAD, которые не должны изменять состояние). Поскольку CSRF не может читать что-либо из-за одной и той же политики происхождения и основан на использовании небезопасных методов HTTP, таких как POST, PUT и DELETE, этот файл CSRF уменьшит риск CSRF. Этот подход использования файла cookie CSRF используется всеми современными средами SPA. Угловой подход упоминается здесь , здесь .

Кроме того, поскольку cookie - это httpOnly и Secured, сценарий XSS не может его прочитать. Таким образом, XSS также смягчается.

Также стоит упомянуть, что внедрение XSS и сценариев может быть дополнительно уменьшено путем использования соответствующего content-security-policy заголовка ответа.

0
ответ дан Saptarshi Basu 18 January 2019 в 16:55
поделиться
Другие вопросы по тегам:

Похожие вопросы: