Кликджекинг

Ещё в 2002 году было замечено, что возможно наложить прозрачный слой поверх веб-страницы, и пользовательские действия будут применяться к этому слою без ведома пользователя^[7]. Однако первые исправления начали появляться лишь с 2004 года^[8], и общая проблема долгое время не воспринималась как серьёзная до 2008 года^[7].

В 2008 году Джереми Гроссман и Роберт Хансен обнаружили, что уязвимым к кликджекингу оказался Adobe Flash Player, что позволяло злоумышленникам получить доступ к компьютеру пользователя без его ведома^[7]. Термин «кликджекинг» предложили именно Гроссман и Хансен^[9], составив портманто из слов «клик» и «угон»^[7].

По мере обнаружения схожих атак термин «UI redressing» стали использовать для обозначения целого класса подобных атак, а не только самого кликджекинга^[7].

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

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

• Классический: осуществляется в веб-браузере^[7];
• Лайкджекинг: использует возможности Фейсбука и других соцсетей^[10][11];
• Вложенный: атакует Google+ с использованием наложенных фреймов^[12];
• Курсорджекинг: манипулирует визуальным отображением и положением курсора^[7];
• Маусджекинг: внедряет ввод с клавиатуры или мыши по беспроводному RF-каналу^[13];
• Вне браузера: задействует программы без использования браузера^[7];
• Кукиджекинг: похищение cookies из браузеров^[7][14];
• Файлджекинг: превращает атакуемое устройство в файловый сервер^[7][15][16]
• Атака на менеджер паролей: эксплуатирует уязвимости автозаполнения в браузерных менеджерах паролей^[7].

Предполагает, что злоумышленник с помощью невидимых слоёв на веб-странице перенаправляет действия мыши пользователя на другие элементы, что приводит к неправильной интерпретации действий пользователем^[17].

Пользователь может получить по электронной почте ссылку на видео с новостями, но поверх или под кнопкой «PLAY» может быть «спрятана» ещё одна страница, например, с товаром на Amazon. Пользователь пытается запустить видео, но на деле заказывает товар, если у него включен быстрый заказ и учётная запись активна.

Техническая реализация подобных атак может быть сложна из-за несовместимости браузеров, однако такие инструменты, как BeEF или Metasploit, позволяют почти полностью автоматизировать эксплуатацию уязвимых сайтов. Кликджекинг может сочетаться с другими веб-атаками, например межсайтовым скриптингом (XSS)^[18][19].

Лайкджекинг — это вредоносная технология, при которой пользователь обманывается и «ставит лайк» странице в Facebook или другим постам/аккаунтам в соцсетях без своего осознанного желания. Термин «лайкджекинг» предложил Кори Баллу в статье «How to „Like“ Anything on the Web»^[20], что стало одним из первых задокументированных упоминаний этой уязвимости «лайк»-кнопки^[21].

В издании IEEE Spectrum отмечается, что решение для противодействия лайкджекингу было разработано компанией Facebook на одном из хакатонов^[22]. Существуют специальные букмарклеты, которые позволяют обезопасить «лайк» вне стандартной кнопки Facebook^[23].

В отличие от классического варианта, вложенный кликджекинг использует вредоносный веб-фрейм между двумя уровнями исходной страницы: исходным фреймом и отображаемым окном. Это возможно благодаря уязвимости HTTP-заголовка X-Frame-Options, когда при значении SAMEORIGIN браузер проверяет только внешние два слоя, не учитывая наличие дополнительных вложенных^[12].

В частности, злоумышленники использовали ошибку Google+ и поисковика изображений Google, чтобы вставлять свои скрытые фреймы между уровнями отображения графики.

Курсорджекинг представляет собой приём по смещению или изменению отображения курсора, открыт в 2010 году исследователем Эдди Борди из vulnerability.fr^[24]. Маркус Нимиц показал это с помощью специального значка курсора, а Марио Хайдерих в 2012 году реализовал скрытие курсора^[25].

Жорди Шансель обнаружил уязвимость курсорджекинга во Firefox на Mac OS X, позволяющую выполнить произвольный код либо шпионить через веб-камеру^[26]. Эта проблема была решена в Firefox 30.0, а ещё одна схожая уязвимость устранена в Firefox 37.0^[27].

В отличие от других техник кликджекинга, маусджекинг связан с аппаратными уязвимостями: впервые описан в 2016 году Марком Ньюлином из Bastille.net, позволяет отправлять произвольные команды клавиатуры через уязвимые радиомодули^[28]. Logitech выпустила исправления, но другие производители отреагировали с опозданием^[29].

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

Данная форма атаки наиболее часто встречается на мобильных устройствах, особенно Android из-за специфики toast-уведомлений: между запросом уведомления и его отображением есть задержка, в течение которой под уведомлением можно создать невидимую кнопку, уязвимую к клику^[7].

Кукиджекинг представляет собой атаку, в ходе которой cookies похищаются из браузера пользователя путём обмана его видимыми объектами, которые на самом деле заставляют пользователя выделять и отправлять содержимое cookie^[14].

В атаках файлджекинга цель — использовать функции браузера по навигации по файловой системе и доступу к файлам для получения личных данных пользователя. Пользователь обманом переводит браузер в состояние активного файлового сервера, позволив тем самым злоумышленнику загружать необходимые файлы^[15].

Исследование 2014 года, проведённое в Университете Карнеги — Меллон, выявило, что некоторые менеджеры паролей неправильно заполняли пароли для HTTP-страницы, если изначально пароль сохранялся для HTTPS, а также были уязвимы к iframe- и редирект-атакам, что позволяло раскрывать ещё больше паролей при синхронизации между устройствами^[16].

Защита от кликджекинга (в том числе лайкджекинга) реализована в виде расширения NoScript для Mozilla Firefox: функция ClearClick, представленная 8 октября 2008 года, предотвращает щелчки по невидимым или подменённым элементам веб-документов и апплетов^[30]. По данным Browser Security Handbook от Google, ClearClick обеспечивает «значительный уровень защиты» от кликджекинга^[31]. С версии NoScript 2.2.8 RC1 добавлена защита и от курсорджекинга^[25].

Расширение NoClickjack реализует защиту от кликджекинга для Google Chrome, Mozilla Firefox, Opera и Microsoft Edge, не вмешиваясь в работу легальных iFrame. NoClickjack разработан на базе технологии GuardedID и доступен бесплатно.

Продукт GuardedID (коммерческий) реализует защиту от кликджекинга в Internet Explorer, принудительно делая все фреймы видимыми^[32]. GuardedID может работать в связке с NoClickjack для Chrome, Firefox, Opera и Microsoft Edge.

Gazelle — экспериментальный защищённый браузер Microsoft Research, реализующий операционно-системную модель безопасности с ограниченной защитой от кликджекинга: динамически меняемый контент одного окна может перекрывать окно другого происхождения только если он непрозрачен^[33].

API Intersection Observer v2^[34] позволяет отслеживать видимость элементов интерфейса так, как её воспринимает пользователь^[35]. Это помогает виджету обнаружить, что он перекрыт другим контентом. В Google Chrome функция включена по умолчанию с версии 74^[36], реализована и в других Chromium-совместимых браузерах.

Владельцы сайтов могут защитить пользователей от фрейм-ориентированного кликджекинга, вставляя в свои страницы специальный JavaScript-код- framekiller — так, чтобы страница не могла быть вложена в фрейм с другого источника^[31].

Однако JavaScript-защита не всегда надёжна, особенно в Internet Explorer^[31], где её можно обойти, используя элемент <IFRAME SECURITY=restricted>^[37].

В 2009 году в Internet Explorer 8 появился новый HTTP-заголовок X-Frame-Options для частичной защиты от кликджекинга^[38],^[39] который вскоре поддержали и другие браузеры (Safari^[40], Firefox^[41], Chrome^[42], Opera^[43]). Заголовок определяет политику вложенности: DENY — запрещает любую вложенность, ALLOW-FROM origin — разрешает только с указанного источника, SAMEORIGIN — только с того же сайта. Некоторые рекламные площадки возвращают нестандартное значение ALLOWALL, которое на практике не ограничивает вложение сайта.

В 2013 году X-Frame-Options был опубликован в RFC 7034^[44], однако официальным интернет-стандартом не является. W3C рекомендует вместо него использовать директиву frame-ancestors политики Content Security Policy Level 2^[45].

Однако X-Frame-Options не защищает от атак кликджекинга без фреймов^[46].

Директива frame-ancestors в Content Security Policy (с версии 1.1) позволяет разрешать или запрещать вложенность контента через iframe, object и т. п., и призвана заменить X-Frame-Options. При наличии обоих заголовков именно политика frame-ancestors должна использоваться браузером^[47], хотя старые браузеры могли это игнорировать^[48].

Примеры политики frame-ancestors:

# Запрет вложенности: всё встроенное содержимое станет недоступным.
Content-Security-Policy: frame-ancestors 'none'

# Разрешить вложенность только самому себе.
Content-Security-Policy: frame-ancestors 'self'

# Разрешить вложенность только указанным сайтам.
Content-Security-Policy: frame-ancestors www.example.com www.wikipedia.org