Безопасность хранения токена на предъявителя в куки - PullRequest
0 голосов
/ 30 сентября 2018

Мой SPA использует React в качестве внешнего интерфейса и laravel API в качестве внутреннего.

Когда пользователь входит в систему (через axios и api), api возвращает доступ (токен Bearer) в качестве ответа.Я использую фреймворк реагирования на cookie-файлы для хранения токена доступа в виде cookie-файлов в браузере.Этот файл cookie будет прочитан и использован для любого будущего запроса.

Это правильный способ сделать?Разве данные cookie не являются чем-то простым в браузере, что может быть легко получено любым злоумышленником?Так как это всего лишь файл одного компьютера где-то.

Что мешает злоумышленнику захватить этот файл cookie, выдать себя за пользователя и начать выполнять действия, требующие аутентификации?

Срок действия токена составляет, скажем, 1 год.Он будет обновляться только каждый раз, когда пользователь входит в систему. Я понимаю, что если я укорачиваю срок службы, он будет более безопасным.Однако это будет означать, что пользователю придется постоянно входить в систему?

----- Обновление -----

Я не уверен, что какое-либо из предложенных решений ответило на мой вопрос.Приложение SPA основано на внешнем интерфейсе, и запрос может быть получен из любого места, такого как Почтальон, Мобильное приложение или любое стороннее устройство, которое хочет общаться с моим сервером.Таким образом, этим устройствам необходим способ локального хранения некоторого токена доступа, который будет использоваться для любого будущего запроса.

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

В этом случае Imне уверен, что токен CSRF или другие средства могут помочь мне?

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

Ответы [ 2 ]

0 голосов
/ 22 октября 2018

Я просто хочу добавить некоторые недостатки хранения токенов в файлах cookie, о которых вам также следует знать:

  • Максимальный размер файла cookie составляет всего 4 КБ, поэтому это может вызвать проблемы, еслик токену прикреплено много претензий.

  • Файлы cookie могут быть уязвимы для атак подделки межсайтовых запросов (CSRF или XSRF).Использование защиты CSRF каркаса веб-приложения делает куки безопасным вариантом для хранения JWT.CSRF также можно частично предотвратить, проверив заголовок HTTP Referer и Origin.Вы также можете установить флаг cookie SameSite = строгий для предотвращения CSRF-атак.

  • Может быть сложно реализовать, если приложению требуется междоменный доступ.Куки имеют дополнительные свойства (Домен / Путь), которые можно изменить, чтобы указать, куда разрешено отправлять куки.

------- Update ----

Вы также можете использовать куки для хранения токена авторизации, даже если он лучше (по крайней мере, на мой взгляд, чем использование локального хранилища или некоторого промежуточного программного обеспечения сеанса, такого как Redis).И есть несколько различных способов управления временем жизни куки, если мы оставим в стороне флаги httpOnly и secure:

  • Cookies могут быть уничтожены после закрытия браузера (сеансовые куки).
  • Внедрите проверку на стороне сервера (обычно выполняемую для вас используемой веб-платформой), и вы можете реализовать срок действия или срок действия скользящего окна.
  • Файлы cookie могут быть постоянными (не уничтожаться после закрытия браузера) с истечением срока действия.
0 голосов
/ 18 октября 2018

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

В файле cookie установлен флаг HttpOnly , тогда JS не будетможет получить к нему доступ, но он все равно будет отправлен с любым запросом.

Флаг SameSite обеспечит отправку cookie только на сайт, который предоставил его вам.Что предотвращает утечку.

Флаг Secure позволяет отправлять куки-файлы только через защищенное соединение, чтобы никто не перехватывал их в вашем веб-трафике.

Редактировать

Возможно, вы захотите посмотреть рабочий процесс авторизации, но суть его такова:

  1. Пользователь входит в систему с именем пользователя и паролем
  2. AВеб-токен JSON выдается при входе из бэкэнда и отправляется в браузер
  3. JWT (веб-токен JSON) можно сохранить в файле cookie в веб-хранилище (локальном / хранилище сеансов) в браузере
  4. В последующих запросах к REST API токен будет встроен в заголовок или строку запроса для авторизации.С помощью этой формы авторизации ваш REST API понимает, кто делает запрос и какой ресурс возвращать, основываясь на уровне авторизации

Пожалуйста, смотрите ответ @tpopov, так как он также сделал несколько действительно хороших замечаний..

...