сохранение токена аутентификации в cookie (Django Rest Framework + React) - PullRequest
0 голосов
/ 02 июля 2018

Итак, как видно из названия, я использую Django Rest Framework в сочетании с React.

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

Я думал о том, чтобы сохранить токен в cookie, но это не очень безопасно.

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

Итак, мой вопрос: верно ли мое предположение, что хранить мой токен аутентификации в cookie-файле небезопасно?

Примечание: Я думаю о переходе на аутентификацию на основе сеанса, но я бы предпочел сохранить мне работу и сохранить аутентификацию токена.

Ответы [ 2 ]

0 голосов
/ 14 августа 2018

Какой следующий подход: хранить не токен, а refresh_token как в OAuth https://auth0.com/docs/tokens/refresh-token/current?

Вы должны принять решение о том, какие тайм-ауты оставить для вашей безопасности, поэтому каждый раз, когда токен умирает или становится пустым, вы можете попытаться восстановить сеанс refresh_token, который хранится в куки

Даже если потенциальный взломщик получит refresh_token после тайм-аута const, это не имеет смысла

0 голосов
/ 14 августа 2018

Это то, с чем мне пришлось иметь дело. Потерял несколько ночей сна в процессе.

Отказ от ответственности: я не специалист по безопасности. Просто немного одержим (читай: параноик).

Короткая версия (для ответа на ваш вопрос): Я, наконец, в конечном итоге использовал window.localStorage для хранения токена. Хотя я и сам не убежден, что это лучше всего сделать, но речь идет не только о «хранении» - прочитайте длинную версию, чтобы понять больше.

Длинная версия: Во-первых, давайте уточним несколько вещей. React больше похож на мобильное приложение, чем на веб-страницу / веб-сайт. Я не говорю о React Native - я имею в виду React.js .

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

В мобильном приложении (или автономном приложении на стороне клиента) вам необходимо сохранить какой-то токен, чтобы по существу сказать серверу: «Привет, это я! Я недавно побывал. Вот мое удостоверение личности. пожалуйста?". Проблема в том, что сложно сохранить токен на стороне клиента. Сам Android не предоставлял никакого безопасного способа хранения токена аутентификации до Android v4.3. Это тоже не было достаточно безопасно, поэтому они недавно представили аппаратное хранилище ключей. По этой причине некоторые приложения не работают (и до сих пор не работают) с корневыми устройствами. Подробнее об этом здесь: https://stackoverflow.com/a/19669719/3341737

По сравнению с автономным веб-приложением React, Google (в некоторой степени) контролирует клиентскую часть Android. Им сравнительно легче реализовать аппаратное хранилище ключей. В случае с веб-приложением существует множество браузеров с сотнями версий и так далее.

Возвращаясь к window.localStorage. Как и Cookies, localStorage изолирован для каждого домена. Поскольку это более новый API, он разработан лучше, чем старые добрые Cookies.

Нет смысла шифровать ключ (хотя вы можете его запутать), поскольку вам также необходимо хранить ключ дешифрования где-то локально. Поэтому, если кто-то может получить доступ к токену, он также может получить доступ к ключу расшифровки.

Второй аспект этой проблемы (и почему «хранение» - не единственная проблема) - от кого вы действительно хотите защитить токен?

  1. Человек посередине? Используйте SSL.
  2. Другие сайты? Они не могут получить доступ к localStorage вашего домена.
  3. Какой-то человек? Правда. Они могут легко получить токен, если у них есть физический доступ к ПК. Наличие физического доступа практически делает их пользователем (вы хотите защитить токен от пользователя?). Учитывая, что у человека есть физический доступ, вы не можете защитить токен, даже если каким-то образом его надежно храните.

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

Почему не Cookie? Две причины (1 на самом деле):

  1. Cookie отправляется с каждым запросом по умолчанию. Вам это действительно не нужно, потому что вам нужно отправлять токен только во время вызовов API (не при загрузке страницы). Кроме того, поскольку вы используете DRF (применимо к любому бэкэнду API RESTful), вам, вероятно, нужно отправить токен - это особый путь на сервер, который в любом случае требует специального метода.
  2. window.localStorage - это аккуратный API для работы (просто window.localStorage.setItem('key', 'value')). Кроме того, ограничение максимального размера намного выше по сравнению с файлами cookie.

Таким образом, window.localStorage кажется мне подходящим вариантом. Просветите меня, если у вас есть лучшее решение.

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

  1. Отменить / удалить токен из БД по истечении определенного периода времени или после определенного периода бездействия.
  2. Отправьте обновленный токен (также лишите законной силы предыдущий) с запросами достаточно случайно и замените сохраненный токен новым.
  3. Предоставьте пользователю доступ к удалению сохраненных токенов их учетной записи вместе с последней активностью каждого токена.
  4. Если вы действительно (действительно) обеспокоены, свяжите токен с IP-адресом пользователя (или чем-то еще, что не может быть клонировано в другой системе). Если пользователь входит в систему с нового устройства / местоположения / браузера, используйте 2FA.
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...