Как я могу убедиться, что мои файлы JavaScript, доставленные по CDN, не изменены?

Question

Я работаю над сценарием, в котором некоторые файлы JavaScript должны размещаться на CDN. Я хочу иметь некоторый механизм, чтобы, когда этот файл загружается с пользовательской стороны, я могу гарантировать, что файлы не были подделаны и действительно поступают из указанного CDN.

Я понимаю, что задача очень проста, если я использую SSL, но все же хочу убедиться, что нужные файлы обслуживаются даже по протоколу HTTP без SSL.

Насколько я могу найти, нет существующего механизма, такого как цифровая подпись для файлов JavaScript, который поддерживается на разных платформах. Может быть, это не нужно?

Есть ли какой-нибудь метод, встроенный в браузеры для проверки автора файлов JavaScript? Есть ли что-нибудь, что я могу сделать, чтобы сделать это безопасным способом?

Answer 1

Вы ищете subresource integrity чеков.

Например, вот JQuery CDN сниппет:

<script src="https://code.jquery.com/jquery-3.1.0.js" 
     integrity="sha256-slogkvB1K3VOkzAI8QITxV3VzpOnkeNVsKvtkYLMjfk=" 
     crossorigin="anonymous"></script> 

Answer 2

В самом деле, особенность, как это currently being drafted под названием Subresource Integrity. Посмотрите на атрибут integrity тега <script>.While not yet fully adopted across the board, он выполняет именно эту цель.

integrity

Содержит встроенные метаданные, агент пользователя может использовать для проверки того, что неправдоподобным ресурс был доставлен бесплатно неожиданных манипуляции. См. Целостность Subresource.

Source

Subresource Integrity (SRI) является функция безопасности, которая позволяет браузерам проверить, что файлы они выборки (например, из CDN) поставляются без неожиданных манипуляций. Он работает, позволяя вам предоставлять криптографический хеш, который должен соответствовать выбранному файлу.

Source

---

Пример:

<script src="https://example.com/example-framework.js" 
    integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC" 
    crossorigin="anonymous"></script> 

---

Однако обратите внимание, что это не защитит вас от Man in the Middle attacks, если вы направляете свои ресурсы с помощью обычного HTTP. В этом случае хеш-код может быть подделан злоумышленником, что делает защиту от манипулируемых файлов сценариев бесполезной.

По этой причине вы должны всегда использовать безопасные HTTPS-соединения вместо простого HTTP в дополнение к описанным выше мерам безопасности.

Answer 3

Отказ от ответственности: Как всегда, вы должны рассматривать только эти механизмы любого использования при использовании протокола HTTPS, так как они легко могут быть отключены через MiTM с HTTP

В дополнении к механизму в вышеуказанных ответах, вы также можете использовать политику защиты контента HTTP-заголовков на родительской странице.

http://www.html5rocks.com/en/tutorials/security/content-security-policy/

Content-Security-Policy: скрипт-Src 'sha256-qznLcsROx4GACP2dm0UCKCzCG-HiZ1guq6ZZDob_Tng ='

Есть несколько вещей, чтобы отметить здесь. Префикс sha * - определяет алгоритм, используемый для генерации хэша. В приведенном выше примере используется sha256-. CSP также поддерживает sha384- и sha512-. При генерации хэша не включают теги. Также капитализация и пробел, включая начальные или конечные пробелы.

Используя Chrome 40 или более позднюю версию, вы можете открыть DevTools, а затем перезагрузить страницу. Вкладка «Консоль» будет содержать сообщения об ошибках с правильным хэшем sha256 для каждого из ваших встроенных скриптов.

Этот механизм существует уже довольно долгое время, поэтому поддержка браузера, скорее всего, очень хорошая, просто обязательно проверьте.

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

Answer 4

Если ваша модель противника позволяет злоумышленнику изменять файлы JavaScript по мере их доставки из CDN, то ваша модель противника позволяет злоумышленнику изменять источник ссылок, поскольку он доставляется, чтобы удалить любую попытку проверки, изменить исходный код адрес, отличный от CDN, и/или полностью удалить ссылку на JavaScript.

И позволяет не открывать банку червей о том, как ваше приложение может определить, правильно ли преобразователь пользователя или неправильно решает CDN через HTTP-запросы (или любой другой механизм, который не имеет проверенной цепочки доверия) ,

/и т.д./хосты:

# ... 
1.2.3.4 vile-pirates.org trustworthy.cdn 
# ... 

Answer 5

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