Как стать автором
Обновить

Комментарии 3

Зря первый вариант пометили как абстрактный. Видел много сервисов для внутрикорпоративного использования, которые не видны снаружи, и при этом уязвимы для CSRF-атак.

Очень плохо, что статья только запугивает некими последствиями, но никаких намёков на механизмы, реализующие эти последствия не даёт.

Где технический сценарий атаки? Если есть его понимание, то описать его не составляет труда. Но ничего подобного в статье нет. Но есть нагнетание страха. Или просто — манипуляция.

Сценарий мог бы выглядеть так:

Пользователь открывает другую вкладку, адрес которой смотрит на сервер злоумышленника. Вкладка грузит страницу злоумышленника. Страница содержит фрейм с src, указывающим на сайт в первой вкладке. Получаем произвольный get-запрос с идентификатором сессии, но выполненный злоумышленником.

Коротко? Автор был на такую краткость неспособен? Автора, как всегда, ограничивал «доступный объём статьи»? Или ещё какие отмазки придумаем?

А вот если сценарий присутствует, то и методы защиты становятся очевидными. Простейшее средство — не открывайте новые вкладки и окна во время раборты с деньгами. Даже идиоты это поймут. Но автор не пожелал подсказать им о таком простом средстве. Предпочёл запугивать.

В итоге имеем уровень домохозяек поданный как нечто «научно обоснованное».

Люди, не будьте идиотами, не ведитесь на бездоказательные и убогие статейки, а то ведь так всю жизнь не только в наморднике ходить будете, но и с ошейником, а так же с зондом в заднице.

Статья вообще-то для тех, кто веб-приложения делает, а не для пользователей.


И меры защиты от такого известны уже давным-давно: либо случайный токен в параметрах запроса и его копия в куках или в сессии, либо авторизация вообще без использования кук.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий