Я новичок в веб-разработке и пытаюсь уловить проблемы безопасности. Я просмотрел эту статью по адресу http://guides.rubyonrails.org/security.html. Вот некоторые из шагов, которые автор упомянул о том, как атакующий фиксирует сеанс.фиксация сеанса
- Атакующий создает действительный идентификатор сессии: он загружает страницу авторизации веб-приложения, где он хочет исправить сессию, и принимает идентификатор сессии в куки от ответа (см номер 1 и 2 в образ).
- Возможно, он поддерживает сеанс. Длительные сеансы, например каждые 20 минут, значительно сокращают сроки атаки. Поэтому он время от времени обращается к веб-приложению, чтобы сохранить сеанс.
- Теперь злоумышленник заставит браузер пользователя использовать этот идентификатор сеанса (см. Номер 3 на изображении). Поскольку вы не можете изменить файл cookie другого домена (из-за той же политики происхождения), злоумышленник должен запустить JavaScript из домена целевого веб-приложения. Внедрение JavaScript-кода в приложение XSS выполняет эту атаку. Вот пример: <script> document.cookie = "_ session_id = 16d5b78abb28e3d6206b60f22a03c8d9"; </скрипт >. Подробнее о XSS и инъекции позже.
- Злоумышленник заманивает жертву на зараженную страницу кодом JavaScript. Просмотрев страницу, браузер жертвы изменит идентификатор сеанса на идентификатор сеанса trap.
- Поскольку новый сеанс ловушки не используется, веб-приложение потребует аутентификации пользователя.
- С этого момента жертва и злоумышленник будут совместно использовать веб-приложение с тем же сеансом: сеанс стал действительным, и жертва не заметила атаки.
Я не понимаю пару пунктов.
- Почему пользователь вводит логин на этапе5, поскольку сеанс отправляется через?
- Я видел возможные решения на вики, такие как проверка свойств пользователей и другие. Почему мы не можем просто сбросить сеанс для пользователя, который входит в систему, когда они вводят имя пользователя и пароль на шаге 5?