Вопрос: Где обычно хранятся токены? В чем разница между размещением токена в cookie и размещением его в localStorage и sessionStorage?
схема мышления
- Что такое токен?
- Место хранения токенов
- В чем разница между токеном, помещенным в cookie, localStorage и sessionStorage?
- Суммировать
1. Что такое токен?
Токен на самом деле представляет собой учетные данные для доступа к ресурсам.
Как правило, после того, как пользователь успешно войдет в систему с помощью имени пользователя и пароля, сервер подпишет учетные данные для входа в цифровую форму, а зашифрованная строка будет использоваться в качестве токена.
2. Место хранения токенов
Токен на самом деле представляет собой учетные данные для доступа к ресурсам.
Как правило, после того, как пользователь успешно войдет в систему с помощью имени пользователя и пароля, сервер подпишет учетные данные для входа в цифровую форму, а зашифрованная строка будет использоваться в качестве токена.
Он будет возвращен клиенту после успешного входа пользователя в систему.Клиент в основном сохраняет следующие способы:
- Хранится в localStorage, передается в фон как поле каждый раз, когда вызывается интерфейс
- Сохраните его в файле cookie и позвольте ему отправляться автоматически, но недостатком является то, что он не может быть междоменным.
- После получения он сохраняется в localStorage и помещается в поле Authorization заголовка HTTP-запроса каждый раз при вызове интерфейса.
Токены обычно хранятся в localStorage, cookie или sessionStorage на стороне клиента.
3. В чем разница между токеном, помещенным в cookie, localStorage и sessionStorage?
3.1 Хранить токен к LocalStorage или SessionStorage
Доступ к веб-хранилищу (localStorage/sessionStorage) можно получить через тот же провайдер домена Javascript. Это означает, что любой JavaScript, работающий на вашем веб-сайте, может получить доступ к веб-хранилищу и, следовательно, уязвим для XSS-атак. В частности, в проекте используется множество сторонних библиотек JavaScript.
Чтобы предотвратить XSS, обычно следует избегать и кодировать все ненадежные данные. Но это не предотвращает XSS на 100%. Например, мы импортируем чужой код в наше приложение с помощью CDN или какой-либо другой общедоступной библиотеки JavaScript и менеджера пакетов, такого как npm.
Что делать, если один из используемых вами сценариев был скомпрометирован? Вредоносный JavaScript может быть встроен на страницу, а веб-хранилище скомпрометировано. Эти типы XSS-атак могут заставить любое веб-хранилище посетить ваш сайт.
Именно поэтому многие организации не рекомендуют хранить какую-либо ценную или достоверную информацию в любом веб-хранилище в веб-хранилище. Сюда входят идентификаторы сеансов и токены. В качестве механизма хранения Web Storage не применяет никаких стандартов безопасности при передаче.
XSS-атака: межсайтовый скриптинг (сокращенно XSS) — это атака путем внедрения кода. Злоумышленники внедряют вредоносные скрипты на целевой веб-сайт для запуска в браузере пользователя. Используя эти вредоносные скрипты, злоумышленники могут получить конфиденциальную информацию о пользователе, такую как Cookie, SessionID и т. д., тем самым ставя под угрозу безопасность данных.
3.2 Хранение токена с помощью файлов cookie
преимущество:
- Вы можете указать httponly, чтобы предотвратить его чтение с помощью JavaScript, или вы можете указать secure, чтобы гарантировать, что токен передается только по HTTPS.
недостаток:
- Не соответствует лучшим практикам Restful.Лучшие практики отдыха
- Уязвим к атакам CSRF (Ref и Origin можно проверить на стороне сервера)
CSRF: подделка межсайтовых запросов, проще говоря, злоумышленник обманывает браузер пользователя с помощью некоторых технических средств, чтобы посетить веб-сайт, который он аутентифицировал, и выполнить некоторые операции (такие как: отправка электронных писем, отправка сообщений и даже операции с недвижимостью, такие как переводы ) и покупки). Поскольку браузер прошел аутентификацию, посещенный веб-сайт будет считаться реальной операцией пользователя и запущен. Это использует уязвимость в аутентификации пользователя в Интернете: простая функция аутентификации гарантирует, что запрос будет отправлен из браузера пользователя, но не гарантирует, что сам запрос был отправлен пользователем добровольно. CSRF не получает никакой информации о пользователе, он просто обманывает браузер пользователя, заставляя его действовать от имени пользователя.
Суммировать
Есть две точки зрения на то, существует ли токен в файлах cookie или в localStorage.
- Разработчики, поддерживающие файлы cookie, настоятельно не рекомендуют хранить конфиденциальную информацию (например, JWT) в localStorage, поскольку она не устойчива к XSS.
- Фракция, поддерживающая localStorage, считает, что, несмотря на различные преимущества localStorage, при надлежащей защите от XSS преимущества намного перевешивают риски.
Помещение его в файл cookie, кажется, все видит, кажется, «решает» (потому что все еще есть проблема XSS) одну проблему, но вводит другую проблему (CSRF)
localStorage обладает характеристиками большей гибкости, большего размера и естественной невосприимчивости к CSRF. Файлы cookie имеют ограниченное пространство, а половина JWT занимает больше байтов, и иногда вам нужно хранить более одного JWT.
Справочное чтение, которое не понимает, что такое JWT[Что такое] JWT
Убедитесь, что в вашем коде и в коде сторонних библиотек достаточно XSS-проверок, кроме того, храните токен в localStorage.
Перед лицом XSS, даже если ваш файл cookie httpOnly не может быть получен, хакер все равно может спровоцировать или сделать что-либо без ведома пользователя. запомнить! Код хакеров пользуется таким же доверием пользователей, как и ваш! Пока существует XSS, независимо от того, хранится ли информация в файле cookie или в localStorage, одинаково уязвима единственная разница — сложность ее получения. Уязвимости XSS сложно найти, потому что сайт не только построен на основе вашего собственного кода, но и сторонний код может уже иметь XSS.
Руководство по знаниям: