Безопасность
CSRF: тест с выбором ответа
Суть Тест с выбором на синтез по всему юниту — ambient authority, бреши SameSite, побочные эффекты на GET, токен-паттерны, проверка Origin и почему CORS — не защита от CSRF.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов поперёк всего юнита. Каждый отражает решение, которое ты принимаешь, ревьюя реальный дизайн аутентификации — не определение для заучивания, а компромисс, который надо взвесить, когда эндпоинт меняет состояние.
Цель
Убедись, что связываешь ambient authority, намеренные бреши SameSite, токен-паттерны и проверки Origin — тот синтез, к которому вёл урок, и ловушку, когда CORS принимают за защиту от CSRF.
Викторина
Completed
Ревьюер заявляет: «наша сессионная кука HttpOnly и Secure, значит, мы защищены от CSRF». Почему это рассуждение неверно?
Heads-up HttpOnly жив и полезен — но против кражи куки через XSS, это другой класс атак. Рассуждение неверно потому, что CSRF вообще не нужно читать куку.
Heads-up HttpOnly управляет доступом JavaScript к значению куки, а не тем, прикрепит ли её браузер к запросу. Браузер всё равно отправляет её кросс-сайтово; это и есть ambient authority, на которой едет CSRF.
Heads-up Secure лишь заставляет куку идти по HTTPS. Подделанный запрос тоже идёт по HTTPS, с прикреплённой кукой. Шифрование транспорта ортогонально CSRF.
Викторина
Completed
Сессионные куки — SameSite=Lax. Скрытая форма на evil.com авто-сабмитит кросс-сайтовый POST /transfer. Что произойдёт и какой эндпоинт реально остаётся уязвим?
Heads-up Lax как раз снимает куку с кросс-сайтовых POST-подзапросов; это его главный выигрыш. Остаётся уязвимым изменение состояния через GET на top-level навигации, а не POST.
Heads-up Lax — это не Strict. Он намеренно шлёт куку на top-level навигациях безопасными методами, так что GET, меняющий состояние, всё ещё подделываем через переход по ссылке.
Heads-up Lax оставляет три бреши: побочные эффекты на GET, куки SameSite=None и окно default-Lax 120с Lax+POST. Это defense-in-depth, никогда не единственный замок.
Викторина
Completed
Почему «никогда не меняй состояние на GET-запросе» — реальное правило безопасности, а не просто вкусовщина REST?
Heads-up Производительность тут ни при чём. Суть в том, что Lax всё равно прикрепляет куку к top-level GET-навигациям, так что мутирующий GET напрямую подделываем через CSRF.
Heads-up Кэширование — про корректность, а не про безопасность. Реальная проблема в том, что побочный эффект на GET достижим подделанной top-level навигацией, несущей Lax-куку.
Heads-up На практике GET-эндпоинты регулярно освобождают от проверки токена, и их триггерят обычные ссылки и теги изображений. Держать мутации вне GET закрывает самый дешёвый вектор CSRF до любой токен-логики.
Викторина
Completed
Stateless JSON API использует обычный double-submit cookie: случайное значение в куке, которое надо эхом вернуть в заголовке. Атакующий контролирует поддомен с XSS. Почему он обходит защиту и какой фикс?
Heads-up Double-submit действительно stateless — в этом его прелесть. Слабость в том, что он предполагает, будто атакующий не может писать твои куки; XSS на поддомене или cookie injection ломают это допущение.
Heads-up Same-origin policy запрещает кросс-сайтовое чтение твоих заголовков и значения куки. Здесь брешь — записываемость куки через поддомен, а не читаемость.
Heads-up HMAC-подписанный double-submit привязывает токен к сессии, так что подставленное значение не пройдёт валидацию, сохраняя паттерн stateless. Synchronizer token (stateful) сильнее, но не единственный вариант.
Викторина
Completed
Команда добавляет строгую CORS-политику (никаких чужих origin) и делает вывод, что её эндпоинты с изменением состояния теперь защищены от CSRF. Где рассуждение ломается?
Heads-up CORS не блокирует отправку или выполнение запросов; он контролирует выдачу ответа скрипту браузером. Подделанная запись всё равно проходит. CORS — не защита от CSRF.
Heads-up CORS применяется ко всем методам, но во всех случаях он гейтит читаемость ответа, а не выполнение запроса. Мутация происходит до того, как CORS начинает играть роль.
Heads-up Preflight срабатывает только для непростых запросов. Простые запросы и top-level POST-формы пропускают его целиком и выполняют побочный эффект — именно поэтому CORS не может быть защитой от CSRF.
Викторина
Completed
Атакующий логинит браузер жертвы в АККАУНТ АТАКУЮЩЕГО (login CSRF), и дальнейшая активность жертвы пишется под личностью атакующего. Какая защита это закрывает и почему обычное рассуждение неполно?
Heads-up Он не безвреден: жертва затем вводит данные, платёжные реквизиты или историю, которые попадают в аккаунт атакующего, где он позже их прочтёт. Login CSRF — реальная именованная угроза.
Heads-up SameSite управляет сессионной кукой, но login CSRF подделывает login POST до того, как какая-либо сессионная кука существует. Нужен pre-session токен на форме логина, а не SameSite на пост-логин куке.
Heads-up Шифрование защищает конфиденциальность в транзите; оно ничего не делает с подделанной top-level отправкой логина. Защита — CSRF-токен, покрывающий неаутентифицированный поток логина.
Итог
Сквозная линия юнита — одна цепочка: куки — это ambient authority, поэтому браузер шлёт твою сессию на любой запрос к твоему origin — включая подделанную запись. SameSite=Lax срезал поверхность кросс-сайтового POST в 2020, но оставил побочные эффекты на GET, SameSite=None и окно 120с Lax+POST, так что это defense-in-depth, а не замок. Реальная защита слоит неугадываемый токен (synchronizer для stateful-приложений, HMAC-подписанный double-submit для stateless API), проверку Origin/Referer и правило, что мутации не едут на GET. И две ловушки повторяются: HttpOnly/Secure и CORS оба ощущаются как защита от CSRF, но касаются чтения, а не подделанной записи, которая уже выполнилась.