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

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

Методы JavaScript, используемые злоумышленниками

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

Давайте рассмотрим несколько распространенных методов, используемых злоумышленниками, когда они взламывают клиентский код (обычно через библиотеку JavaScript) для манипулирования приложением и кражи или просмотра данных.

Модификация DOM

DOM расшифровывается как Document Object Model, которая, согласно Mozilla, «… представление данных объектов, составляющих структуру и содержимое документа в сети». Другими словами, DOM - это ключевой компонент, представляющий веб-страницу и взаимосвязь между всеми ее элементами. Вредоносная модификация DOM - это любой код JavaScript, который изменяет веб-страницу, вводя новый код, который манипулирует DOM. Вредоносные библиотеки JavaScript могут использовать этот метод для выполнения фрагментов кода, которые будут представлять поддельный контент, отображать несанкционированную рекламу, создавать форму, предлагающую пользователю указать свой номер социального страхования или банковский счет, а также иным образом изменять предполагаемое визуальное восприятие или функциональность веб-сайта. в том виде, в котором он был изначально разработан оператором веб-сайта.

Доступ к данным хранилища браузера

Современные браузеры поддерживают несколько типов веб-хранилищ. Наиболее распространенными типами являются куки, сессионное хранилище и локальное хранилище. Каждый тип хранилища служит разным целям и имеет разную область применения. Общим для перечисленных выше объектов является то, что они обычно содержат конфиденциальные пользовательские данные. JavaScript, запущенный на веб-странице, имеет доступ почти ко всем типам хранилищ. Более того, JavaScript может считывать и изменять значения ключей хранилища. При этом он может получать доступ или изменять данные PII, токены социальных сетей, коды членства, ключи сеанса, истории пользователей, потоки кликов и многое другое.

Сетевой анализ и манипуляции

Код JavaScript может генерировать сетевые вызовы во всех типах протоколов, но он также имеет возможность обезьяны исправлять сетевую активность (расширять или изменять поддерживающее системное программное обеспечение локально) и тем самым изменять параметры сетевых вызовов, контент, заголовки и целевые домены. Он также может воспроизвести тот же сетевой запрос, клонировав все его содержимое и изменив целевой объект. Это может быть использовано для получения несанкционированного доступа к сетевым возможностям, чтобы браузер или веб-приложение выглядело как нечто, чем он не является, или для подделки личности пользователя.

Сбор данных

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

Опасности и истории из реальной жизни

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

Цифровой скимминг

Цифровой скимминг был повсюду в СМИ: группа Magecart взломала тысячи сайтов и украла миллионы данных кредитных карт со страниц платежей. Однако скимминг-эксплойты не новы; Изначально сообщение о Magecart поступило в 2016 году. Идея цифрового скимминга проста: тайно модифицируя легитимные библиотеки JavaScript с помощью вредоносного кода, злоумышленник отслеживает платежные транзакции, собирает номера кредитных карт и идентификаторы пользователей (и другие ключевые детали платежа) и отправляет их на указанный шлюз для регистрации. Обычный пользователь не может сказать, что его информация была утечкой, потому что исходная транзакция обрабатывается в обычном режиме. Оператор веб-сайта также не знает, что данные его пользователя были украдены.

Пример: Magecart является наиболее ярким примером цифрового скимминга и изначально ориентировался на интернет-магазины, работающие на платформе Magento. С тех пор он распространился на многие другие типы торговых платформ. Атаки Magecart следуют знакомой схеме. Хакеры-преступники взламывают серверную часть магазина, используя неизвестные или известные, но не исправленные уязвимости в программном обеспечении или в надстройках, используемых для многих приложений электронной коммерции. Затем хакер изменяет код сайта, направляя его на загрузку JavaScript, который будет отслеживать и записывать активность на конфиденциальных страницах, где платежная информация берется у клиента. Неверный JavaScript отправлял платежные данные на удаленный сервер, управляемый злоумышленниками. Десятки известных сайтов электронной коммерции были затронуты Magecart, часто месяцами не осознавая, что данные их пользователей копируются.

Атака на водопой

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

Пример. В ноябре 2018 года исследовательская группа компании ESET, занимающейся кибербезопасностью, опубликовала заметку об атаке на 21 веб-сайт, связанный с организациями в Камбодже, включая сайты правительственных агентств с высокой посещаемостью. Атака была организована, как заключили исследователи ESET, теневой группой под названием OceanLotus. В этом случае атака чрезвычайно сложна и состоит из нескольких шагов, позволяющих избежать обнаружения, использования нескольких IP-адресов для каждой атаки пользователя и нескольких этапов для проверки того, что пользователь соответствует желаемым критериям, прежде чем пытаться внедрить вредоносное ПО в локальную среду пользователя. В случае OceanLotus считается, что он в первую очередь ориентирован на сбор конфиденциальной информации от государственных органов, НПО и правозащитных организаций. Это означает, что команду OceanLotus спонсирует какой-то государственный деятель, заинтересованный в этой информации.

Взлом сеанса и учетных данных

Захват сеанса - это метод, используемый для кражи сеанса пользователей в протоколе, защищенном аутентификацией (например, OAuth), и обхода процедур аутентификации. JavaScript обращается к ресурсам хранилища пользователей в браузере или веб-приложении, где обычно хранятся токены социальных сетей и учетные данные сеанса. Таким образом, мошенническая библиотека JavaScript или внедрение кода могут перехватить сеансы пользователей и пройти аутентификацию от их имени, используя эти украденные учетные данные.

Примеры. Существует множество недавних и недавних примеров этих типов атак, которые могут включать в себя кражу всего, от информации, хранящейся в файлах cookie, до PII и других полезных форм финансовых или личных данных. В апреле 2018 года появились сообщения об эксплойте, в ходе которого хакеры-преступники захватывали данные пользователей Facebook с помощью сторонних трекеров JavaScript, включенных на сайты и веб-приложения, которые используют Войти через Facebook для регистрации и аутентификации пользователей. Согласно этим отчетам, эксплойт позволяет трекерам просматривать некоторые или все данные PII пользователя, предоставленные сайту. Эти данные PII могут включать имя, адрес электронной почты, пол, возрастную группу, пол, местонахождение и фото профиля. То, что трекеры на самом деле делали с данными, было неочевидно, но очевидно, что материнские компании, стоящие за трекерами, продают услуги издателям, чтобы помочь им заработать больше денег на основе данных, полученных от пользователей.

Внедрение поддельной рекламы и вредоносные перенаправления

В современной сети рекламные компании зарабатывают сотни миллиардов долларов, когда люди посещают веб-сайт, нажимают на объявления или смотрят видео. Мошенники также используют этот рынок с помощью мошенничества с рекламой и мошенничества с кликами. Злоумышленники обманным путем извлекают деньги из этих потоков, внедряя скомпрометированный код JavaScript в библиотеки или непосредственно на плохо защищенные веб-сайты. Этот вредоносный код JavaScript может отображать поддельную рекламу или автоматически нажимать несколько раз на объявления, отображаемые на странице. Поддельный JavaScript также может использоваться для перенаправления пользователей в другое место назначения, которое злоумышленник может использовать для сбора денег за клики, просмотры или партнерские покупки.

Пример. В апреле 2019 года в результате атаки на браузеры Google Chrome без исправлений на устройствах iOS около 500 миллионов пользователей подверглись атаке с перехватом сеанса, совершенной бандой eGobbler, известной киберпреступной организацией, имеющей долгая история так называемых атак с использованием вредоносной рекламы. В данном случае, как и команда, обнаружившая эксплойт в Confiant outline, эксплойт обошел основную функцию песочницы в приложениях iOS, которая не позволяет злоумышленникам устанавливать вредоносное ПО. В этой конкретной атаке захват сеанса использует взломанную веб-страницу с рекламным ПО. Пользователь нажимает на рекламу, которая, кажется, принадлежит хорошо известному бренду, но на самом деле используется для доставки вредоносного ПО. После того, как полезные данные будут доставлены, у пользователя будут неожиданные всплывающие окна, которые он не сможет закрыть. Когда пользователь нажимает на ссылки во всплывающем окне, банда eGobbler будет получать доход от кликов.

Криптоджекинг

Это новая форма злоупотребления JavaScript. Криподжекинг - это когда злоумышленники используют вычислительную мощь браузера или ЦП хост-машины для выполнения математических вычислений, необходимых для майнинга криптовалют, таких как BitCoin. Криптохакеры делают это с помощью взломанных библиотек JavaScript или скомпрометированных сторонних служб JavaScript. Незаконный майнинг осуществляется без ведома владельцев браузера или компьютера. Операторы сайтов, на которых запущен скомпрометированный JavaScript, также не знают, чему они подвергают своих пользователей. Криптоджекинг - это угроза, которую используют криминальные группы крипто-майнинга, такие как Coinhive. Эта группа взломала библиотеки JavaScript на нескольких популярных веб-сайтах для широкомасштабного мошенничества. Помимо того, что майнинг криптовалют является незаконным, он приводит к тому, что пользователи страдают от значительного падения производительности их Интернета и компьютеров.

Пример. Диспетчер пакетов узлов (NPM) - это реестр пакетов для всех пакетов, используемых для приложений, которые запускают NodeJS, популярный общедоступный язык сценариев на стороне сервера, использующий JavaScript. NPM загружается миллиарды раз в месяц операторами сайтов, обновляющими свои пакеты NodeJS. Поскольку они написаны на JavaScript, пакеты NodeJS часто используются для интеграции интерфейсных функций, таких как модули оплаты или инструменты чата. В ноябре 2018 года очень популярная библиотека NodeJS / JavaScript под названием Event-Stream, у которой было 2 миллиона загрузок в неделю, была взломана после того, как разработчик пакета устал от работы и передал ее кому-то еще на GitHub. Получатель Event-Stream внедрил код, который включал в себя программное обеспечение для майнинга криптовалюты, подвергая миллионы посетителей веб-сайтов, которые использовали этот пакет, размещению вредоносного ПО для криптовалюты на своих локальных машинах или браузерах.

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

Как защитить свое веб-приложение

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

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

CSP и услуги на основе политик

Сегодня веб-операторы могут выбрать один из двух способов обработки клиентских угроз и защиты своих ресурсов JavaScript от несанкционированного доступа.

CSP (Content Security Policy) - это защищенный HTTP-уровень, встроенный в современные браузеры. Используя CSP, веб-разработчик может применять правила контента к разрешенным активам. Это позволяет с высокой степенью детализации контролировать, какой контент может и не может быть изменен Javascript при загрузке веб-приложения. Замечательно. Обратная сторона? CSP управляется статическими тегами, которые нелегко обновить или изменить программно. В результате CSP требует полного повторного развертывания всего веб-приложения всякий раз, когда применяется новая политика. Хотя CSP блокирует любой код JavaScript, который не соответствует его правилам, он также может блокировать непредвиденные крайние случаи и влиять на взаимодействие с пользователем. Результат? Использование CSP для защиты содержимого приложения - хорошая идея, но компромисс заключается в том, что это приводит к более длительному и менее эффективному процессу разработки. Не менее важно, что если CSP используется ненадлежащим образом, он может значительно замедлить работу вашего веб-приложения, что повлияет на взаимодействие с пользователем.

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

Какой подход правильный?

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

Когда он определяет наличие аномалии, уровень безопасности должен оперативно принимать решения о том, какой ответ на запрос в браузере является правильным (обычно это дерево решений с такими параметрами, как предупреждение / разрешение / уменьшение). Таким образом, требования безопасности могут не отставать от динамического жизненного цикла библиотек JavaScript, а также иметь полный контроль и видимость любых внесенных изменений. До недавнего времени этот тип возможностей был невозможен из-за ограничений на мониторинг в реальном времени в глобальном масштабе, а также требований к ресурсам и задержкам алгоритмов машинного обучения, которые должны управлять этой технологией. Подробнее об этом мы расскажем в следующем посте.