Подтвердить что ты не робот

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

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

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

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

Кажется, что google CDN поддерживает обслуживание библиотек через SSL.

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

4b9b3361

Ответ 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
    
  • Сначала создайте и сохраните свою собственную контрольную сумму для этого файла.

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

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

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

Ответ 2

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

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

Изменить: Также рассмотрите проблему конфиденциальности, упомянутую Gert G.

Ответ 3

Служит ли jQuery из CDN на самом деле менее безопасным, чем обслуживает его с самого сервера?

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

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

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

Ответ 4

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

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

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

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