Понимание атак CSRF и блокировка уязвимостей CSRF

Опубликовано: 2022-11-21

Веб-уязвимости широко распространены и постоянно увеличиваются. Обеспечение безопасности и конфиденциальности ваших пользователей важнее, чем когда-либо. Если не устранить веб-уязвимости, это может привести к испорченной репутации и огромным штрафам от регулирующих органов, а также к потере доверия пользователей.

Веб-сайты и веб-приложения уязвимы для вредоносных программ, спама и других атак — в этой статье основное внимание уделяется одному из таких векторов атак — атакам с подделкой межсайтовых запросов (CSRF). Атаки CSRF вызывают особую тревогу, поскольку они могут происходить без ведома пользователя. Их также трудно обнаружить разработчику или владельцу веб-сайта, потому что вредоносные запросы очень похожи на настоящие запросы.

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

Что такое CSRF-атака?

Атака с подделкой межсайтовых запросов, также известная как атака CSRF, обманом заставляет аутентифицированного пользователя выполнять непреднамеренные действия, отправляя вредоносные запросы без их осознания этого.

Иллюстрация того, как работают подделки межсайтовых запросов (CSRF).
Как работают CSRF-атаки. (Источник изображения: Окта)

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

Злоумышленник обычно использует социальную инженерию, чтобы отправить ничего не подозревающему пользователю ссылку через чат или электронную почту.

Когда пользователь щелкает ссылку, он выполняет команды, заданные злоумышленником.

Например, нажатие на ссылку может перевести средства со счета пользователя. Или он может изменить адрес электронной почты пользователя, не позволяя ему восстановить доступ к учетной записи.

Как работает CSRF-атака?

Заставить пользователя инициировать запрос на изменение состояния при входе в систему — это первый и самый важный шаг в атаке CSRF. С помощью CSRF-атак злоумышленник стремится заставить аутентифицированного пользователя неосознанно отправить вредоносный веб-запрос на веб-сайт или веб-приложение. Эти запросы могут состоять из файлов cookie, параметров URL и других типов данных, которые кажутся пользователю обычными.

Чтобы CSRF-атака была успешной, должны выполняться следующие условия:

  • Аутентифицированный пользователь должен войти в веб-приложение, которое использует файлы cookie для управления сеансом.
  • Злоумышленник должен создать поддельный запрос на изменение состояния.
  • Подлинные запросы, обрабатываемые целевым сервером, не должны содержать непредсказуемых параметров. Например, запрос не должен ожидать пароль в качестве параметра для проверки перед инициированием запроса на изменение состояния.

Самый распространенный метод завершения CSRF-атак — использование файлов cookie в приложениях со слабой политикой файлов cookie SameSite. Веб-браузеры включают файлы cookie автоматически и часто анонимно, и они сохраняют файлы cookie, используемые доменом, в любом веб-запросе, который пользователь отправляет в этот домен.

Политика файлов cookie SameSite определяет, как браузер в контексте просмотра между сайтами обрабатывает файл cookie. Если установлено значение «строгий», файл cookie не передается в контекстах просмотра между сайтами, что предотвращает атаки CSRF. Браузер прикрепляет файл cookie во всех межсайтовых контекстах, если он не установлен. Это делает приложение уязвимым для CSRF-атак.

Когда пользователь по незнанию отправляет вредоносный запрос через веб-браузер, сохраненные файлы cookie заставляют сервер считать запрос законным. Затем сервер отвечает на запрос, изменяя учетную запись пользователя, изменяя состояние сеанса или возвращая запрошенные данные.

Давайте подробнее рассмотрим два примера способов атаки CSRF, один с запросом GET, а другой с запросом POST.

CSRF для запроса GET

Во-первых, рассмотрим запрос GET, используемый веб-приложением финансового банка, где атака использует запрос GET и доставку по гиперссылке.

Допустим, GET-запрос на перевод денег выглядит примерно так:

 GET https://xymbank.com/online/transfer?amount=1000&accountNumber=547895 HTTP/1.1

В приведенном выше подлинном запросе пользователь запрашивает перевод 1000 долларов США на счет с 547895 в качестве оплаты за приобретенные продукты.

Хотя этот запрос является явным, простым и практичным, он подвергает владельца учетной записи атаке CSRF. Это связано с тем, что запрос не требует подробностей, которые злоумышленник может не знать. Таким образом, чтобы инициировать атаку, злоумышленнику нужно будет только изменить параметры этого запроса (сумма и номер счета), чтобы создать исполняемый поддельный запрос.

Вредоносный запрос будет эффективен для любого из пользователей банка, если у них есть текущие сеансы, управляемые файлами cookie.

Вот как будет выглядеть поддельный запрос на перевод $500 на счет хакера (здесь номер 654585 ). Обратите внимание, что приведенный ниже пример представляет собой очень упрощенную версию шагов, связанных с атакой CSRF, для объяснения.

 GET https://xymbank.com/online/transfer?amount=500&accountNumber=654585 HTTP/1.1

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

 <a href="https://xymbank.com/online/transfer?amount=500&accountNumber=654585">Click here to get more information</a>.

Учитывая, что злоумышленник нашел правильные адреса электронной почты своих целей, он может отправить их по электронной почте многим клиентам банка. Те, кто щелкнет ссылку во время входа в систему, вызовут запрос на отправку злоумышленнику 500 долларов с зарегистрированной учетной записи.

CSRF для POST-запроса

Давайте посмотрим, как то же самое финансовое учреждение испытало бы CSRF, если бы оно принимало только запросы POST. В этом случае доставка гиперссылки, использованная в примере с запросом GET, работать не будет. Следовательно, для успешной атаки CSRF злоумышленнику потребуется создать HTML-форму. Подлинный запрос на отправку 1000 долларов за купленный товар будет выглядеть так:

 POST /online/transfer HTTP/1.1 Host: xymbank.com Content-Type: application/x-www-form-urlencoded Cookie: session=FRyhityeQkAPzeQ5gHgTvlyxHJYhg amount=1000 account=547895

Для этого запроса POST требуется файл cookie для определения личности пользователя, суммы, которую он хочет отправить, и учетной записи, которую он хочет отправить. Злоумышленники могут изменить этот запрос для выполнения атаки CSRF.

Злоумышленник должен добавить только подлинный файл cookie к поддельному запросу, чтобы сервер обработал передачу. Они могут сделать это, создав безобидную на вид гиперссылку, которая перенаправит пользователя на триггерную веб-страницу, которая выглядит следующим образом:

 <html> <body> <form action="https://xymbank.com/online/transfer" method="POST"> <input type="hidden" name="amount" value="500"/> <input type="hidden" name="account" value="654585" /> </form> <script> document.forms[0].submit(); </script> </body> </html>

Мы уже установили сумму и параметры счета в форме выше. Как только аутентифицированный пользователь посещает страницу, браузер добавляет файл cookie сеанса перед пересылкой запроса на сервер. Затем сервер пересылает 500 долларов на счет хакера.

3 способа борьбы с CSRF-атаками

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

  • Использование CSRF-токенов
  • Использование заголовка реферера
  • Выбор ориентированного на безопасность решения для хостинга, такого как Kinsta

Как предотвратить атаки CSRF с помощью токенов CSRF

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

Потенциальные уязвимости токенов CSRF

Хотя токены CSRF являются отличной мерой безопасности, этот метод не защищен от атак. Некоторые из уязвимостей, сопровождающих токены CSRF, включают:

  • Обход проверки — некоторые приложения пропускают этап проверки, если не находят токен. Если злоумышленник получает доступ к коду, содержащему токен, он может удалить этот токен и успешно выполнить атаку CSRF. Итак, если допустимый запрос к серверу выглядит так:
 POST /change_password POST body: password=pass123&csrf_token=93j9d8eckke20d433

Злоумышленнику нужно только удалить токен и отправить его вот так, чтобы выполнить атаку:

 POST /change_password POST body: password=pass123
  • Пулы токенов . Некоторые приложения поддерживают пул токенов для проверки пользовательских сеансов вместо того, чтобы назначать определенный токен для сеанса. Злоумышленнику достаточно получить один из уже находящихся в пуле токенов, чтобы выдать себя за любого из пользователей сайта.

Злоумышленник может войти в приложение, используя свою учетную запись, чтобы получить токен, например:

Боретесь с простоями и проблемами WordPress? Kinsta — это решение для хостинга, предназначенное для экономии вашего времени! Ознакомьтесь с нашими функциями
 [application_url].com?csrf_token=93j9d8eckke20d433

А поскольку токены объединены в пул, злоумышленник может скопировать и использовать тот же токен для входа в другую учетную запись пользователя, поскольку вы будете использовать его снова:

  • Токен CSRF может быть скопирован в файл cookie . Некоторые приложения копируют параметры, связанные с токеном, в файл cookie пользователя. Если злоумышленник получит доступ к такому файлу cookie, он может легко создать другой файл cookie, поместить его в браузер и выполнить атаку CSRF.

Таким образом, злоумышленник может войти в приложение, используя свою учетную запись, и открыть файл cookie, чтобы увидеть следующее:

 Csrf_token:93j9d8eckke20d433

Затем они могут использовать эту информацию для создания другого файла cookie для завершения атаки.

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

Как предотвратить CSRF-атаки с помощью заголовка Referrer

Другая стратегия предотвращения CSRF-атак — использование заголовка реферера. В HTTP заголовки реферера указывают источник запросов. Обычно они используются для выполнения аналитики, оптимизации и ведения журнала.

Вы также можете включить проверку заголовков реферера на стороне сервера, чтобы предотвратить CSRF-атаки. Сторона сервера проверяет исходное происхождение запроса и определяет целевое происхождение запроса. Если они совпадают, то запрос разрешен. Если есть несоответствие, сервер отбрасывает запрос.

Использование заголовков реферера намного проще, чем использование токенов, поскольку оно не требует индивидуальной идентификации пользователя.

Потенциальные уязвимости заголовка Referrer

Как и токены CSRF, заголовки реферера имеют ряд существенных уязвимостей.

Во-первых, заголовки реферера не являются обязательными, и некоторые сайты будут отправлять запросы без них. Если у CSRF нет политики для обработки запросов без заголовков, злоумышленники могут использовать запросы без заголовков для выполнения атак с изменением состояния.

Кроме того, этот метод стал менее эффективным с недавним введением политики реферера. Эта спецификация предотвращает утечку URL-адресов в другие домены, предоставляя пользователям больший контроль над информацией в заголовке реферера. Они могут открыть часть информации заголовка реферера или отключить ее, добавив тег метаданных на HTML-страницу, как показано ниже:

 <meta name="referrer" content="no-referrer">

Приведенный выше код удаляет заголовок реферера для всех запросов с этой страницы. Это усложняет приложениям, которые полагаются на заголовки реферера, предотвращение CSRF-атак с такой страницы.

Как Kinsta защищает от CSRF-атак

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

Помимо критически важных функций безопасности, таких как автоматическое резервное копирование, двухфакторная аутентификация и SFTP через протоколы SSH, интеграция Kinsta Cloudflare обеспечивает защиту корпоративного уровня с защитой на основе IP и брандмауэром.

В частности, в настоящее время Kinsta имеет около 60 настраиваемых правил брандмауэра, помогающих предотвращать вредоносные атаки и устранять серьезные уязвимости без проверки подлинности в плагинах и темах, в том числе определенные, которые ищут уязвимости CSRF.

Резюме

Подделка межсайтовых запросов (CSRF) — это атака, которая обманом заставляет аутентифицированных пользователей непреднамеренно инициировать запросы на изменение состояния. Они нацелены на приложения, которые не могут отличить действительные запросы на изменение состояния от поддельных.

CSRF может быть успешным только в приложениях, которые полагаются на файлы cookie сеанса для идентификации зарегистрированных пользователей и имеют слабую политику файлов cookie SameSite. Им также нужен сервер, который принимает запросы, не содержащие неизвестных параметров, таких как пароли. Хакеры могут отправлять вредоносные атаки, используя либо GET, либо POST.

Хотя использование токенов CSRF или принудительная проверка заголовка реферера могут предотвратить некоторые атаки CSRF, обе меры имеют потенциальные уязвимости, которые могут сделать ваши превентивные меры бесполезными, если вы не будете осторожны.

Переход на безопасную платформу хостинга, такую ​​как Kinsta, защищает ваши веб-сайты или веб-приложения от атак CSRF. Кроме того, интеграция Kinsta с Cloudflare предотвращает определенные атаки CSRF.