Атака вида «межсайтовая подделка запросов» (CSRF)

CSRF – известная также, как XSRF – одна из опасных атак на веб-пользователей, приводящая к выполнению на определённом сайте различных действий от имени зарегистрированных пользователей, на которых была направлена атака.

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

CSRF обычно проводят, используя методы социального инжиниринга. Зачастую злоумышленники используют банальный переход ссылке (например, из электронного письма, которое отправляют жертве) или также используют фишинговые сайты (Рис. 1,2).

Рисунок 1. Пример фишингового письма

Рисунок 2. Пример фишингового сайта

Пользователь переход на сайт, где скрытым образом от его имени отправляется запрос на нужный ресурс. Если пользователь был на нём авторизован (а это значит, что у него есть активная сессия в cookie), то запрос выполняется незаметно для самого пользователя. Схематически атаку можно представить в виде следующей схемы (Рис. 3).

Рисунок 3. Схема стандартной CSRF атаки

Рассмотрим простой пример атаки CSRF. До выполнения нападения, злоумышленник обычно очень тщательно изучает необходимый ему Интернет-ресурс с целью составления возможного валидного запроса. Например, стандартный GET запрос, например, на перевод 100$ мог бы выглядеть следующим образом (Рис. 4):

Рисунок 4. Пример GET запроса

Потенциальный хакер может модифицировать запрос таким образом, чтобы деньги перечислялись именно на его собственный счёт (Рис. 5):

Рисунок 5. Пример модифицированного GET запроса

И встроить это запрос, например, в HTML-тег <a> (Рис. 6):

Рисунок 6. Встраивание запроса в HTML-тег

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

Стоит обратить внимание на то, что, если веб-сайт при выполнении данной операции принимает только POST запросы, то невозможно будет сформировать нужное обращение к серверу, используя тег <a>. Однако атаку при этом всё также можно провести, используя только теперь тег <form> вкупе с автоматическим выполнением JavaScript. Такой приём может выглядеть так (Рис. 7):

Рисунок 7. Атака с использованием POST запроса

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

·     Выход из личных аккаунтов тех сайтов, которые больше не используются.

·     Сохранение в защищённом состоянии логинов и паролей.

·     Не позволять браузерам сохранять ваши пароли.

·     При входе в важные аккаунты, закрывать сторонние источники.

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

Двойная генерация cookie также является известный способом блокирования атак подобного рода. Более того эффективными являются методы встраивания токенов в целый ряд пунктов, в том числе историю браузеров, файлы журналов HTTP, строку запроса на HTTP, а также заголовки рефереров, если защищаемый сайт имеет ссылку на внешний URL.

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

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

Используя IncapRules, вы можете создать для себя такие настройки, которые позволяют фильтровать запросы к подозрительным страницам и функциям, составлять списки проверенных доменов.

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