Насколько безопасны CDN для доставки jQuery?

Question

Мы создаем сайты, которые имеют открытую (незащищенную) область и защищенную (доставляемую по HTTPS) область, и используем библиотеку jQuery.

Недавно я предложил использовать Google CDN для доставки jQuery. Некоторые из моих коллег выразили обеспокоенность по поводу аспекта безопасности этого способа доставки библиотек JavaScript.

Например, они упоминают сценарий, когда кто-то может взломать DNS-сервер, а затем внедрить злонамеренно измененную библиотеку, открывая дверь для различных атак безопасности. Теперь, если хакер может внедрить вредоносный код через Google CDN, он, вероятно, может сделать то же самое, если jQuery обслуживается с самого сайта, верно?

Похоже, что Google CDN поддерживает обслуживание библиотек через SSL.

Действительно ли обслуживание jQuery с CDN менее безопасно, чем обслуживание с самого сервера? Насколько серьезна эта угроза?

Answer 1

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

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

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

Но если вы только параноик, вы можете попробовать что-то вроде этого:

• Убедитесь, что вы ссылаетесь на уникальную и специфическую версию файла jQuery от Google. Например, сделайте это:

  http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js
  

  а не это:

  http://ajax.googleapis.com/ajax/libs/jquery/1.4/jquery.min.js
  

  Последняя версия может вернуть 1.4.2 сейчас, но 1.4.3 завтра. Если у вас есть сочетание потребностей http и https, вы можете использовать URL-адреса, относящиеся к протоколу, например:

  //ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js
  

• Изначально сгенерируйте и сохраните собственную контрольную сумму для этого файла.

• Периодически повторяйте процесс и убедитесь, что новая контрольная сумма совпадает со старой. Если этого не произойдет, прозвучат клаксоны.

Конечно, вы можете сделать это программно. Вы решаете, какой интервал имеет смысл. Каждую минуту? Каждые пять? Теперь у вас есть возможность автоматического выключателя, чувствительность которого вы можете настроить в соответствии со своими предпочтениями. Конечно, подпрограмма «монитор» не обязательно должна выполняться синхронно внутри приложения, которое вы хотите защитить; возможно, для этой цели вы запускаете небольшое служебное приложение на том же сервере.

Достаточно просто проверить: просто измените сохраненный хеш. Поскольку вы ссылаетесь на конкретную версию файла, кнопка паники не будет нажиматься при каждом обновлении второстепенной версии. Если вы хотите перейти на новую версию jQuery, измените URL-адрес AJAX API на своем сайте и сохраните новый хеш.

Answer 2

Действительно ли обслуживание jQuery с CDN менее безопасно, чем обслуживание с самого сервера?

Да.Если это внешний ресурс, он всегда менее защищен .Как вы могли быть уверены, что знаете, что на самом деле получают ваши клиенты, если у вас нет исходного кода?И если вы не знакомы с CloudBleed , возможно, вы захотите прочитать, прежде чем продолжить.

Если вам все-таки нужно загрузить jQuery из внешнего CDN по соображениям производительности, убедитесь, что вывы используете целостность подсистемы .Более подробную информацию о SRI можно найти в MDN.

Наконец, если безопасная загрузка jQuery через CDN вызывает обеспокоенность из-за производительности веб-сайта и создания Single-Point Failure (и это должно быть проблемой, если вы вообще знакомы с работой Стива Соудерса), вам почти наверняка лучше с точки зрения безопасности и производительности, перемещая все свои скрипты своими силами и загружая их асинхроннопараллельно, используя Fetch Injection .Просто будьте уверены, если вы это сделаете, вы агрессивно кешируете в браузере.И если вы обслуживаете глобальную аудиторию, убедитесь, что вы кешируете эти ресурсы.

Answer 3

Как отмечают ваши коллеги, угон DNS-сервера будет проблемой здесь. Не было бы, если бы вы обслуживали библиотеку с того же хоста, что и ваш сайт. Однако если использовать HTTPS, маловероятно, что у злоумышленника будет действительный сертификат на поддельном сайте. Я не знаю, как браузеры отреагируют на это, но я подозреваю, что они пометят сайт как небезопасный (поскольку некоторым его элементам нельзя доверять) и будут действовать соответственно.

Итак, вкратце; если доступ к CDN также осуществляется по протоколу HTTPS, больших рисков быть не должно.

Редактировать: Также рассмотрите вопрос о конфиденциальности, упомянутый Герт G .

Answer 4

Если доверие существует в Интернете, то Google является самым надежным ...

Нет сомнений в том, что Google CDN безопасен, но проблемы всегда возникают из-за интернет-соединения пользователя / сервера качества.

Кстати, если вы включите библиотеку jQuery со скриптом загрузчика API Google, Google добавит небольшой код отслеживания статистики в свои доступные библиотеки CDN JavaScript ( около + 4 КБ, см. В Firebug ), что составляет 20 КБ уменьшенная и сжатая библиотека jQuery немного тяжелая, плюс предвидеть скорость SSL.

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