🎭 CSRF: Как хакер заставляет вас переводить деньги
Кратко: CSRF (Cross-Site Request Forgery) — это атака, при которой злоумышленник заставляет браузер жертвы отправить запрос на сайт, где она уже авторизована . Хакер не крадёт пароль и не взламывает аккаунт — он просто использует вашу же авторизацию, чтобы вы сами, сами того не зная, перевели деньги, сменили пароль или сделали что-то ещё от своего имени . Это как если бы кто-то взял вашу руку с уже приложенным пальцем к сканеру отпечатков и открыл сейф .
🧠 Как это работает CSRF — это атака на доверие. Сайт доверяет вашему браузеру, потому что браузер автоматически отправляет куки при каждом запросе . Хакер этим пользуется. Классическая схема атаки: 1. Вы залогинились в интернет-банке good-bank.com. В браузере сохранилась сессионная кука. 2. Вы переходите на сайт злоумышленника bad-site.com. Там скрытая форма. 3. Форма автоматически отправляет запрос в ваш банк: POST /transfer с суммой и счётом хакера. 4. Браузер подставляет вашу куку, сервер думает, что это вы, и переводит деньги . Главное: вы даже не кликали по кнопке. Достаточно просто открыть страницу. Классический пример: форма на bad-site.com с action=“https://good-banking-site.com/api/account” — запрос уходит на уязвимый сайт .
⚙️ Техники эксплуатации Скрытая форма с автоподачей: document.forms[0].submit(); Форма скрыта, а JS отправляет её сразу после загрузки страницы .
Атака через изображение: если сайт использует GET-запросы для изменения состояния, достаточно картинки с подставленным URL:
Браузер загружает картинку — и деньги уходят . Атака через XMLHttpRequest: вредоносный скрипт может отправлять AJAX-запросы и даже читать ответы, если заголовки CORS позволяют .
🛡️ Как защититься CSRF-токены: самый надёжный способ. Сервер генерирует уникальный токен для каждой формы и проверяет его при отправке. Токен привязан к сессии и непредсказуем — хакер не может его угадать .
Пример реализации на Flask: @app.route(‘/update-email’, methods=[‘POST’]) def update_email(): token = request.form.get(‘csrf_token’) session_token = session.get(‘csrf_token’) if not token or token != session_token: abort(403) return “Email updated!”
SameSite-куки: атрибут SameSite=Strict запрещает браузеру отправлять куки при запросах с других сайтов. SameSite=Lax разрешает отправку только для безопасных GET-запросов (переход по ссылке) и блокирует POST . Проверка Referer / Origin: сервер проверяет, что запрос пришёл с его собственного домена. Но заголовки могут отсутствовать или подделываться, поэтому это не единственная защита . Сложность: атаки возможны не только через куки, но и через HTTP Basic/Digest-аутентификацию — браузер автоматически отправляет учётные данные в течение сессии .
🎯 Современное положение (2026) CSRF-атаки остаются в OWASP Top 10 (категория Broken Access Control) . Использование CSRF-токенов — золотой стандарт, а SameSite-куки стали дополнительным барьером для защиты от межсайтовых запросов. Однако атаки возможны в том числе и в пределах одного сайта, а XSS может обойти защиту полностью . Главный вывод: CSRF — это атака на доверие. Сервер доверяет вашему браузеру, а хакер использует это, чтобы заставить браузер делать то, что нужно ему. Защита — всегда проверять, что запрос идёт от вашего сайта, а не из интернета.
