Примечание. Следующая статья была опубликована 16 января 2017 г. на https://FogMarks.com
Как и было обещано в последнем кейсе, сегодня мы увидим очень интересный кейс с интересным поворотом.
E
кажется, что многие любят jQuery. Эта замечательная библиотека Javascript повсюду, куда бы я ни посмотрел — десятки тысяч компаний используют ее в своих веб-приложениях, и это очень удобно — особенно когда речь идет об AJAX-запросах — импорт jQuery делает нашу жизнь намного проще.
Библиотека библиотек
jQuery не одинок. Google и Microsoft (а иногда и Mozilla и Apple, Facebook и Twitter) постоянно выпускают новые JS-библиотеки и советуют разработчикам использовать их и импортировать в свои продукты. Например, если вы хотите воспроизвести видео в формате QuickTime, вам следует импортировать JS-библиотеку QuickTime от Apple, а если вам нужен аккуратный jQuery DatePicker, вам следует импортировать эту библиотеку из Google, jQuery или любого другого зеркала.
Подсчитайте, сколько раз я использовал слово «импорт» в последнем абзаце. Сделанный? 4 раза.
Всякий раз, когда мы хотим использовать определенную публичную библиотеку JS, принадлежащую определенной компании или сервису, мы напрямую импортируем ее из этой компании.
Чтобы было понятнее, мы просто размещаем ‹скрипт › тег на нашем веб-сайте со свойством src, указывающим на адрес файла JS:
‹script src="http/s://trustworthydomain.com/path/to/js/file.js›‹/script›
Ты понял? Мы загружаем скрипт с другого веб-сайта — стороннего веб-сайта — в контекст нашего веб-сайта. Мы нарушаем правило номер один веб-безопасности — мы доверяем другому веб-сайту!
Теперь это может звучать немного глупо
Почему я не могу импортировать скрипт из надежной компании, такой как jQuery, Microsoft или Google? И вы правы. Вроде.
Когда вы импортируете скрипт из надежной компании, в 90% случаев вы будете импортировать его из CDN компании.
CDN расшифровывается как Content Delivery Network, и это (в кавычках:) «система распределенных серверы (сети), которые доставляют веб-страницы и другой веб-контент пользователю в зависимости от географического местоположения пользователя, источника веб-страницы и сервера доставки контента».
Это услуга хостинга, которая предоставляет услуги хранения клиентам компании в зависимости от их местоположения и некоторых других факторов. Импортируемый вами файл JS не хранится на официальном сервере компании (опять-таки в большинстве случаев).
В этом кейсе мы увидим, как очень популярная компания попалась на эту удочку.
Эта компания (которую мы, конечно, не можем раскрыть) разработала популярную JS-библиотеку и разместила ее на сторонней CDN, которую они купили. Этот CDN был «умным» и перенаправлял пользователей на ближайший сервер в зависимости от местоположения пользователя:
Когда запрос поступил на главный сервер, сервер определил местоположение IP-адреса запроса, а затем перенаправил запрос на ближайший сервер в соответствии с определенным местоположением.
Десятки веб-сайтов внедрили в свой исходный код тег ‹script src›, указывающий на CDN основного сервера этой компании, и он предоставил своим пользователям необходимую библиотеку JS.
(не)приятный сюрприз
Проведя некоторое исследование сервера Apache, который был установлен на сервере C (Копия C на изображении), мы пришли к выводу, что его версия действительно устарела и что он уязвим для атаки с загрузкой произвольных файлов, что позволило нам загрузить файл в CDN (но не для выполнения кода).
Не так уж и серьезно, на первый взгляд.
Но! Когда мы исследовали способ загрузки файла, естественно, неавторизованно, мы увидели, что можно использовать Обход каталога на пути к файлу. Мы просто изменили имя файла на ../../../‹домен компании›/‹название продукта›/‹версия›/‹jsfilename›.js И мы смогли заменить законный файл JS компании на злонамеренный.
По сути, у нас был XSS на десятках веб-сайтов и компаний, даже не проведя ни одной минуты исследования против них. Самое смешное, что эта атака затронула только тех пользователей, которые были направлены на уязвимый сервер (сервер C).
Что мы можем извлечь из этого (TL;DR)
Никогда не доверяйте сторонним веб-сайтам и сервисам выполнение вашей работы! Я говорил тебе это уже миллионы раз. Быть независимым. Будь большим мальчиком, который может оставаться один в доме.
Самым безопасным решением будет вручную загрузить файлы JS-библиотек, которые вы используете, и сохранить их на своем сервере.
Но что происходит, когда библиотеки JS, которые я использую, обновляются?
Очевидно, что с помощью предложенного метода нет простого способа отслеживать его, кроме как с помощью менеджера пакетов, такого как Bower. Все, что вам нужно будет делать, это время от времени синхронизировать свои библиотеки.
До того, как менеджеры пакетов Javascript стали популярными, я посоветовал своему другу просто написать cronjob или скрипт на Python, который будет проверять последнюю версию библиотеки JS, доступную на сервере компании, а затем сравнивать ее с локальной версией. . Если версии не совпадают — скрипт отправляет электронное письмо в техподдержку.
Большие библиотеки JS не так часто обновляются.
Итак, после фильма ужасов, который вы только что посмотрели, следующее, что вы собираетесь сделать, помимо кофе, — это загрузить сторонние библиотеки на свой сервер.
Ваше здоровье.
Подпишитесь на статью Infosec Write-ups, чтобы узнать больше таких замечательных статей.
