Стандарт для хранения сеансового ключа - PullRequest
Новая
       37

Стандарт для хранения сеансового ключа

0 голосов
/ 16 апреля 2020

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

1 Ответ

0 голосов
/ 17 апреля 2020

Есть только несколько мест, где вы можете хранить свои ключи в браузере:

  1. SessionStorage / LocalStorage
  2. Cookies
  3. Веб-работники
  4. в памяти

Cookies

Cookies - одно из лучших мест для хранения чувствительных ключей, если оно имеет правильные конфигурации / атрибуты с ними. Это включает, httpOnly, secure, SameSite, Domain и гарантию того, что они истекают в разумные сроки. подробнее читайте здесь о том, как правильно установить эти атрибуты.

Файлы cookie удобны в использовании, поскольку они так же безопасны, как HTTPS, и к ним нельзя получить доступ через javascript (если заданы правильные атрибуты, например, httpOnly). Но учтите, что все еще существуют уязвимости, которые вы должны остерегаться, например, атака CSRF, и вам придется включить токен CSRF, чтобы противостоять этой уязвимости, так как повар ie автоматически добавляется в заголовки браузером.

LocalStorage / SessionStorage

LocalStorage и хранилище сеансов - плохие места для хранения ключей, поскольку они доступны через javascript. Вы можете посмотреть здесь о том, как Auth0 рекомендует хранить ключи, и заметить, что они убеждают не хранить его в localStorage по указанным причинам.

В памяти

Вы можете сохранить введите javascript памяти (используйте закрытие для инкапсуляции вашего ключа). У этого есть недостаток, так как ключ не будет сохраняться после обновления / закрытия / новой вкладки и т. Д. c, но все еще довольно безопасен

Web Workers

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

Auth может быть сложным и может легко забыть включить что-то важное, поэтому убедитесь, что вы хорошо прочитали все атрибуты и то, как работает каждая часть. Или go с заранее заданными параметрами, такими как Auth0 или одиночное пение.

...