PomogitePLZ
02.07.2026, 16:10
Введение
Если коротко — CSRF (Cross-Site Request Forgery) это атака, при которой злоумышленник заставляет жертву выполнить нежелательное действие на сайте, где она авторизована. По факту ты, зайдя на вредоносный сайт или открыв подозрительную ссылку, можешь непреднамеренно запустить команду на другом сервисе (например, изменить пароль, перевести деньги, удалить что-то). В этой теме хочу разобрать, что это за уязвимость, где она проявляется и как от неё реально защититься.
Что это такое
CSRF — это когда ты, не меняя своей активной сессии, выполняешь запрос, который сайт считает легитимным, потому что тут нет проверки источника. Представь, ты зашёл в личный кабинет банка и оставил вкладку открытой. Потом заходишь на другой сайт с вредоносным скриптом — он пытается отправить запрос на перевод денег, и банк его принимает, так как видит твой валидный куки. Вот это и есть CSRF — подделка запросов с чужой сессии.
Где применяется
Основные места риска — формы с запросами на изменение настроек, перевод денег, подписки, комментирование и вообще любые действия, где сайт не проверяет откуда пришёл запрос, а лишь смотрит на авторизацию. Вот примеры:
- Банковские и финансовые сервисы
- Сайты с личным кабинетом (например, соцсети, почтовики)
- Админ-панели CMS и прочих систем управления
- Сервисы с возможностью оплаты или оформления заявок
Практические примеры
1. Форма смены пароля без csrf-токена.
Кто-то создаёт на стороннем сайте форму, которая отправляет POST-запрос на адрес изменения пароля. Жертва кликает на ссылку, и её пароль путём подделки меняется.
2. Кнопка “лайк” или “следить” без защиты. Иногда CSRF используют, чтобы заставить зарегистрированных пользователей лайкать или подписываться на что-то без их ведома.
3. Админка блога, где можно удалять посты через GET-запросы. Если админ заходит на вредоносный сайт, тот может случайно удалить всё, отправляя запросы под его авторизацией.
Типичные ошибки
- Полагаться только на cookie для аутентификации без проверки источника запроса
- Отсутствие или неправильная реализация CSRF-токенов
- Использование методов GET для изменения состояния (то есть для действий, которые должны быть POST или PUT)
- Игнорирование заголовков Origin и Referer, которые могли бы помочь фильтровать запросы
- Необновляемые или слишком простые CSRF-токены
Полезные инструменты
- Защита на уровне фреймворков — почти все популярные CMS и веб-фреймворки (Django, Laravel, Spring) умеют автоматически вставлять и проверять CSRF-токены
- Инструменты сканирования уязвимостей, например OWASP ZAP для оценки наличия CSRF в приложении
- Расширения для браузеров, которые помогают отслеживать подозрительные запросы (например, CSRF Protector)
- Настройка CORS и Content Security Policy для ограничения контакта с другими доменами
FAQ
1. Почему CSRF токен должен быть уникальным?
Потому что если токен постоянный, злоумышленник может его узнать и использовать повторно.
2. Можно ли защититься с помощью куки с флагом SameSite?
Да, флаг SameSite в cookie помогает ограничить отправку куки только с запросами с того же сайта, но не во всех браузерах и не всегда этого достаточно.
3. А что делать, если проект уже работает без CSRF защиты?
Лучше всего добавить проверку CSRF-токенов или хотя бы реализовать проверку Origin/Referer, дополнительно следить за обновлениями CMS и применять патчи.
4. Может ли HTTPS помочь?
HTTPS защищает данные при передаче, но не спасает от CSRF, так как атака происходит в рамках активной сессии, а защищённое соединение не влияет на логику сервера.
Вывод
CSRF — это та уязвимость, которая часто недооценивается, но может привести к неприятностям любого масштаба: от мелких неудобств до серьёзных финансовых потерь или компрометации учётных записей. Главная защита — в правильной реализации CSRF-токенов, использовании POST-запросов для изменений, в учёте заголовков Origin и внедрении современных политик безопасности. Если у вас проект с формами и авторизацией — обязательно проверьте, есть ли у вас этa защита и как она реализована.
Кто ещё сталкивался с CSRF и как боретесь? Какие нестандартные проблемы возникали в реальных проектах? Поделитесь опытом!
Если коротко — CSRF (Cross-Site Request Forgery) это атака, при которой злоумышленник заставляет жертву выполнить нежелательное действие на сайте, где она авторизована. По факту ты, зайдя на вредоносный сайт или открыв подозрительную ссылку, можешь непреднамеренно запустить команду на другом сервисе (например, изменить пароль, перевести деньги, удалить что-то). В этой теме хочу разобрать, что это за уязвимость, где она проявляется и как от неё реально защититься.
Что это такое
CSRF — это когда ты, не меняя своей активной сессии, выполняешь запрос, который сайт считает легитимным, потому что тут нет проверки источника. Представь, ты зашёл в личный кабинет банка и оставил вкладку открытой. Потом заходишь на другой сайт с вредоносным скриптом — он пытается отправить запрос на перевод денег, и банк его принимает, так как видит твой валидный куки. Вот это и есть CSRF — подделка запросов с чужой сессии.
Где применяется
Основные места риска — формы с запросами на изменение настроек, перевод денег, подписки, комментирование и вообще любые действия, где сайт не проверяет откуда пришёл запрос, а лишь смотрит на авторизацию. Вот примеры:
- Банковские и финансовые сервисы
- Сайты с личным кабинетом (например, соцсети, почтовики)
- Админ-панели CMS и прочих систем управления
- Сервисы с возможностью оплаты или оформления заявок
Практические примеры
1. Форма смены пароля без csrf-токена.
Кто-то создаёт на стороннем сайте форму, которая отправляет POST-запрос на адрес изменения пароля. Жертва кликает на ссылку, и её пароль путём подделки меняется.
2. Кнопка “лайк” или “следить” без защиты. Иногда CSRF используют, чтобы заставить зарегистрированных пользователей лайкать или подписываться на что-то без их ведома.
3. Админка блога, где можно удалять посты через GET-запросы. Если админ заходит на вредоносный сайт, тот может случайно удалить всё, отправляя запросы под его авторизацией.
Типичные ошибки
- Полагаться только на cookie для аутентификации без проверки источника запроса
- Отсутствие или неправильная реализация CSRF-токенов
- Использование методов GET для изменения состояния (то есть для действий, которые должны быть POST или PUT)
- Игнорирование заголовков Origin и Referer, которые могли бы помочь фильтровать запросы
- Необновляемые или слишком простые CSRF-токены
Полезные инструменты
- Защита на уровне фреймворков — почти все популярные CMS и веб-фреймворки (Django, Laravel, Spring) умеют автоматически вставлять и проверять CSRF-токены
- Инструменты сканирования уязвимостей, например OWASP ZAP для оценки наличия CSRF в приложении
- Расширения для браузеров, которые помогают отслеживать подозрительные запросы (например, CSRF Protector)
- Настройка CORS и Content Security Policy для ограничения контакта с другими доменами
FAQ
1. Почему CSRF токен должен быть уникальным?
Потому что если токен постоянный, злоумышленник может его узнать и использовать повторно.
2. Можно ли защититься с помощью куки с флагом SameSite?
Да, флаг SameSite в cookie помогает ограничить отправку куки только с запросами с того же сайта, но не во всех браузерах и не всегда этого достаточно.
3. А что делать, если проект уже работает без CSRF защиты?
Лучше всего добавить проверку CSRF-токенов или хотя бы реализовать проверку Origin/Referer, дополнительно следить за обновлениями CMS и применять патчи.
4. Может ли HTTPS помочь?
HTTPS защищает данные при передаче, но не спасает от CSRF, так как атака происходит в рамках активной сессии, а защищённое соединение не влияет на логику сервера.
Вывод
CSRF — это та уязвимость, которая часто недооценивается, но может привести к неприятностям любого масштаба: от мелких неудобств до серьёзных финансовых потерь или компрометации учётных записей. Главная защита — в правильной реализации CSRF-токенов, использовании POST-запросов для изменений, в учёте заголовков Origin и внедрении современных политик безопасности. Если у вас проект с формами и авторизацией — обязательно проверьте, есть ли у вас этa защита и как она реализована.
Кто ещё сталкивался с CSRF и как боретесь? Какие нестандартные проблемы возникали в реальных проектах? Поделитесь опытом!