#angular #security #browser #single-page-application
Вопрос:
При выходе из системы наше одностраничное приложение очищает локальное хранилище и т. Д. Затем он загружает компонент выхода из системы, который информирует пользователя о том, что он вышел из системы.
Однако время от времени мы вносим утечки памяти в наше приложение, и переменные в памяти остаются дольше, чем должны (мы исправляем эти утечки памяти, когда обнаруживаем их, но не всегда можем быть уверены, что удалили их все. Мы используем Angular, поэтому наиболее распространенной проблемой является то, что службы, внедренные в корневую систему, все еще работают, даже когда мы перенаправляем их на страницу выхода из системы).
Нас беспокоит этот сценарий:
- Аутентифицированный/авторизованный пользователь A использует общий компьютер для получения данных с нашего сервера, которые он просматривает в СПА-салоне
- Пользователь А выходит из приложения, оставляя окно браузера открытым
- Используя все еще открытый браузер, злоумышленник B использует средства разработки браузера для установки точек останова и проверки переменных, не собранных с мусора, которые содержат данные с сервера, которые пользователь A уже получил, и которые пользователь B не имеет права просматривать.
Является ли этот сценарий действительной проблемой безопасности или он выходит за рамки SPA, поскольку другой пользователь имеет физический доступ к машине (chrome считает, что физический доступ выходит за рамки)?
И если это действительно проблема, достаточно ли обновления или перенаправления при выходе из системы, чтобы смягчить ее?
Комментарии:
1. Я думаю, что это не проблема со СПА, это маркер сеанса, который должен быть признан недействительным при выходе из системы. Все, что осталось в СПА-салоне после выхода из системы, не должно иметь возможности получать ресурсы с сервера.
2. Если
On logout, our single page application clears local storage, etc.и токен/значения признаны недействительными, какие значения доступны для чтения в пункте #3? Использует ли пользователь 1 и пользователь 2 одни и те же учетные данные? Проверяет ли API токен при каждом запросе и гарантирует ли вошедший в систему пользователь необходимые разрешения?3. @AlexanderStaroselsky, проблема не в том, что пользователь B может снова получить доступ к API (мы действительно аннулируем токены сеанса). Проблема в том, что пользователь B может использовать средства разработки браузера, например, для установки точек останова и проверки переменных, которые все еще могут содержать некоторые данные, которые пользователь A уже получил с сервера.