JavaScript. Подробное руководство, 6-е издание

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

13.6.2.1. Ослабление ограничений политики общего происхождения

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

Политика общего происхождения создает определенные проблемы для крупных веб-сайтов, которые функционируют на нескольких серверах. Например, сценарий с сервера home.example.com мог бы на вполне законных основаниях читать свойства документа, загруженного с developer.example.com, а сценариям с orders.example.com может потребоваться прочитать свойства из документов с catalog.example.com. Для поддержки таких крупных веб-сайтов можно использовать свойство domain объекта Document. По умолчанию свойство domain содержит имя сервера, с которого был загружен документ. Это свойство можно установить только равным строке, являющейся допустимым доменным суффиксом первоначального значения. Другими словами, если значение свойства domain первоначально было равно строке «home.example.com», то можно установить его равным «ехаmрle.com», но не «home.example» или «ample.com». Кроме того, значение свойства domain должно содержать, по крайней мере, одну точку, чтобы его нельзя было установить равным «соm» или другому имени домена верхнего уровня.

Если два окна (или фрейма) содержат сценарии, установившие одинаковые значения свойства 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-адреса сценарий динамически сгенерирует другой сценарий (коды %ЗС и %ЗЕ - это угловые скобки)! В данном случае вставленный сценарий просто отобразит диалоговое окно, которое не представляет никакой опасности. Но представьте себе такой случай: