Безопасность
CSRF: тест на свободное воспроизведение
Воспроизведение из памяти бьёт перечитывание. На каждый промпт скажи или запиши полный ответ по памяти, прежде чем открыть образцовый — именно усилие припоминания закрепляет материал.
Восстанови спину юнита — ambient authority, намеренные бреши SameSite, токен-паттерны synchronizer и double-submit, проверки Origin/Referer и почему CORS — не защита от CSRF — не подсматривая в урок.
- 01Почему CSRF работает, хотя атакующий никогда не видит ответ и никогда не читает сессионную куку?
- 02Chrome сделал SameSite=Lax дефолтом в 2020. Назови точно, что он блокирует, и три бреши, которые он оставляет.
- 03Сравни synchronizer token pattern и double-submit cookie pattern: как работает каждый и когда что выбрать.
- 04Что добавляют проверки заголовков Origin и Referer и почему это слой defense-in-depth, а не единственная защита?
- 05Коллега говорит: «у нас строгая CORS-политика, значит, мы защищены от CSRF». Объясни точно, почему CORS — не защита от CSRF.
- 06Что такое login CSRF, почему он подставляет команды и как защищаться?
Если ты смог восстановить каждый ответ по памяти, ты держишь спину юнита: CSRF едет на ambient authority, так что подделанная запись выполняется с полной аутентификацией; SameSite=Lax срезал поверхность кросс-сайтового POST, но оставил побочные эффекты на GET, SameSite=None и окно 120с Lax+POST; synchronizer token (stateful) и HMAC-подписанный double-submit (stateless) — реальные защиты; Origin/Referer — дешёвый фильтр defense-in-depth, а не единственная защита; CORS гейтит чтение ответа, а не выполнение запроса, поэтому он не защита от CSRF; а login CSRF требует pre-session токена, потому что подделка предшествует сессионной куке.