Кликджекинг (UI redressing)
Что такое кликджекинг
Кликджекинг — атака на основе интерфейса, при которой пользователя обманом заставляют кликнуть на полезный контент на скрытом веб-сайте, нажав на какой-либо другой контент на веб-сайте приманке. Рассмотрим следующий пример:
Веб-пользователь заходит на веб-сайт приманку (возможно, это ссылка доставленная по электронной почте) и нажимает кнопку, чтобы выиграть приз. По незнанию он был обманут злоумышленником, который нажал альтернативную скрытую кнопку, что привело к оплате счёта на другом сайте. Это пример атаки кликджекинга. Этот метод зависит от включения веб-страницы (или нескольких веб-страниц), содержащей кнопку или скрытую ссылку, скажем, внутри iframe. iframe накладывается поверх предполагаемого содержимого веб-страницы приманки. Эта атака отличается от CSRF атаки тем, что от пользователя требуется выполнить действие, такое как клик по кнопке, тогда как атака CSRF зависит от подделки всего запроса без ведома или ввода пользователя.
Защита от CSRF-атак часто обеспечивается использованием CSRF токена: одноразового номера для конкретного сеанса или одноразового номера. Атаки кликджекинга не нейтрализуются CSRF токеном, поскольку сеанс устанавливается с контентом, загруженным с подлинного веб-сайта, и все запросы выполняются в домене. Токены CSRF помещаются в запросы и передаются на сервер как часть обычного сеанса. Отличие от обычного пользовательского сеанса заключается в том, что процесс происходит внутри скрытого iframe.
Как построить базовую кликджекинг атаку
Кликджекинг атаки используют CSS для создания слоёв и управления ими. Атакующий включает целевой веб-сайт в виде слоя iframe, наложенного на веб-сайт приманку. Пример использования тега style и параметров выглядит следующим образом:
<head>
<style>
#target_website {
position:relative;
width:128px;
height:128px;
opacity:0.00001;
z-index:2;
}
#decoy_website {
position:absolute;
width:300px;
height:400px;
z-index:1;
}
</style>
</head>
...
<body>
<div id="decoy_website">
...decoy web content here...
</div>
<iframe id="target_website" src="https://vulnerable-website.com">
</iframe>
</body>iframe целевого веб-сайта размещается в браузере таким образом, чтобы обеспечить точно перекрытие целевого действия с веб-сайтом приманкой, с использованием соответствующих значений ширины и высоты положения. Абсолютные (position:absolute) и относительные (position:relative) значения положения используются для того, чтобы целевой веб-сайт точно перекрывал приманку независимо от размера экрана, типа браузера и платформы. z-index определяет порядок размещения слоёв iframe и веб-сайта. Значение opacity задаётся как 0.0 (или близкое к 0.0), чтобы содержимое iframe было прозрачным для пользователя. Защита от кликджекинга в браузере может применять обнаружение прозрачности iframe на основе порогового значения (например, Chrome версии 76 включает это поведение, а Firefox — нет). Атакующий выбирает значение opacity таким образом, чтобы желаемый эффект был достигнут без срабатывания защитных действий.
Кликджекинг с предварительно заполненной формой ввода
Некоторые веб-сайты требующие заполнения и отправки формы, разрешают предварительное заполнение полей формы с использованием параметров GET перед отправкой. Другие веб-сайты могут потребовать ввести текст перед отправкой формы. Поскольку значение GET является частью URL-адреса, целевой URL-адрес может быть изменён для включения значений по выбору злоумышленника, а прозрачная кнопка submit
накладывается на сайт-приманку, как в базовом примере кликджекинга.
Скрипты разрыва frame
Кликджекинг атаки возможны всякий раз, когда сайт может быть помещён во frame. Таким образом, превентивные методы основаны на ограничении возможности создания фреймов для веб-сайтов. Обычная защита на стороне клиента, реализуемая через веб-браузер, заключается в использовании сценариев ломающих или прерывающих фреймы. Их можно реализовать с помощью проприетарных надстроек или JavaScrip-расширений для браузера, таких как NoScript. Сценарий часто разрабатываются таким образом, чтобы они выполняли некоторые или все из следующих действий:
- проверить и обеспечить, чтобы текущее окно приложения было главным или
window.top, - сделать все фреймы видимыми,
- предотвратить клики на невидимые фреймы,
- перехватывать и помечать как потенциальные кликджекинг атаки пользователя.
Методы блокировки фреймов часто зависят от браузера и платформы, и из-за гибкости HTML атакующие часто могут их обойти. Поскольку блокировщик фреймов — это JavaScript, настройки безопасности браузера могут помещать их работе, или браузер может даже не поддерживать JavaScript. Эффективный обходной путь атакующего против прерывателя фреймов — использование HTML5 атрибута iframe sandbox. Если это установлено со значениями allow-forms или allow-scripts, а значение allow-top-navigation опущено, то сценарий блокировки фреймов можно нейтрализовать, поскольку iframe не может проверить, является ли он window.top.
<iframe id="victim_website" src="https://victim-website.com" sandbox="allow-forms"></iframe>Оба allow-forms и allow-scripts разрешают указанные действия в iframe, но навигация верхнего уровня отключена. Это запрещает прерывание фреймов, но обеспечивает функциональность на целевом сайте.
Комбинирование кликджекинга с DOM XSS атакой
До сих пор мы рассматривали кликджекинг как автономную атаку. Исторически кликджекинг использовался для выполнения таких действий, как накрутка лайков. Однако истинная мощь кликджекинга раскрывается, когда он используется в качестве носителя для другой атаки, такой как DOM XSS атака. Реализация этой комбинированной атаки относительно проста, если предположить, что атакующий сначала идентифицировал XSS эксплойт. Затем XSS эксплойт объединяется с целевым URL-адресом iframe, так что пользователь кликая по кнопке или ссылке выполняет DOM XSS атаку.
Многошаговый кликджекинг
Атакующему, манипулирующему входящими данными на целевом веб-сайте, может потребовать выполнить несколько действий. Например, атакующий может захотеть обманом заставить пользователя купить что-то на веб-сайте, для этого товары нужно добавить в корзину. Эти действия могут быть реализованы атакующим с использованием нескольких iframe. Такие атаки требуют значительной точности и осторожности с точки зрения атакующего, если он хочет быть эффективным и незаметным.
Как предотвратить кликджекинг атаку
Мы обсудили часто встречающиеся механизмы предотвращения кликджекинг атак на стороне браузера, а именно сценарии блокировки фреймов. Однако мы видели, что атакующему часто несложно обойти эту защиту. Следовательно, были разработаны протоколы, управляемые сервером ограничивающие использование браузером iframe и снижающие риск кликджекинга.
Кликджекинг — это поведение на стороне браузера, и его успех тем или иным образом зависит от функциональности браузера и соответствия преобладающим веб-стандартам и передовой практике. Защита на стороне сервера от кликджекинга обеспечивается путём определения и передачи ограничений на использование таких компонентов, как iframe. Однако реализация защиты зависит от соответствия браузера и соблюдения этих ограничений. Двумя механизмами защиты от кликджекинга на стороне сервера являются X-Frame-Options и Content Security Policy.
X-Frame-Options
X-Frame-Options изначально был представлен как неофициальный заголовок ответа в Internet Explorer 8 и быстро был принят в других браузерах. Заголовок предоставляет владельцу сайта контроль над использованием iframe и objects, поэтому включения веб-страницы во фрейм можно запретить с помощью директивы deny:
X-Frame-Options: denyКроме того, заключение во фрейм может быть ограничено тем же источником, что и веб-сайт, с помощью директивы sameorigin
X-Frame-Options: sameoriginили на указанный веб сайт с помощью директивы allow-from:
X-Frame-Options: allow-from https://normal-website.comX-Frame-Options не реализовано последовательно в разных браузерах (например, директива allow-from не поддерживает Chrome версии 76 или Safari 12). Однако при правильном сочетании с Content Security Policy в рамках многоуровневой стратегии защиты она может обеспечить эффективную защиту от атак с использованием кликджекинга.
Content Security Policy (CSP)
Политика Безопасности Контента (CSP) — это механизм обнаружения и предотвращения, обеспечивающий смягчение последствий таких атак, как XSS и кликджекинг. CSP обычно реализуется на веб-сервере в виде возвращаемого заголовка вида:
Content-Security-Policy: policyгде policy — это строка директива политик, разделённых точкой с запятой. CSP представляет клиентскому браузеру информацию о разрешённых источниках веб-ресурсов, которые браузер может использовать для обнаружения и перехвата вредоносного поведения.
Рекомендуемой защитой от кликджекинга является включение директивы frame-ancestors в Content Security Policy содержимого приложения. Директива frame-ancestors 'none' по своему поведению похожа на директиву X-Frame-Options: deny. Директива frame-ancestors 'self' в целом эквивалентна директиве X-Frame-Options: sameorigin. Следующие CSP вносят фреймы в белый список только для одного и того же домена:
Content-Security-Policy: frame-ancestors 'self';В качестве альтернативы, заключение в фреймы может быть ограничено перечисленными сайтами:
Content-Security-Policy: frame-ancestors normal-website.com;Для эффективной защиты от кликджекинга и XSS, CSP требует тщательной разработки, внедрения и тестирования и должны использоваться как часть многоуровневой стратегии защиты.