Что такое CSRF атака и как она работает

Что проверяют

Сможете ли вы воспроизвести атаку тест-кейсом, а не пересказать определение, и отличить работающую защиту от её видимости. Для тестировщика вопрос звучит так: какие запросы вы попробуете подделать и по чему поймёте, что сервер подделку принял.

Как отвечать

Суть в том, что браузер сам прикладывает куки к запросу на ваш домен, кто бы этот запрос ни инициировал. Значит, форма или картинка на постороннем сайте может выполнить действие от имени залогиненного пользователя. Ответ атакующему не нужен, ему нужен побочный эффект: смена почты или пароля, перевод, оформление заказа.

Как это проверяют:

• собрать страницу с формой, которая отправляется автоматически на изменяющий эндпоинт, и открыть её в браузере с живой сессией;
• повторить запрос без токена, с пустым токеном, с токеном из другой сессии, с подменённым и вырезанным заголовком Origin;
• убедиться, что GET ничего не меняет, а изменяющие методы не принимают параметры из строки запроса;
• посмотреть куки сессии: SameSite, Secure, HttpOnly;
• проверить, что токен привязан к сессии, обновляется после входа и не утекает в адрес страницы, логи и заголовок Referer.

Рабочая защита это токен, связанный с сессией, плюс проверка Origin. Значение SameSite в режиме Lax закрывает основную часть векторов, но не спасает от поддоменов и от действий, оформленных переходом по ссылке.

Где спотыкаются

Считают, что HTTPS, вход по паролю или проверка сессии уже защищают. Атака выполняется именно в валидной сессии, шифрование канала к ней отношения не имеет.

Находят скрытое поле с токеном в разметке и закрывают проверку. Нужно убедиться, что сервер его действительно сверяет: нередко принимается любое значение, или проверка стоит на форме, но отсутствует у того же метода в мобильном API.

Путают CSRF с XSS и надеются на CORS. CORS ограничивает чтение ответа чужим скриптом, отправку обычной формы он не отменяет, а разрешающая настройка с передачей учётных данных только расширяет поверхность атаки.