Изменение частоты истечения объекта кэша ASP.NET?

Этот ответ основан на подходе без сохранения состояния, и поэтому в нем не говорится о традиционном управлении сеансами

Вы задали два совершенно разных вопроса:

[ 1125] Корзина покупок - которая больше относится к бизнес-функциям
2. OAuth 2 & amp; JWT - который связан с безопасностью и аутентификацией

Как пользователь веб-сайта электронной коммерции, я ожидаю, что любой товар, который я добавлю в свою корзину для покупок со своего мобильного устройства во время поездок на рабочее место, должен быть доступным в корзине, когда я захожу на сайт с моего компьютера после достижения дома. Таким образом, данные корзины должны быть сохранены во внутренней БД и связаны с моей учетной записью.

Когда речь заходит об аутентификации с использованием OAuth 2.0, токен доступа JWT и / или токен обновления необходимо хранить где-то на клиентском устройстве, поэтому, когда пользователь аутентифицирует себя, предоставляя учетные данные для входа, ему не нужно предоставлять его учетные данные снова, чтобы перемещаться по сайту. В этом контексте локальное хранилище браузера, сессионное хранилище и файлы cookie являются допустимыми параметрами. Однако обратите внимание, что здесь файл cookie не связан ни с одним сеансом на стороне сервера. Другими словами, cookie не хранит идентификатор сессии. Файл cookie просто используется в качестве хранилища для токена доступа, который передается на сервер при каждом http-запросе, и затем сервер проверяет токен с помощью цифровой подписи, чтобы убедиться, что он не был подделан и срок его действия не истек.

Хотя все три варианта хранения для доступа и / или обновления токенов популярны, cookie-файл представляется наиболее безопасным вариантом при правильном использовании.

Чтобы лучше это понять, я рекомендую вам прочитать это и это вместе со спецификацией OAuth 2.0.

Обновление: 16 февраля 2019 г.

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

Причина, по которой я думаю, что браузер localStorage и sessionStorage не обеспечивают достаточную безопасность для хранения токенов аутентификации, заключается в следующем:

1. Если XSS возникает, вредоносный скрипт может легко прочитать токены оттуда и отправьте их на удаленный сервер. На удаленном сервере или злоумышленнике не возникнет проблем с выдачей себя за пользователя-жертву.

2. localStorage и sessionStorage не являются общими для поддоменов. Таким образом, если у нас есть два SPA, работающих на разных поддоменах, мы не получим функцию единого входа, потому что токен, сохраненный одним приложением, не будет доступен для другого приложения в организации. Есть некоторые решения, использующие iframe, но они больше похожи на обходные пути, чем на хорошее решение. И когда заголовок ответа X-Frame-Options используется, чтобы избежать атак с использованием iframe кликджекинга, любое решение с iframe исключается.

Эти риски, однако, могут быть уменьшены путем использования отпечатка пальца (как упомянуто в Шпаргал OWASP JWT ), который, в свою очередь, также требует cookie.

Идея отпечатка пальца состоит в том, чтобы генерировать криптографически сильную случайную строку байтов. Строка Base64 необработанной строки будет затем сохранена в файле cookie HttpOnly, Secure, SameSite с префиксом имени __Secure-. Надлежащие значения для атрибутов домена и пути должны использоваться в соответствии с бизнес-требованиями. Хэш строки SHA256 также будет передан в заявке JWT. Таким образом, даже если атака XSS отправляет токен доступа JWT удаленному серверу, управляемому злоумышленником, он не может отправить исходную строку в файле cookie, и в результате сервер может отклонить запрос на основании отсутствия файла cookie. Файл cookie HttpOnly не может быть прочитан сценариями XSS.

Поэтому, даже когда мы используем localStorage и sessionStorage, мы должны использовать cookie, чтобы обеспечить его безопасность. Кроме того, мы добавляем ограничение субдомена, как упомянуто выше.

Теперь единственное беспокойство по поводу использования cookie для хранения JWT - это CSRF-атака. Поскольку мы используем cookie SameSite, CSRF смягчается, потому что межсайтовые запросы (AJAX или только через гиперссылки) невозможны. Если сайт используется в каком-либо старом браузере или некоторых других не очень популярных браузерах, которые не поддерживают cookie SameSite, мы все равно можем уменьшить CSRF, дополнительно используя файл cookie CSRF с криптографически сильным случайным значением, таким образом, что каждый запрос AJAX считывает cookie значение и добавьте значение cookie в пользовательский заголовок HTTP (за исключением запросов GET и HEAD, которые не должны изменять состояние). Поскольку CSRF не может читать что-либо из-за одной и той же политики происхождения и основан на использовании небезопасных методов HTTP, таких как POST, PUT и DELETE, этот файл CSRF уменьшит риск CSRF. Этот подход использования файла cookie CSRF используется всеми современными средами SPA. Угловой подход упоминается здесь , здесь .

Кроме того, поскольку cookie - это httpOnly и Secured, сценарий XSS не может его прочитать. Таким образом, XSS также смягчается.

Также стоит упомянуть, что внедрение XSS и сценариев может быть дополнительно уменьшено путем использования соответствующего content-security-policy заголовка ответа.