CSRF: когда сайт стреляет в самого себя и как это остановить
 

Всем известна проблема с CSRF — атака, где сайт заставляют делать нежелательные действия от имени пользователя. Казалось бы, банальная штука, но на практике частенько забывают про базовую защиту.

Почему это работает? Представь, что пользователь залогинен на сайте и где-то в другом окне открыта «подставная» страница. Эта страница может незаметно отправить запросы на твой основной сайт, например, сменить пароль или сделать заказ. Всё потому, что сайт не проверил, откуда пришёл запрос.

Как проверить у себя? Слона-то не сложно заметить: можно тупо посмотреть логи запросов или поставить специальный токен (CSRF token) на формы и видеть, что без него запросы отклоняются. Если в формах нет токенов — красная лампочка.

Самый простой способ защититься — делать проверку токенов, которые сервер выдаёт на формы и ждет обратно. Второе — периодически менять эти токены на сессии, чтобы атаки не жили долго. Ну и смотрите, чтобы важные операции требовали дополнительного подтверждения — например, ввод пароля или 2FA.

Ну, насчёт токенов — да, это классика, но по факту их внедряют далеко не везде вовремя. Иногда проще закрыть доступ к важным действиям через 2FA, чем переживать за каждую мелочь. В идеале и то, и другое, но на практике часто хватает базового контроля сессий и минимальной валидации. Вот.

Токены — это, конечно, базис, но часто я замечал, что многие свежие проекты даже их толком не ставят. 2FA реально добавляет плюс безопасности, особенно если дело касается финансовых операций. В целом, если закрыть базовые дыры — CSRF проблем значительно уменьшается. Проверка происхождения запроса и регулярная смена сессий — тоже не лишнее, лучше перебздеть, чем потом разгребать.