Фиксация сессии VS XSRF / CSRF

Что определяет два соответственно?

Фиксация сессии описывается как:

Фиксация сеанса — это атака, которая позволяет злоумышленнику захватить действительный сеанс пользователя. Атака исследует ограничение в способе, которым веб-приложение управляет идентификатором сеанса, более конкретно, уязвимым веб-приложением.

Источник: OWASP

Который кажется довольно близким к тому, что эксплуатирует CSRF. Что отличает их друг от друга или Session fixation просто синоним или ответвление от CSRF?

Также хотелось бы отметить, что ключевая терминология, исходящая из предоставленной мной ссылки OWASP, практически идентична упомянутой в CSRF.

2

Решение

Нет, это не синоним. Фиксация сессии и CSRF — две разные атаки.

Фиксация сессии это класс Session Hijacking. Атакующий пытается украсть, угадать или исправить идентификатор сессии, затем использовать его и войти на целевой веб-сайт в качестве жертвы. Это можно сделать многими способами. Основная защита заключается в том, что если приложение использует флаг httpOnly, не передает идентификатор сеанса в URL (session.use_trans_sid = 0, session.use_only_cookies = 1) и заботится об уязвимостях XSS.

CSRF это другой вид атаки. Злоумышленник не хочет иметь идентификатор сеанса жертвы, а скорее заставляет жертву выполнить действие на сервере, где жертва правильно вошла в систему. Таким образом, жертва выполняет вредоносное действие сама, но не знает о нем. Как? Жертва загружает страницу где-нибудь, содержащую вредоносную ссылку в формате html (т.е. img src), или целевой веб-сайт содержит уязвимость XSS, и это хороший момент для загрузки внешнего вредоносного javascript и выдачи запросов ajax.

Стандартной защитой является токен CSRF. Это еще один токен (следующий за идентификатором сеанса), который включается в каждый секретный запрос. Злоумышленник не должен знать текущий токен CSRF для конкретного пользователя и не может подготовить вредоносную ссылку или запрос ajax. Маркер CSRF должен быть уникальным для каждого сеанса. Чувствительные запросы — это отправка формы, удаление / настройка чего-либо (разрешение и т. Д.). Таким образом, приложение не должно защищать абсолютно каждый запрос. Также не рекомендуется передавать токен CSRF в URL.

Посмотрите на OWASP для получения дополнительной информации в CSRF.

4

Другие решения

Других решений пока нет …

По вопросам рекламы [email protected]