Я прочитал о защите сервисов на основе JWT на https://cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_for_Java_Cheat_Sheet.html. В этом руководстве рассказывается, как обрабатывать токен JWT на стороне клиента
Автоматически отправляется браузером (Cook ie хранилище).
- Получено даже при перезапуске браузера (использование контейнера localStorage в браузере).
- Получено в случае проблемы с XSS (Cook ie доступен для кода JavaScript или токена, хранящегося в локальном / сеансовом хранилище браузера).
Как предотвратить
Сохраните токен с помощью контейнера sessionStorage браузера. Добавить это в качестве заголовка Bearer HTTP Authentication с JavaScript при вызове служб.
Добавить информацию об отпечатке пальца в токен. Сохраняя токен в контейнере sessionStorage браузера, он предоставляет токен для украдены посредством XSS-атаки. Однако отпечатки пальцев добавились к токен предотвращает повторное использование украденного токена злоумышленником на своей машине. Чтобы закрыть максимум рабочих поверхностей для злоумышленник, добавьте политику безопасности содержимого браузера, чтобы усилить контекст выполнения.
Ограничение решения, предоставляемое OW ASP
Проблема в том, что если пользователь вводит тот же URL-адрес в другая вкладка в том же браузере, ему не должна быть представлена страница входа, вместо этого она должна быть направлена на домашний экран без какого-либо процесса входа в систему. Чтобы решить эту проблему . Я следовал приведенному ниже подходу. Кстати, я использую токен refre sh для поддержки скользящего сеанса
- Пользователь вводит имя пользователя и пароль для входа
- После проверки учетных данных для входа токен доступа сохраняется в не httponly, защищенный, samesite cook ie и токен refre sh хранятся в secure, samesite, httponly cook ie
- Значение отпечатка пальца добавляется с комбинацией другого пользовательского контекста, встроенного с информацией токена . Это значение cookie отпечатка пальца также хранится в защищенном, samesite, httponly cook ie и изменяется при каждом новом токене доступа, предоставляемом клиенту.
- Значение Fingerprint предназначено для предотвращения взлома токенов. Даже если токен доступа украден у повара ie. Злоумышленник не сможет использовать его, так как информация об отпечатке пальца отсутствует
- При каждом запросе клиенту браузера необходимо будет отправить токен доступа в качестве токена-носителя в заголовке, получив токен доступа, существующий в повар ie. Это служит одновременно механизмом предотвращения CSRF и механизмом аутентификации пользователя.
- Если срок действия токена истекает, браузер вызовет URL-адрес токена refre sh, а поскольку refre sh token cook ie уже присутствует , сервер автоматически получит токен refre sh и предоставит новый токен доступа и токен refre sh. и шаг 2 повторяется снова
Так безопасен ли этот подход? Так как применяются меры противодействия хищению токенов. должен ли я беспокоиться о хранении токена доступа в не httponly cook ie?
ПРИМЕЧАНИЕ. Причина, по которой я не храню и токен доступа, и токен refre sh в In-Memory javascript переменная, потому что этот токен должен использоваться несколькими приложениями, размещенными в одном домене.