Clickjacking — это атака на основе интерфейса, при которой пользователя обманом заставляют щелкнуть по полезному контенту на скрытом веб-сайте, щелкнув какой-либо другой контент на фиктивном веб-сайте.
Рассмотрим пример:
Пользователь заходит на веб-сайт-приманку (возможно по ссылке, пришедшей по электронной почте) и видит очень выгодное предложение или сообщение о крупном выигрыше. Для получения предложения необходимо нажать на кнопку, после чего выигрыш будет начислен пользователю. Пользователь нажимает на кнопку и по незнанию становится обманутым. На самом деле он нажал не на кнопку получения приза, а на кнопку, скрытую за кнопкой получения подарка, что привело к оплате счета на другом сайте.
Этот метод зависит от включения невидимой веб-страницы (или нескольких страниц), содержащей кнопку или скрытую ссылку, скажем, внутри iframe. Кадр iframe накладывается поверх предполагаемого содержимого веб-страницы-приманки пользователя.
Для того чтобы уметь защищаться, нам нужно знать, как происходит атака, а для этого можно привести базовый пример.
Атаки Clickjacking используют CSS для создания слоев и управления ими. Злоумышленник включает целевой веб-сайт в виде слоя iframe, наложенного на веб-сайт-приманку. Пример использования тега стиля и параметров выглядит следующим образом:
Frame целевого веб-сайта размещается в браузере таким образом, чтобы обеспечить точное перекрытие целевого действия с веб-сайтом-приманкой с использованием соответствующих значений ширины и высоты положения. Абсолютные и относительные значения положения используются для того, чтобы целевой веб-сайт точно перекрывал обманку, независимо от размера экрана, типа браузера и платформы. Z-индекс определяет порядок размещения слоев iframe и веб-сайта. Значение непрозрачности определяется как 0,0 (или близко к 0,0), чтобы содержимое iframe было прозрачным для пользователя.
Теперь стало понятно, как работают атаки кликджекинга. Давайте рассмотрим, как предотвратить их и сделать свой сайт безопаснее.
Учтите, что ядро атаки – это возможность включить любой веб-сайт или приложение в iframe. Это означает, что атака кликджекинга может затронуть любой тип приложения, независимо от технологии или инфраструктуры, использованной для его создания. Таким образом, уязвимы не только обычные веб-приложения, но и React, Angular и другие приложения.
Самым старым вариантом защиты является код JavaScript, запрещающий открытие страницы во фрейме.
В этом случае, если окно обнаруживает, что оно открыто во фрейме, оно автоматически располагает себя сверху. Но мы можем заблокировать переход, вызванный сменой top.location в обработчике события beforeunload.
Внешняя страница (принадлежащая хакеру) устанавливает обработчик на это событие, отменяющий его. Например, такой:
Надёжный метод защиты - это Политика безопасности контента (CSP). Все основные браузеры поддерживают заголовок X-Frame-Options.
CSP предоставляет клиентскому браузеру информацию о разрешенных источниках веб-ресурсов, которые браузер может использовать для обнаружения и перехвата вредоносного поведения.
В этой статье мы рассмотрели одну из множества уязвимостей для веб-приложения. В следующей части мы продолжим разбираться с этой темой и узнаем, как сделать своё веб приложение ещё безопасней.
Cross Site Request Forgery (CSRF)
Подделка межсайтовых запросов (CSRF) — это атака, которая заставляет конечного пользователя выполнять нежелательные действия в веб-приложении, в котором он в настоящее время аутентифицирован. С небольшой помощью социальной инженерии (например, отправив ссылку по электронной почте или в чат) злоумышленник может обманом заставить пользователей веб-приложения выполнить действия по выбору злоумышленника.
Эта форма эксплойта также называется атакой одним щелчком или ездой на сеансе, так как атака использует ранее прошедший проверку подлинности сеанс пользователя.
Посмотрим на примере, как работает атака.
Ваня хочет перевести деньги на благотворительность и входит в систему www.my-bank.example.com с помощью проверки подлинности. Сервер проверяет подлинность пользователя и выдает ответ, включающий проверку подлинности cookie. Сайт уязвим для атак, так как он доверяет любому запросу, который он получает после уже прошедшей проверки cookie при авторизации в системе.
Далее пользователь посещает вредоносный сайт. Представим, что ему пришло письмо на электронную почту о выигрыше в лотерею, и при клике на кнопку пользователь попадает на сайт www.evil-not-bank.example.com.
Вредоносный сайт www.evil-not-bank.example.com. содержит HTML-форму:
Обратите внимание, что формы action публикует сообщения на уязвимом сайте, а не на вредоносном сайте. Это "межсайтовая" часть CSRF. Так вышло, что злоумышленник знал о том, что Ваня пользуется системой www.my-bank.example.com. и негодяю осталось лишь надеяться, что Ваня уже авторизован на сайте www.my-bank.example.com и нажмёт на кнопку.
Пользователь нажимает кнопку отправить. Браузер отправляет запрос и автоматически включает проверку подлинности cookie для запрошенного домена www.my-bank.example.com
Запрос выполняется на сервере www.my-bank.example.com с контекстом проверки подлинности пользователя и может выполнять любое действие, которое может выполнять пользователь, прошедший проверку подлинности.
Некоторые атаки направлены на конечные точки, использующие GET запросы.
Давайте рассмотрим следующий пример: Алиса хочет перевести 100 долларов Бобу, используя веб-приложение bank.com, уязвимое для CSRF. Злоумышленник Мария хочет обманом заставить Алису отправить деньги Марии. Атака будет состоять из следующих шагов:
- Создание URL-адреса или сценария эксплойта
- Обманом заставить Алису выполнить действие с помощью социальной инженерии
Если приложение было разработано, чтобы в основном использовать GET-запросы для передачи параметров и выполнения действий, операция перевода денег может быть сведена к запросу, например:
GET http://bank.com/transfer.do?acct=BOB&amount=100 HTTP/1.1
Теперь Мария решает использовать эту уязвимость веб-приложения, используя Алису в качестве жертвы. Сначала Мария создает следующий URL-адрес эксплойта, который переведет 100 000 долларов со счета Алисы на счет Марии. Мария берет исходный URL-адрес команды и заменяет имя получателя на себя, одновременно значительно увеличивая сумму перевода:
http://bank.com/transfer.do?acct=MARIA&amount=100000
Социально-инженерный аспект атаки заставляет Алису загрузить этот URL-адрес, когда Алиса входит в банковское приложение. Обычно это делается с помощью одного из следующих методов:
- Отправка нежелательного электронного письма с содержимым HTML;
- Установка URL-адреса или скрипта эксплойта на страницы, которые могут быть посещены жертвой, в то время как они также осуществляют онлайн-банкинг.
URL-адрес эксплойта может быть замаскирован под обычную ссылку, побуждая жертву перейти по ней:
<a href="http://bank.com/transfer.do?acct=MARIA&amount=100000">View my Pictures!</a>
Или как поддельное изображение 0x0:
<img src="http://bank.com/transfer.do?acct=MARIA&amount=100000" width="0" height="0" border="0">
Если бы этот тег изображения был включен в электронное письмо, Алиса ничего бы не увидела. Однако браузер по-прежнему отправит запрос на bank.com без каких-либо визуальных указаний на то, что перевод состоялся.
Реальным примером CSRF-атаки на приложение, использующее GET, был эксплойт uTorrent 2008 года, который использовался в массовом масштабе для загрузки вредоносного ПО.
Как от этого можно защититься?
Шаблон токена синхронизатора — один из самых популярных и рекомендуемых методов смягчения последствий CSRF.
Токены CSRF должны генерироваться на стороне сервера. Они могут генерироваться один раз за сеанс пользователя или для каждого запроса. Токены на запрос более безопасны, чем токены на сеанс, поскольку диапазон времени, в течение которого злоумышленник может использовать украденные токены, минимален.
Однако это может привести к проблемам с удобством использования. Например, функция браузера с кнопкой «Назад» часто затруднена, так как предыдущая страница может содержать токен, который больше не действителен. Взаимодействие с этой предыдущей страницей приведет к ложноположительному событию безопасности CSRF на сервере. В реализации токена для сеанса после первоначального создания токена значение сохраняется в сеансе и используется для каждого последующего запроса до истечения срока действия сеанса.
Когда запрос выдается клиентом, компонент на стороне сервера должен проверить существование и действительность токена в запросе по сравнению с токеном, найденным в пользовательском сеансе. Если токен не был найден в запросе или предоставленное значение не соответствует значению в сеансе пользователя, то запрос следует отклонить. Также следует учитывать дополнительные действия, такие как запись события в журнал как потенциальную атаку CSRF.
Токены CSRF должны быть:
- Уникальными для сеанса пользователя.
- Секретными
- Непредсказуемыми (большое случайное значение, сгенерированное безопасным методом ).
Токены CSRF предотвращают CSRF, потому что без токена злоумышленник не может создавать действительные запросы к внутреннему серверу.
Двойная отправка файла cookie
Если сохранение состояния токена CSRF на сервере проблематично, альтернативной защитой является использование метода двойной отправки файла cookie. Этот метод прост в реализации и не имеет состояния. В этом методе мы отправляем случайное значение как в файле cookie, так и в качестве параметра запроса, при этом сервер проверяет, совпадают ли значение файла cookie и значение запроса.
Для повышения безопасности этого решения включите токен в зашифрованный файл cookie — отличный от файла cookie аутентификации (поскольку они часто используются в поддоменах), — а затем на стороне сервера сопоставьте его (после расшифровки зашифрованного файла cookie) с токеном в скрытом поле формы или параметр/заголовок для вызовов AJAX. Это работает, потому что поддомен не может перезаписать правильно созданный зашифрованный файл cookie без необходимой информации, такой как ключ шифрования.
