Токен сеанса в теле страницы

Question

Сценарий: При использовании кеша, такого как Varnish, JS можно использовать для обновления данных страницы, чтобы были доступны данные, специфичные для пользователя.Для этого требуется, чтобы запрос AJAX отправлял токен аутентификации, который был передан приложению JS при входе в систему и сохранен в хранилище сеансов браузера.На веб-сайте без лака сессионный cookie и токен xsrf доступны для каждого запроса, но они недоступны на странице с кэшированным лаком, поэтому возникает необходимость получить их при входе в систему и сохранить где-нибудь на время сеанса.JS не может получить доступ к содержимому зашифрованного куки-файла, поэтому маркер аутентификации сеанса должен быть передан в заголовке или теле ответа входа в систему, чтобы JS мог получить его, сохранить и вернуть при последующих запросах.Весь цикл происходит по https.

Вопросы:

1. Является ли сеанс пользователя более уязвимым, чем использование стандартных файлов cookie сеанса в среде без лака?
2. Является ли использование хранилища сеансов для хранения токена уязвимостью?
3. Есть ли лучшее решение?

Answer 1

Короче говоря, ваша установка великолепна.

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

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

Лучше всего хранить данные сеанса и токен XSRF в хранилище сеансов или локальном хранилище (в зависимости от варианта использования).

Является ли использование хранилища сеансов для хранения токена уязвимостью?

Нет, поскольку вы не сохраняете токен в cookie, тогда вам следуетgo.

Есть ли лучшее решение?

зависит от варианта использования.для сценария, который вы предоставили, это идеально.и было бы лучше, если бы вы отправили токен сеанса в теле запроса.например, как это реализует Оаут.
для аутентификации вы можете вернуть ответ в виде данных JSON с токеном сеанса и токеном xsrf для дальнейшего использования.