Атака CSRF (также известная как подделка межсайтовых запросов) — это тип уязвимости веб-приложений, при котором злоумышленник может заставить пользователя выполнить нежелательные действия на сайте, на котором тот уже авторизован. Это достигается путем отправки на сайт запроса от имени пользователя без его ведома. При этом сайт доверяет запросу, так как он исходит от уже аутентифицированного пользователя.
1. Принцип работы
Основная идея CSRF-атаки заключается в том, что пользователь уже авторизован на целевом сайте (например, в своем интернет-банке или на сайте электронной почты). Злоумышленник создает ссылку или HTML-форму, которая отправляет запрос на этот сайт от имени пользователя. Если сайт не проверяет источник запроса должным образом, он может выполнить действие, как если бы его инициировал сам пользователь.
Пример:
- Пользователь заходит на сайт банка и авторизуется.
- Злоумышленник отправляет пользователю ссылку через электронную почту или публикует её на стороннем сайте.
- Пользователь, не подозревая опасности, кликает на ссылку.
- Эта ссылка отправляет запрос на сайт банка с действием (например, перевод денег), и сайт выполняет его, так как пользователь уже авторизован в системе.
2. Пример атаки
Предположим, что сайт интернет-банка использует следующий запрос для перевода денег:
GET https://example-bank.com/transfer?amount=5000&to=123456
Злоумышленник может создать HTML-страницу с таким кодом:
<img src="https://example-bank.com/transfer?amount=5000&to=123456" style="display:none;">
Если пользователь, который уже авторизован в банке, откроет эту страницу, браузер автоматически отправит запрос на сервер банка, и деньги будут переведены.
3. Условия для успешной атаки
Для успешной атаки CSRF должны быть выполнены следующие условия:
- Пользователь уже авторизован в приложении.
- Сайт не проверяет источник запроса (например, не использует специальные защитные механизмы).
- Браузер автоматически отправляет куки или другие данные для аутентификации.
4. Защита от атаки CSRF
Для защиты от CSRF-атак используются различные методы и стратегии:
а) CSRF-токены
- Один из наиболее распространенных способов защиты. В каждой форме или запросе, отправляемом от клиента на сервер, добавляется уникальный токен, который сервер проверяет при получении запроса. Если токен не совпадает или отсутствует — запрос отклоняется.
- Токены генерируются сервером и привязываются к сессии пользователя. Они должны быть уникальными для каждой сессии и изменяться при каждой новой аутентификации.
б) Проверка Referer и Origin
- При обработке запроса сервер может проверять заголовки Referer или Origin, чтобы убедиться, что запрос пришел с законной страницы сайта, а не с внешнего ресурса.
- Однако полагаться исключительно на эти заголовки не рекомендуется, так как некоторые браузеры или конфигурации могут блокировать отправку этих заголовков.
в) SameSite Cookies
- Это механизм, который ограничивает отправку куки только в тех случаях, когда запросы исходят с того же домена. Если запрос приходит с другого домена, куки не отправляются, и сервер не может аутентифицировать пользователя.
- Это относительно новая мера, которая поддерживается современными браузерами и помогает предотвратить CSRF-атаки.
г) Использование методов POST вместо GET
- Хотя это не является полной защитой, использование методов POST вместо GET для выполнения критически важных операций затрудняет злоумышленнику создание атакующих ссылок, так как формы с методом POST сложнее внедрить в сторонние сайты.
д) Ограничение времени действия сессии
- Ограничение времени действия сессии может уменьшить окно возможностей для CSRF-атаки, так как токены и куки будут действительны только на короткий промежуток времени.
Заключение
Атака CSRF — это серьезная угроза, которая может привести к выполнению нежелательных действий от имени пользователя на доверенных сайтах. Однако современные методы защиты, такие как использование CSRF-токенов, проверка заголовков и использование SameSite Cookies, помогают значительно снизить риск таких атак. Важно, чтобы разработчики веб-приложений учитывали возможность CSRF-атак и внедряли соответствующие меры безопасности.
Если проверка здоровья не прошла, статус будет выглядеть как unhealthy.
Если Вам интересно, что еще можно найти на канале QA Helper, прочитайте статью: Вместо оглавления. Что вы найдете на канале QA Helper - справочник тестировщика?
Не забудьте подписаться на канал, чтобы не пропустить полезную информацию: QA Helper - справочник тестировщика
Пишите в комментариях какой пункт было бы интересно рассмотреть более подробно.
Обязательно прочитайте: Что должен знать и уметь тестировщик
Также будет интересно почитать: Вопросы которые задают на собеседовании тестировщикам