CSRF: Подделка межсайтовых запросов
Что такое CSRF
Подделка межсайтовых запросов CSRF — уязвимость веб безопасности позволяющая злоумышленникам побуждать пользователей выполнять действия, которые они не намерены выполнять. Это позволяет злоумышленнику частично обойти политику одинакового источника (same-origin policy), предназначенную для предотвращения взаимодействия различных веб сайтов друг с другом.
Какие последствия CSRF атаки
При успешной CSRF атаке злоумышленник заставляет пользователя непреднамеренно выполнить действие. Например, это может быть изменение адреса электронной почты в учётной записи, изменение пароля или перевод средств. В зависимости от характера действий злоумышленник может получить полный контроль над учётной записью пользователя. Если скомпрометированный пользователь имеет привилегированную роль в приложении, злоумышленник может получить полный контроль над всеми данными и функциями приложения.
Как работает CSRF
Чтобы CSRF атака была возможно, должны быть соблюдены три условия:
- Активное действие. В приложении есть действие для вызова которого у злоумышленника есть причина. Это может быть привилегированное действие (например, изменение разрешений для других пользователей) или любое действие с данными пользователя (например, изменение собственного пароля пользователя).
- Обработка сеансов на основе файлов cookie. Выполнение действия включает в себя отправку одного или нескольких HTTP-запросов, и приложение полагается исключительно на файлы cookie сессии для идентификации пользователя, отправившего запрос. Другого механизма для отслеживания сеансов или проверки пользовательских запросов не существует.
- Нет непредсказуемых параметров запроса. Запросы, выполняющие действие, не содержат параметров, значения которых злоумышленник не может определить или угадать. Например, когда пользователь изменяет свой пароль, функция неуязвима, если злоумышленнику необходимо знать значение существующего пароля.
Предположим, приложение содержит функцию, позволяющую пользователю изменить адрес электронной почты в своей учётной записи. Когда пользователь выполняет это действие, он делает HTTP-запрос, подобный этому:
POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30
Cookie: session=yvthwsztyeQkAPzeQ5gHgTvlyxHfsAfE
email=wiener@normal-user.comЭто соответствует условиям необходимым для CSRF атаки:
- Действие по изменению адреса электронной почты в учётной записи пользователя представляет интерес для злоумышленника. После этого действия злоумышленник, как правило, сможет инициировать сброс пароля и получить полный контроль над учётной записью пользователя.
- Приложение использует сессию cookie для определения какой пользователь послал запрос. Других токенов или механизмов для отслеживания сеансов пользователей не существует.
- Злоумышленник может легко определить значения параметров запроса, необходимые для выполнения действия.
С учётом этих условий злоумышленник может создать веб-страницу содержащую следующий HTML-код:
<html>
<body>
<form action="https://vulnerable-website.com/email/change" method="POST">
<input type="hidden" name="email" value="pwned@evil-user.net" />
</form>
<script>
document.forms[0].submit();
</script>
</body>
</html>Если пользователь-жертва посещает веб-страницу злоумышленника, происходит следующее:
- Страница злоумышленника инициирует HTTP-запрос к уязвимому веб-сайту.
- Если пользователь авторизовался на уязвимом веб-сайте, его браузер автоматически включит файл сессии cookie в запрос (при условии, что не используются SameSite cookie)
- Уязвимый веб сайт обработает запрос обычным образом, расценит его как выполненный пользователем-жертвой и изменит его адрес электронной почты.
Хотя CSRF обычно описывается в связи с обработкой сеансов на основе cookie сессий, он также возникает в других контекстах, когда приложение автоматически добавляет некоторые учётные данные пользователя в запросы, такие как базовая аутентификация HTTP и аутентификация на основе сертификатов.
Как доставляют CSRF эксплойт
Механизмы доставки для атак с подделкой межсайтовых запросов практически такие же, как и для отражённых XSS. Как правило, злоумышленник размещает вредоносный HTML-код на контролируемом им веб-сайте, а затем побуждает жертву посетить этот веб-сайт. Это можно сделать предоставив пользователю ссылку на веб-сайт по электронной почте или в сообщении соцсети. Или, если атака размещена на популярном веб-сайте (например, в комментарии пользователя), они могут просто подождать, пока пользователи не посетят веб-сайт.
Обратите внимание, что некоторые простые CSRF эксплойты используют метод GET и могут быть полностью автономными с одним URL-адресом на уязвимом веб-сайте. В этой ситуации злоумышленнику может не понадобится использовать внешний сайт, и он может напрямую передать жертве вредоносный URL-адрес в уязвимом домене. В предыдущем примере, если запрос на изменение электронной почты можно выполнить с помощью метода GET, то автономная атака будет выглядеть так:
<img src="https://vulnerable-website.com/email/change?email=pwned@evil-user.net">Основные способы защиты от CSRF атак
В настоящее время для успешного поиска и использования CSRF-уязвимостей требуется обход мер по борьбе с CSRF, развёрнутых целевым веб-сайтом, браузером жертвы или и тем, и другим. Наиболее распространены следующие средства защиты:
- CSRF токен — уникальное, секретное и непредсказуемое значение генерируемое приложением на стороне сервера и передаваемое клиенту. При попытке выполнить конфиденциальное действие, такое как отправка формы, клиент должен включить в запрос правильный CSRF токен. Из-за этого злоумышленнику очень сложно составить валидный запрос от имени жертвы.
- SameSite cookie — механизм безопасности браузера, который определяет, когда cookie веб-сайта включаются в запросы исходящие с других веб-сайтов. Поскольку для запросов на выполнение конфиденциальных действий обычно требуется сессия cookie с проверкой подлинности, соответствующие ограничения
SameSiteмогут помешать злоумышленнику инициировать эти действия на других сайтах. С 2021 года Chrome по умолчанию применяет ограниченияLex SameSite. Поскольку это предлагаемый стандарт, мы ожидаем, что другие основные браузеры примут это поведение в будущем. - Проверка на основе Referer — некоторые приложения используют HTTP-заголовок
Refererдля защиты от CSRF атак. Обычно путём проверки того, что запрос исходит оз собственного домена приложения. Как правило, это менее эффективно, чем проверка CSRF токена.
Подробную информацию о том, как правильно реализовать эти средства защиты для предотвращения CSRF-атак на веб-сайтах см в статье CSRF: Как предотвратить уязвимость.