Як я можу переконатись, що мої файли JavaScript, доставлені через CDN, не змінюються?

88

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

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

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

Чи існує якийсь метод, вбудований у браузери для перевірки автора файлів JavaScript? Чи можу я щось зробити, щоб зробити це безпечним способом?

javascript  code-signing 
— baba26
джерело
13
Хоча це питання мені цікаве, чи не є це поза темою?
— evolutionxbox
20
чому ви будете обслуговувати файли на http?
— njzk2
12
"Але чому немає такого механізму?" Бо це справді важко . Як тільки ваші дані покинуть ваш сервер, це тост. HTTPS допомагає, але якщо це звичайне з'єднання HTTP, будь-яка перевірка може провалитися (вірніше - пройти). Атака MITM може просто змінити ваш очікуваний підпис та / або підпис того, що вам надано, перш ніж браузер зрозуміє очікування. Отже, коли користувач отримує деяке корисне навантаження, це буде вважатися абсолютно безпечним ... коли це не обов’язково це.
— ВЛАЗ
4
"Але чому немає такого механізму?" Тому що в HTTPS вже існує дешеве, ефективне та широко застосовуване рішення.
— Кевін Крумвіед,
9
Це, мабуть, має бути на ServerFault або Security, оскільки насправді йдеться про безпечне обслуговування файлів, і будь-яке відношення до програмування є лише дотичним, оскільки згадані файли представляють вихідний код.
— underscore_d

Відповіді:

140

Власне кажучи, така функція зараз розробляється під назвою Цілісність підресурсів . Подивіться на integrityатрибут <script>тегу. Хоча він ще не повністю прийнятий на загальному рівні , він виконує саме цю мету.

integrity

Містить вбудовані метадані, за допомогою яких агент користувача може перевірити, чи доставлений отриманий ресурс вільний від несподіваних маніпуляцій. Див. Цілісність підресурсів.

Джерело

Цілісність підресурсів (SRI) - це функція безпеки, яка дозволяє браузерам перевіряти, що файли, які вони отримують (наприклад, із CDN), доставляються без несподіваних маніпуляцій. Це працює, дозволяючи вам надати криптографічний хеш, якому повинен відповідати отриманий файл.

Джерело

Приклад:

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

Однак зауважте, що це не захистить вас від атак Man in the Middle, якщо ви передаєте свої ресурси через звичайний HTTP. У цьому випадку зловмисник може підробляти хеш-код, роблячи захист від маніпульованих файлів сценаріїв марним.

З цієї причини, ви завжди повинні використовувати захищені з'єднання HTTPS замість простого HTTP на додаток до заходів безпеки, описаних вище.

— Тимо
джерело
9
Я думаю, що варто згадати, що перевірку цілісності можна легко підробити, припускаючи, що OP планує надсилати свій HTML у HTTP, а також файли активів. Якщо їх веб-сайт - HTTPS, і вони хочуть обслуговувати активи через HTTP, то більшості браузерів це не сподобається і мовчки ігнорують активи HTTP.
— MonkeyZeus
3
@MonkeyZeus Це було б правдою лише в разі атаки MITM або якщо наш власний сервер скомпрометований, правильно? Я розумію, що питання прямо задає питання, як захиститися від компрометованого CDN.
— Тимо
10
@TimoSta Точно! Без цих перевірок, якщо ви включите скрипт, наприклад, https://code.jquery.com/тоді, кожен, хто компрометує, code.jquery.comможе XSS ваш сайт, незалежно від того, доступ чи ні code.jquery.comчерез HTTPS. За допомогою цих перевірок зловмисник може лише перешкоджати завантаженню сценаріїв, а не замінювати їх шкідливими.
— Ajedi32
1
@MonkeyZeus Я додав примітку до моєї відповіді, де вказав ваші занепокоєння. Чи згодні ви з формулюванням?
— Тимо
1
@TimoSta Дуже приємно, мені це подобається! До речі, я зробив +1 ще до того, як опублікував свій перший коментар :-)
— MonkeyZeus
36

Ви шукаєте перевірку цілісності підресурсів .

Наприклад, ось фрагмент CDN jQuery:

<script src="https://code.jquery.com/jquery-3.1.0.js"
        integrity="sha256-slogkvB1K3VOkzAI8QITxV3VzpOnkeNVsKvtkYLMjfk="
        crossorigin="anonymous"></script>
— Брайан
джерело
2
Зовсім марно, оскільки зловмисник може змінювати поле цілісності одночасно з тим, що вони змінюють сценарій, який ви завантажуєте.
— Гонки легкості на орбіті
15
@LightnessRacesinOrbit: Ні, якщо ви контролюєте власний домен, до якого здійснюється доступ через HTTPS, але не контролюєте code.jquery.com. Це може захистити вас від компрометації code.jquery.com.
— SilverlightFox
2
@SilverlightFox: Гаразд, абсолютно марний проти атак MITM *
— Гонки легкості на орбіті
@LightnessRacesinOrbit Так. Все-таки дуже корисний і запобіг би цій атаці, наприклад: bleepingcomputer.com/news/security/…
— Адріан Муат,
6

Застереження: Як завжди, ви повинні вважати ці механізми корисними лише при використанні https, оскільки їх легко можна відключити через MitM за допомогою http

На додаток до механізму у наведених вище відповідях, ви також можете використовувати заголовки відповідей політики безпеки вмісту http на батьківській сторінці.

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

Політика безпеки вмісту: script-src 'sha256-qznLcsROx4GACP2dm0UCKCzCG-HiZ1guq6ZZDob_Tng ='

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

За допомогою Chrome 40 або новішої версії ви можете відкрити DevTools, а потім перезавантажити сторінку. Вкладка Консоль міститиме повідомлення про помилки з правильним хешем sha256 для кожного з ваших вбудованих сценаріїв.

Цей механізм існує вже давно, тому підтримка браузера, швидше за все, досить гарна, просто обов’язково перевірте.

Крім того, якщо ви хочете переконатися, що старі несумісні браузери не є небезпечними, ви можете включити синхронний сценарій перенаправлення у верхній частині сторінки, що заборонено політикою.

— Фабіо Белтраміні
джерело
існує вже досить давно, але підтримка браузера не дуже хороша. caniuse.com/subresource-integrity
— Sp0T
@ Sp0t - Цілісність підресурсу (про що йдеться у вашому посиланні) є механізмом інших відповідей. Моя відповідь стосується політики безпеки вмісту, яка має набагато кращу підтримку
— Фабіо Белтраміні
3

Існує важливий момент про те, що такий підпис може і що не може робити. Це може захистити користувача від гіпотетичних атак, коли хтось модифікує ваш код. Це не може запевнити ваш сайт, що ваш код - це код, який виконується. Іншими словами, ви все ще не можете довіряти нічому, що надходить на ваш сайт від клієнта.

— ddyer
джерело
2

Якщо ваша модель супротивника дозволяє зловмисникові змінювати файли JavaScript у міру їх доставки з CDN, тоді ваша модель суперника дозволяє зловмисникові змінювати джерело, що посилається, оскільки воно доставляється для видалення будь-якої спроби перевірки, щоб змінити адресу джерела на іншу, ніж CDN та / або повністю видалити посилання на JavaScript.

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

/ etc / hosts:

#  ...
1.2.3.4    vile-pirates.org    trustworthy.cdn
#  ...
— Ерік Тауерс
джерело
2
Перше речення явно не відповідає дійсності. Що робити, якщо посилальна сторінка завантажується через HTTPS, а файл JavaScript завантажується через HTTP-not-S?
— user253751 02
Або що, якщо сам CDN порушений, але не ваш власний сервер?
— Ajedi32,
@immibis: Я вирішив припустити, що OP не настільки ірраціональний, щоб пропонувати такий сценарій.
— Ерік Тауерс
1
@immibis Чи не тому браузери, як правило, не дозволяють HTTPS-сторінкам завантажувати JS через HTTP?
— Бармар,
1
@immibis Я говорив, що це покращує ситуацію, яка навіть не можлива, оскільки браузери це забороняють.
— Бармар,
1

Ви можете забезпечити це за допомогою цілісності підресурсів. Багато загальнодоступних CDN включають хеші SRI у вбудований код, пропонований на веб-сайтах CDN. Наприклад, на PageCDN, коли ви натискаєте файл jquery на сторінці jQuery CDN , ви отримуєте можливість або скопіювати URL-адресу, або використовувати тег скрипта, що містить хеш SRI, як показано нижче:

<script src="https://pagecdn.io/lib/jquery/3.4.1/jquery.min.js" integrity="sha256-CSXorXvZcTkaix6Yvo6HppcZGetbYMGWSFlBw8HfCJo=" crossorigin="anonymous"></script>

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

На даний момент цю функцію підтримує 91% браузерів у всьому світі. Детальніше про каніуса .

— 5377037
джерело
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.