Автор: Kateryna Ivanenko, Invicti Brand Manager
Кратко о CSRF
CSRF, или подделка межсайтового запроса – это тип веб-атаки, обманом заставляющий браузер аутентифицированного пользователя выполнить нежелательное действие на надежном сайте.
Она использует аутентифицированную сессию пользователя, заставляя браузер отправлять вредоносный запрос на сайт, на котором пользователь уже вошел в систему. Это может привести к несанкционированным действиям, таким как изменение настроек аккаунта или совершение транзакций без согласия пользователя.
На этой странице разъясняется разница между CSRF и XSS (межсайтовый скриптинг).
Основные причины CSRF
1) Положение исключительно на cookie для идентификации пользователя
Если веб-программа авторизует действия только на основе cookie сессии, может быть выполнен любой межсайтовый запрос, который браузер делает с этими файлами. Браузеры автоматически добавляют такие cookie, независимо от страницы, которая инициировала запрос, являющийся основным условием для CSRF.
2) Отсутствующие или неэффективные анти-CSRF токены
Самая надежная защита – это требование токена для каждого запроса, который сайт злоумышленника не может прочитать или угадать. Если они отсутствуют, или они простые, повторно используемые или не привязанные к пользователю/сессии, CSRF становится возможным. OWASP четко рекомендует защиту на основе токенов как основное смягчение.
3) Небезопасное использование HTTP-методов
Если чувствительные действия разрешены через GET или если сервер не различает чтение (read) и запись (write), злоумышленники могут инициировать их с помощью <img>, <link> или простой навигации. Действия с изменением состояния через GET должны быть запрещены.
4) Слабая проверка источника запроса
Если веб-сайт не проверяет, откуда поступают запросы (используя заголовки Origin или Referer), он не может определить, было ли действие пользователя выполнено на его собственном сайте или на поддельном.
Злоумышленники могут обманом вынудить браузер отправлять неавторизованные запросы. Правильная проверка заголовка Origin и соблюдение строгого списка разрешенных источников помогает предотвратить это.
5) Неправильно настроенные файлы cookie SameSite
SameSite является хорошей практикой, но не панацеей. Веб-программы, которые полагаются исключительно на это, остаются уязвимыми.
6) Неправильные конфигурации CORS (Cross-Origin Resource Sharing)
Если веб-приложение позволяет браузерам отправлять файлы cookie или токены для входа (Access-Control-Allow-Credentials: true) и одновременно принимает запросы от любого сайта, то хакерский веб-сайт может отправлять их от имени пользователя и, возможно, даже видеть ответы. То есть разрешение на все источники с доверием к учетным данным открывает путь для атак CSRF.
7) Потоки OAuth/OIDC без надлежащего параметра состояния
Потоки входа являются отдельным нюансом CSRF: если клиентская программа не привязывает ответ авторизации к сессии браузера, используя криптографически устойчивое значение состояния (и не проверяет его по возвращении), злоумышленники могут внедрять код или токены авторизации. Спецификация OAuth и основные поставщики идентификационных данных определяют состояние как обязательный элемент контроля CSRF.
8) Слишком длительные сессии и лишние привилегии
Когда сессии никогда не заканчиваются, или включают чрезмерные привилегии, CSRF имеет большее влияние. Хотя это не является прямой причиной, они могут усиливать данную атаку.
Короткий cheat sheet для снижения риска и смягчения CSRF
- Использование анти-CSRF токенов для запросов с изменением состояния и привязки к пользователю/сессии. Вы можете найти больше информации об использовании анти-CSRF токенов в этой статье.
- Настройка GET только для чтения; обеспечение проверки методов на стороне сервера.
- Проверка, откуда поступает запрос: использование заголовка Origin, а если он отсутствует, положение только на тщательно проверенный хедер Referer.
- Настройка файлов cookie: сочетание SameSite с токенами и использование флажков Secure и HttpOnly, где это возможно.
- Усиление CORS: не стоит использовать Access-Control-Allow-Credentials: true, если это не действительно нужно, и никогда не следует применять его с * или скопированным значением Origin.
- Для OAuth/OIDC: генерация криптографически устойчивого состояния, его привязка к сессии пользователя и проверка во время редиректа.
- Конфигурации сессии: более короткий срок, ограниченные привилегии и дополнительная авторизация для чувствительных операций.
Как обнаружить уязвимость CSRF в веб-приложениях
Единственный способ выявить CSRF – это тестирование безопасности веб-сайта. Для этой цели можно использовать разные сканеры, например:
- DAST (black-box): имитация действий хакера, находящее уязвимости при выполнении веб-приложения.
- SAST (white-box): поиск дефекта в непосредственно в коде, подобно ошибкам в тексте.
Лучшая практика – сочетать оба метода, поскольку динамическое тестирование помогает выявлять уязвимости, специфические для выполнения веб-приложения, но не может сканировать всю базу кода, как статический анализ. Оба метода можно имплементировать в CI/CD, при этом SAST интегрируется на ранних этапах.
Если вы хотите бесплатно протестировать такие решения, это может быть DAST Invicti (на основе Acunetix и Netsparker) или продукт, включающий SAST, SCA, безопасность контейнеров, такой как Mend.io. Для этого, пожалуйста, оставьте свои контактные данные:
Запрос на бесплатное тестирование Invicti/Mend.io
Оставьте контакты и мы с вами свяжемся
