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

Ответ 1

Если вы используете их только в том виде, в котором включает JavaScript, и поскольку JavaScript является только клиентской стороной, он потенциально имеет доступ ко всему и всему, что отображается как XHTML через DOM. Это было бы основано на том, что CDN взломали, а JavaScript, который вы включили, получил злонамеренное изменение. См. Как API javascript Google обходит междоменную безопасность в AJAX для получения информации о использовании JavaScript в междоменном домене.

Как говорили другие, это просто не стоит риска, учитывая почти нулевые преимущества. Библиотеки JavaScript, как правило, слишком малы, чтобы иметь значение для экономии пространства на сервере, скорости/скорости доступа и т.д.

Ответ 2

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

В отношении безопасности: данные могут быть скомпрометированы или канал передачи может быть перехвачен, а вредоносный код передан на месте с помощью атак XSS и CSRF. Вероятность этого снова очень низкая, на мой взгляд.

Существуют также проблемы с файлами cookie и проблемы с безопасным подключением (более https вместо http) в отношении предупреждающих сообщений и сертификатов несоответствия (см. http://idunno.org/archive/2009/09/16/quick-thoughts-on-the-microsoft-ajax-cdn.aspx). Microsoft поддерживает SSL, хотя я не уверен в том, что касается Yahoo и Google (они должны). Google не отслеживает файлы cookie, но они все равно будут видеть, как IP-адреса попадают в сеть CDN и могут использовать их для отслеживания, если они этого захотят.

Значение CDN будет иметь некоторую скорость через локальное кэширование script, если пользователь посетил какой-либо другой сайт, используя CDN. Но для крупного учреждения я не вижу нужды.

Ответ 3

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

1) Отправить ВСЕ активы пользователю через HTTPS из того же домена. Хотя он медленнее и дешевле для пропускной способности, он также более безопасен, потому что вы напрямую контролируете все активы от манипуляций. По всем активам я действительно имею в виду все активы, включая изображения, поскольку манипуляция изображениями, содержащими текстовое содержимое, может использоваться для отправки ложных инструкций перед попыткой фишинга. В связи с этим я бы не использовал CDN для хранения ваших активов, потому что это не то местоположение, которое у вас есть, поэтому у вас меньше средств для контроля за сохраненными данными для подделки.

2) НЕ используйте AJAX или что-нибудь еще с объектом XMLHttpRequest. Точкой асинхронной связи является маяковая информация между точками за пределами перезагрузки страницы. Это здорово для удобства использования, но полностью побеждает безопасность. Поскольку он выполняется на стороне клиента, скомпрометированный код также может использоваться для предотвращения законного шифрования SSL путем передачи информации от пользователя ненадежной третьей стороне после того, как информация расшифровывается в конце пользователя. Когда вы имеете дело с покупками, PII или финансовыми данными, ВСЕГДА убедитесь, что каждая информационная транзакция от пользователя заставляет перезагружать страницу или новую страницу.

3) Избегайте использования каких-либо скриптов на стороне клиента. Средство не использует ActiveX, Flash или даже Acrobat. 95% всех зарегистрированных уязвимостей безопасности приписываются скриптам на стороне клиента, а 70% этих атак - повреждение памяти программного обеспечения обработки. Хотя JavaScript, как правило, не известен для переполнения буфера, я по-прежнему рекомендую использовать его как можно меньше, чтобы манипулировать только DOM.

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

5) Не используйте событие onsubmit для присоединения script к представлению данных формы. Нарушение исполняемого кода или добавление дополнительного вредоносного кода может создать точку, в которой должна быть включена функция XMLHttpRequest для анонимного маяка данных формы для ненадежной третьей стороны перед отправкой ее в надежный источник, даже если протокол передачи действия атрибутом является HTTPS.

6) До тех пор, пока вы придерживаетесь VALID XHTML, CSS и текста практически для всех возможных аспектов работы пользователя и обмениваетесь данными только с использованием HTTPS, вы должны быть в основном в порядке.

Вы должны иметь в виду, что банки и учебные заведения получают 40% всех известных атак, поэтому вы ДОЛЖНЫ предполагать, что ваша работа будет атакована и скомпрометирована. Средняя стоимость одной атаки в 2008 году составила 11,3 млн. Долл. США. Если банк может напасть на вас за эти убытки, потому что вы не считаете полную глубину безопасности, как бы вы ответили? Планируйте соответственно, чтобы ваша работа была как можно заблокирована.

Ответ 4

Вы должны ознакомиться с условиями и условиями, если таковые имеются, для версий с бесплатным CDN. Однако для "крупной финансовой компании" это, вероятно, будет недостаточно.

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

Ответ 5

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

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