Представим ситуацию, у нас реализуется web-приложение с stateless сессиями — с использованием accessToken. Пользователь проходит аутентификацию, и backend-сервер выпускает accessToken и передает его клиенту.
Классический вопрос: «Где хранить accessToken на клиенте?».

Если JS-коду не нужно взаимодействовать с токеном, то единственным безопасным вариантом является хранение токена в Cookie с атрибутами HttpOnly, SameSite, Secure. Однако, как быть, если такая необходимость есть? Хранить токен в localStorage?

😏Чем плохо такое решение? Если хранить accessToken в localStorage, то при XSS у злоумышленника будет доступ к хранилищу браузера, и токен может быть украден.

На практике мне встречалась реализация, где разработчики и рыбку съели и токен хранили в Cookie, и подставляли его в HTTP Header через JS.
Как? Всё просто — они реализовали API, который возвращает в теле ответа все Cookie, которые передавались в HTTP запросе. JS-код брал токен из ответа и подставлял в HTTP заголовок Bearer для следующего запроса. По сути это обход защиты атрибута HttpOnly.

😏Чем плох этот вариант? Помимо XSS, при небезопасной конфигурации CORS, злоумышленник сможет получить токен жертвы из ответа сервера, заманив ее на подконтрольный ресурс.

Существует еще одно решение — хранить токен в переменной JS и обернуть его в замыкание. Однако у злоумышленника останется возможность влиять на контекст выполнения. Поэтому, более безопасный метод - предотвратить вмешательство с помощью XSS в среду выполнения, которая имеет токен, достигая изоляции контекста. В веб-фронтенде это можно сделать с помощью Web Workers.

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

Идея заключается в том, чтобы поместить все запросы API в рабочий поток. Благодаря изоляции среды выполнения, если в рабочем потоке нет XSS, основной поток не может вмешаться в рабочего и не может получить доступ к его данным. Это обеспечивает безопасность токена.

Web Worker делится на три вида:
• Dedicated workers: используется только одним скриптом
• Shared workers: может использоваться несколькими скриптами в разных окнах/фреймах.
• Service Workers: выполняет роль прокси-сервера для взаимодействия между веб-приложением, браузером и сетью.

🔍 В этой статье описывается пример использование Dedicated Worker и обоснование отказа от Service Worker.

🔍 В этой статье, напротив, используется Service Worker + описываются другие примеры использования «прослойки» между фронтом и беком. Например, в кейсе, который я описывал выше (с API, которая возвращает Cookie в ответе), можно было бы использовать прокси на бэке, отказавшись вовсе от работы JS-кода с токеном в браузере пользователя.

Не одним htb едины

Гонял тут меня недавно один крутой АппСек на собеседовании по антипаттернам в коде, которые могут привести к эксплуатации типовых уязвимостей в продакшене. Психика конечно пострадала (не только моя), но зато потом я сел и начал искать способы тренировки этого навыка. А то кажется, что делать это вдали от реального Git-а и SAST-а не так уж и просто. И я нашел.

В общем, это почти как Hack The Box или Try Hack Me, но для АппСек-ов. Заходим, выбираем челлендж и ищем уязвимости в коде. А вот и сам сервис – ссылка

#AppSec

🧠 Твой Пакет Знаний | 👨‍🏫 Менторство ИБ
📂 Другие каналы