Наша аудиторская компания проводит аудит внешней защиты, и в первом отчете об уязвимости говорится, что у нас возникла проблема с сохранением идентификатора сеанса в кэше веб-браузера.
В отчете указано следующее:
Уязвимость :
M-001: неполный контроль кэша или его отсутствие и прагма HTTP
Описание воздействия:
Обнаружена проблема безопасности, которая даже после закрытия сеанса позволяет получить доступ к частным или конфиденциальным данным, которыми обмениваются в сеансе, через кеш веб-браузера.Поэтому веб-приложения должны использовать ограничивающие политики кэширования для всего веб-трафика, передаваемого по HTTP и HTTPS, такие как заголовки HTTP «Cache-Control: no-cache, no-store» y «Pragma: no-cache» [5].и / или эквивалентные мета-теги на всех или (по крайней мере) конфиденциальных веб-страницах.
Рекомендации :
Рекомендуется независимо отПолитика кэширования определяется веб-приложением, что если разрешено хранение в кеше веб-приложения, сеанс ID никогда не должен храниться в кеше, поэтому настоятельно рекомендуется использовать набор файлов cookie "Cache-Control: no-cache =».-Directive "Cookie2" ", чтобы позволить веб-клиентам кэшировать все, кроме идентификатора сеанса."
На следующем изображении вы можете увидеть, что вы получаете при выполнении запроса к платформе через терминал:
Наша платформа разработана на Ruby on Rails версии 5.0.2, размещена на Amazon Web Services, и мы используем Devise в качестве инструмента аутентификации.
Рекомендация компании говорит нам о необходимости реализации директивы Cookie2, но мы читали, что эта директива устарела.
Нам не удалось эффективно решить проблему идентификатора сеанса вкуки и в кеше браузера.В настоящее время Devise автоматически меняет de session_id в каждом запросе к приложению на случайное значение.
Разве этого сброса session_id недостаточно для атаки на указанную уязвимость?Каково общее действие против session_id, сохраняемого в кэше?