ОБЪЕДИНЕНИЕ ЛИДЕРОВ НЕФТЕГАЗОВОГО СЕРВИСА И МАШИНОСТРОЕНИЯ РОССИИ
USD 92,26 -0,33
EUR 99,71 -0,56
Brent 0.00/0.00WTI 0.00/0.00

Централизованный Интернет

В современном Интернете очень многое связано между собой. Иногда связи образуют довольно неочевидные слои, которые соответствуют разным уровням использования интернет-технологий. Несмотря на то, что Интернет продолжают называть «децентрализованным объединением сетей», централизация в нём присутствует и часто даёт о себе знать (например, в виде неожиданных последствий блокировок каких-то узлов сети по IP-адресу).

Внешние библиотеки

Около трети веб-сайтов Рунета существенным образом зависят от внешних библиотек, где хранится программный код, исполняемый браузером при отображении веб-страницы. Бо́льшая часть такого рода зависимостей связана с узлами Google, Cloudflare, Facebook; прекращение доступа к этим узлам приведёт к тому, что использующие их ресурсы веб-сайты, размещённые на российском хостинге под российским доменным именем, перестанут нормально работать.

Поясним подробнее. Основой современной веб-разработки (как и программирования вообще) является использование заимствованного программного кода. Пуристов, которые предпочитают все аспекты веб-страницы реализовывать самостоятельно, используя только базовые конструкции HTML/CSS/JavaScript, осталось слишком мало. Все остальные заимствуют код из библиотеки (в случае, если сайт разрабатывается на JavaScript) и фреймворки (типовые фрагменты кода – ред.), которые используются практически повсеместно. Наиболее известные примеры – jQuery, Angular, Bootstrap и другие, эти названия прекрасно знакомы веб-разработчику.

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

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

Поясним на примере. Пусть основной веб-сайт расположен под доменом test.ru и использует jQuery (библиотека функций на JavaScript – ред.) – без этой библиотеки страницы сайта не работают (чтобы понять, что это значит, попробуйте отключить исполнение JavaScript в браузере и походить по сайтам).

Разработчик мог бы разместить копию кода библиотеки jQuery под тем же доменом, что и основной сайт, например, по адресу https://test.ru/static/libs/jQuery-current.js. Однако вместо этого он использует некоторую специализированную CDN, указывая адрес https://cdn.example.com/jquery/jQurey-current.js.

Счётчики посещаемости - особо опасные библиотеки

Формально к JavaScript-библиотекам могут быть отнесены системы веб-аналитики, прежде всего Google Analytics и «Яндекс.Метрика». Это тоже внешние библиотеки кода, но с существенной особенностью: их нельзя скопировать на собственный узел. Системы веб-аналитики собирают большое число данных о действиях пользователя на сайте. Несмотря на то, что существуют локальные системы веб-аналитики, использование внешних систем остаётся весьма распространённым: к сожалению, они повсеместно встречаются даже на сайтах банков.

Так и образуется дополнительный слой связей – на уровне приложений. Веб-сайт, размещённый под адресом test.ru, оказывается зависим от файла, размещённого под доменом example.com. При этом от внешнего узла example.com оказывается зависим и посетитель сайта test.ru. Если что-то не так с внешней библиотекой, посетитель сайта test.ru этот сайт просто не увидит. Более того, сторона, имеющая контроль над внешней библиотекой, может практически как угодно изменить веб-страницу на стороне пользователя, прямо в браузере. (Дополнительно отметим, это важно: для доступности сайта критическое значение имеют не только доменные имена вроде cdn.example.com, но также IP-адреса узлов, с которых загружаются библиотеки.)

Данные в обмен на программный код

При обращении к внешнему (дополнительному) узлу браузер передаёт ему довольно много метаинформации. Так, уже в самом HTTP-запросе передаётся IP-адрес точки подключения к Интернету клиента, некоторые параметры браузера и операционной системы, имя основного сайта, cookie-файлы (небольшие файлы-идентификаторы, которые браузер сохраняет по команде сайта – ред.). Так как для обнаружения IP-адреса узла, с которого будет загружаться библиотека, используется DNS (сервис поиска адресной информации по доменному имени – ред.), то внешний сервис также получает информацию о настройках и адресах этой системы у клиента.

Шрифты опасны тоже

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

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

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

Веб-шрифты, как правило, загружаются из репозитория Google (fonts.googleapis.com), а также с других узлов, принадлежащих специализированным контент-провайдерам. То же относится и к распространённым CSS-фреймворкам.

Таков ещё один жёстко централизованный «слой» Интернета.

И о главном

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

На первый взгляд может показаться, что библиотека выполняет только те функции, ради которых её использовал веб-разработчик. Но это не так: программный код библиотеки может быть изменён владельцем узла, с которого библиотека загружается (либо третьей стороной на пути до клиента), после чего она сможет реализовать какой угодно набор функций, например, собрать пользовательские данные со страницы, изменить её содержание, сделать просмотр недоступным, перенаправить браузер на произвольный адрес и так далее, и тому подобное. В некоторых современных браузерах существует механизм базовой защиты от подмены исходного кода встраиваемых библиотек под названием Subresource Integrity (SRI), но на практике этот механизм ни на каких сайтах не используется.

Резюме

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

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

  • конкретные IP-адреса (т.е. конкретных пользователей);
  • конкретные типы браузеров;
  • определённое время;
  • любую комбинацию этих настроек.

То есть даже если администратор исходного веб-ресурса, test.ru в нашем примере, пытается как-то отследить корректность работы узлов, на которых находятся используемые библиотеки, он не в состоянии этого сделать: для IP-адресов, с которых проводится проверка, всё может работать корректно, при этом для других посетителей сайта картина окажется совсем другой.

Подмена библиотек

До массового внедрения протокола защищённой передачи данных HTTPS подмена библиотек являлась распространённым и весьма эффективным вектором активных атак, которые строились либо на перехвате TCP-соединений, подмене IP-адресов, либо на подмене DNS-ответов. HTTPS чрезвычайно затрудняет такую атаку. Загрузка библиотеки с подставного узла, использующего невалидный серверный TLS-сертификат (необходим для установления HTTPS-соединения – ред.), скорее всего, будет заблокирована браузером. Но если у атакующего имеется валидный сертификат (маловероятно, но возможно), то атака реализуема и по HTTPS. Важно заметить, что даже простое блокирование загрузки библиотеки для многих веб-страниц оказывается фатальным: работа с сайтом для пользователя будет невозможна. Подобное блокирование не обязательно является некоторой целевой атакой, узел CDN, раздающий файлы библиотек, может быть по тем или иным причинам внесён в реестр блокируемых провайдерами сайтов или оказаться вне доступа по любым иным причинам.

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

Рекомендации

На основной массе сайтов подключение внешних библиотек можно признать допустимым. Но это практикуется на сайтах государственных органов, на банковских сайтах и сайтах крупнейших российских СМИ, где, конечно, подобная практика вряд ли уместна.

Пример от редакции

Внешние библиотеки и шрифты, используемые сайтом крупного российского государственного СМИ

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

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

Нередко веб-мастер просто не знает, как скопировать файлы библиотек, поскольку использует инструменты более высокого уровня – например, CMS (систему управления контентом). Либо возможность «локального» размещения ресурсов недоступна технически («конструкторы сайтов» и т.п.).

Но практически во всех случаях возможно отказаться от внешнего размещения библиотек, скопировав их на веб-узел, находящийся под тем же административным управлением, что и основной сайт (традиционная рекомендация: вынести соответствующий адрес в поддомен, например, static.test.ru). Такой подход позволит вернуть вебу необходимую распределённость, децентрализованность.

Независимо от того, перенесли вы библиотеки или нет, необходимо внедрить HTTPS (безопасный протокол существенно снизит риск активной атаки на пользователей сайта) и использовать встроенные в браузер механизмы защиты подлинности кода библиотек, механизмы ограничения источников скриптов для страницы (Subresource Integrity (SRI), специализированные HTTP-заголовки).

Об авторе: Александр Венедюхин, ведущий аналитик в компании «Технический центр Интернет».

Дополнительная информация

Идет загрузка следующего нового материала

Это был последний самый новый материал в разделе "Цифровые технологии"

Материалов нет

Наверх