JavaScript. Подробное руководство, 6-е издание
Шрифт:
Если два окна (или фрейма) содержат сценарии, установившие одинаковые значения свойства domain, политика общего происхождения для этих двух окон ослабляется, и каждое из окон может читать значения свойств другого окна. Например, взаимодействующие сценарии в документах, загруженных с серверов orders. example.com и catalog.example.com, могут установить свойства document.domain равными «example.com», тем самым указывая на общность происхождения документов и разрешая каждому из документов читать свойства другого.
Второй прием ослабления ограничений политики общего происхождения предполагается стандартизовать под названием «Cross-Origin Resource Sharing» (http:// www.w3.org/TR/cors/). Этот проект стандарта дополняет протокол HTTP новым заголовком запроса Origin: и новым заголовком ответа Access-Control-Allow-Origin. Он позволяет серверам использовать заголовок для явного определения списка доменов, которые могут запрашивать файл, или использовать шаблонные символы, чтобы обеспечить возможность получения файла любым сайтом. Броузеры, такие как Firefox 3.5 и Safari 4, используют этот новый заголовок, чтобы разрешить выполнение междоменных HTTP-запросов с использованием объекта XML-HttpRequest, которые иначе были бы невозможны из-за ограничений политики общего происхождения.
Еще один новый прием, известный как «обмен сообщениями между документами» (cross-document messaging), позволяет сценарию из одного документа передавать текстовые сообщения сценарию в другом документе независимо от домена происхождения сценария. Вызов метода
13.6.3. Взаимодействие с модулями расширения и элементами управления ActiveX
Хотя в базовом языке JavaScript и базовой объектной модели на стороне клиента отсутствуют средства для работы с сетевым окружением и файловой системой, которые необходимы наихудшему злонамеренному программному коду, тем не менее ситуация не такая простая, как кажется на первый взгляд. Во многих броузерах JavaScript-код используется как «механизм выполнения» других программных компонентов, таких как элементы управления ActiveX (в IE) и модули расширения (в других броузерах). Самыми распространенными примерами являются модули расширения, обеспечивающие поддержку Flash и Java, и они предоставляют в распоряжение клиентских сценариев дополнительные мощные возможности.
Вопросы безопасности приобретают особую важность, когда речь заходит о передаче управления элементам ActiveX и модулям расширения. Апплеты Java, например, могут иметь низкоуровневый доступ к сетевым возможностям. Защитная «песочница» для Java не позволяет апплетам взаимодействовать с серверами, отличными от того, откуда они были получены; тем самым закрывается брешь в системе безопасности. Но остается основная проблема: если модуль расширения может управляться из сценария, необходимо полное доверие не только системе безопасности броузера, но и системе безопасности самого модуля расширения. На практике модули расширения Java и Flash, похоже, не имеют проблем с безопасностью и не вызывают появление этих проблем в клиентских сценариях на языке JavaScript. Однако элементы управления ActiveX имеют более пестрое прошлое. Броузер IE обладает возможностью доступа из сценариев к самым разным элементам управления ActiveX, которые являются частью операционной системы Windows и которые раньше уже были источниками проблем безопасности.
13.6.4. Межсайтовый скриптинг
Термин межсайтовый скриптинг (cross-site scripting), или XSS, относится к области компьютерной уязвимости, когда атакующий внедряет HTML-теги или сценарии в документы на уязвимом веб-сайте. Организация защиты от XSS-атак -обычное дело для веб-разработчиков, занимающихся созданием серверных сценариев. Однако программисты, разрабатывающие клиентские JavaScript-сценарии, также должны знать о XSS-атаках и предпринимать меры защиты от них.
Веб-страница считается уязвимой для XSS-атак, если она динамически создает содержимое документа на основе пользовательских данных, не прошедших предварительную обработку по удалению встроенного HTML-кода. В качестве тривиального примера рассмотрим следующую веб-страницу, которая использует JavaScript-сценарий, чтобы приветствовать пользователя по имени:
В этом двустрочном сценарии используется метод
В этом случае будет выведен текст «Привет, Давид». Но что произойдет, если страница будет запрошена с использованием следующего URL-адреса:
С таким содержимым URL-адреса сценарий динамически сгенерирует другой сценарий (коды %ЗС и %ЗЕ - это угловые скобки)! В данном случае вставленный сценарий просто отобразит диалоговое окно, которое не представляет никакой опасности. Но представьте себе такой случай:
Межсайтовый скриптинг потому так и называется, что в атаке участвует более одного сайта. Сайт В (или даже сайт С) включает специально сконструированную ссылку (подобную только что показанной) на сайт А, в которой содержится сценарий с сайта В. Сценарий evil.js размещается на сайте злоумышленника В, но теперь этот сценарий оказывается внедренным в сайт А и может делать все, что ему заблагорассудится с содержимым сайта А. Он может стереть страницу или вызвать другие нарушения в работе сайта (такие как отказ в обслуживании, о чем рассказывается в следующем разделе). Это может отрицательно сказаться на посетителях сайта А. Гораздо опаснее, что такой злонамеренный сценарий может прочитать содержимое cookies, хранящихся на сайте А (возможно, содержащих учетные номера или другие персональные сведения), и отправить эти данные обратно на сайт В. Внедренный сценарий может даже отслеживать нажатия клавиш и отправлять эти данные на сайт В.