Skip to content
EN

CSRF: определение и применение

Коротко:

CSRF (Cross-Site Request Forgery) — атака, где злоумышленник заставляет браузер жертвы отправить запрос на другой сайт с credentials жертвы (cookies). Защита: CSRF-токены в форме, SameSite=Lax/Strict cookies, double-submit pattern, referer validation.

Проверить безопасность сайта →

Что такое CSRF

CSRF (Cross-Site Request Forgery) — атака, где злоумышленник заставляет браузер жертвы отправить запрос на другой сайт с credentials жертвы (cookies). Защита: CSRF-токены в форме, SameSite=Lax/Strict cookies, double-submit pattern, referer validation.

Примеры атак CSRF

CSRF-атаки могут быть реализованы различными способами. Например, злоумышленник может создать вредоносную ссылку, которая при переходе отправляет POST-запрос на уязвимый сайт с поддельными данными. Это может привести к изменению паролей, добавлению новых пользователей или другим нежелательным действиям.

Другой пример — использование iframe, который загружает вредоносную страницу с запросом на атакуемый сайт. Это может произойти, например, при посещении заражённого сайта или при просмотре вредоносного электронного письма. В результате браузер жертвы отправляет запрос на атакуемый сайт, и злоумышленник получает доступ к данным пользователя.

Чтобы защититься от CSRF-атак, важно использовать современные методы защиты, такие как CSRF-токены и SameSite=Lax/Strict cookies.

Как проверить сайт на уязвимость к CSRF

Для проверки сайта на уязвимость к CSRF можно использовать различные инструменты и методы. Например, можно провести тестирование на проникновение (penetration testing), чтобы имитировать действия злоумышленника и проверить, насколько сайт защищён от CSRF-атак.

Также можно использовать специальные инструменты для тестирования на уязвимости, такие как Burp Suite или OWASP ZAP. Эти инструменты позволяют отправлять поддельные запросы на сайт и проверять, как он на них реагирует.

Кроме того, можно проверить наличие CSRF-токенов на сайте и убедиться, что они правильно реализованы. Для этого можно использовать инструменты для анализа кода, такие как SonarQube или CodeQL.

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

Влияние CSRF на безопасность веб-приложений

CSRF может иметь серьёзные последствия для безопасности веб-приложений. Например, злоумышленник может получить доступ к личным данным пользователя, таким как пароли или номера банковских счетов. Это может привести к финансовым потерям или краже личной информации.

Кроме того, CSRF может использоваться для проведения других атак, таких как фишинг или мошенничество. Например, злоумышленник может создать поддельный сайт, который выглядит как настоящий, и заставить пользователя ввести свои данные на этом сайте. Затем злоумышленник может использовать эти данные для проведения финансовых операций или других действий.

Чтобы минимизировать риски, связанные с CSRF, важно использовать современные методы защиты и регулярно проверять сайт на уязвимость. Это поможет обеспечить безопасность веб-приложений и защитить пользователей от потенциальных угроз.

ЗаголовкиCSP, HSTS, X-Frame-Options и др.
SSL/TLSШифрование и сертификат
КонфигурацияСерверные настройки и утечки
Оценка A-FОбщий балл безопасности

Почему нам доверяют

OWASP
рекомендации
15+
заголовков безопасности
<2с
результат
A–F
оценка безопасности

Как это работает

1

Введите URL сайта

2

Анализ заголовков безопасности

3

Получите оценку A–F

Что проверяет анализ безопасности?

Инструмент проверяет HTTP-заголовки безопасности, конфигурацию SSL/TLS, утечки серверной информации и защиту от распространённых атак (XSS, clickjacking, MIMEsniffing). Оценка от A до F показывает общий уровень защиты.

Анализ заголовков

Проверка Content-Security-Policy, HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy и других.

Проверка SSL

Версия TLS, срок сертификата, цепочка доверия, поддержка HSTS.

Обнаружение утечек

Поиск раскрытых серверных версий, debug-режимов, открытых конфигов и директорий.

Отчёт с рекомендациями

Детальный отчёт с объяснением каждой проблемы и конкретными шагами для исправления.

Кому это нужно

Специалисты по безопасности

аудит HTTP-заголовков

DevOps

проверка конфигурации

Разработчики

CSP и HSTS настройка

Аудиторы

соответствие стандартам

Частые ошибки

Нет Content-Security-PolicyCSP — главная защита от XSS. Без него инъекция скриптов значительно проще.
Нет заголовка HSTSБез HSTS возможна downgrade-атака с HTTPS на HTTP. Включите Strict-Transport-Security.
Server header раскрывает версиюServer: Apache/2.4.52 помогает атакующим подобрать эксплойт. Скройте версию.
X-Frame-Options не установленСайт можно встроить в iframe для clickjacking-атаки. Установите DENY или SAMEORIGIN.
Нет X-Content-Type-OptionsБез nosniff браузер может интерпретировать файлы неправильно (MIME sniffing).

Лучшие практики

Начните с базовых заголовковМинимум: HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy. Займёт 5 минут.
Внедрите CSP постепенноНачните с Content-Security-Policy-Report-Only, мониторьте нарушения, затем включите.
Скройте серверные заголовкиУдалите Server, X-Powered-By, X-AspNet-Version из ответов.
Настройте Permissions-PolicyОграничьте доступ к камере, микрофону, геолокации — только то, что реально используется.
Проверяйте после каждого деплояЗаголовки безопасности могут быть перезаписаны при обновлении конфигурации сервера.

Получите больше с бесплатным аккаунтом

История security-проверок и мониторинг HTTP-заголовков безопасности.

Зарегистрироваться (FREE)

Больше по теме

Часто задаваемые вопросы

Применимо ли к моему проекту?

См. определение выше. Большинство веб-проектов с trafic > 100 RPS нуждается.

Запустить инструмент, который описан в этой статье

Бесплатный тариф — 10 мониторов, проверки каждые 5 мин, без карты. Платные тарифы — интервал от 1 минуты и проверки из нескольких регионов.