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

Флэнаган Дэвид

• Реализовать мощный прикладной программный интерфейс на стороне клиента, позволяющий писать полезные веб-приложения.

• Воспрепятствовать злонамеренному программному коду читать или изменять персональные данные пользователя, получать доступ к конфиденциальным данным, обманывать пользователя или тратить его время.

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

производители броузеров с осторожностью (открыто и совместно) отменяют некоторые давнишние ограничения, связанные с безопасностью и расширяют возможности клиентского JavaScript, не добавляя (хотелось бы надеяться) новых дыр в системе безопасности.

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

13.6.1. Чего не может JavaScript

Броузеры - это первая линия обороны против злонамеренного кода, поэтому они просто не поддерживают некоторые функциональные возможности. Например, клиентский JavaScript не предоставляет никакого способа записи или удаления файлов и каталогов на клиентском компьютере. То есть программа на языке JavaScript не может удалить данные или установить вирус. (Тем не менее в разделе 22.6.5 вы узнаете, как на языке JavaScript реализовать чтение файлов, выбранных пользователем, а в разделе 22.7 - как настроить безопасную частную файловую систему, в пределах которой программы на языке JavaScript смогут работать с файлами.)

Аналогично клиентский JavaScript не имеет универсальных механизмов сетевых взаимодействий. Клиентский сценарий на языке JavaScript может управлять протоколом HTTP (как описывается в главе 18). А другой стандарт, примыкающий к стандарту HTML5, известный как WebSockets, определяет прикладной программный интерфейс, напоминающий сокеты, позволяющий взаимодействовать со специализированными серверами. Но ни один из этих интерфейсов не позволяет получить непосредственный доступ к сети. На клиентском JavaScript нельзя написать программу универсального сетевого клиента или сервера.

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

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

• JavaScript-программа может закрыть окно броузера, открытое ею же, но она не может закрыть другое окно без подтверждения пользователя.

• Свойство

value

HTML-элемента

FileUpload

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

• Сценарий не может прочитать содержимое документов с других серверов, отличных от сервера, откуда был получен документ с данным сценарием. Аналогичным образом сценарий не может зарегистрировать обработчики событий в документах, полученных с других серверов. Это предотвращает возможность подсматривания данных, вводимых пользователем (таких как комбинации символов, составляющих пароль) в других страницах. Это ограничение известно как политика общего происхождения (same-origin policy) и более подробно описывается в следующем разделе.

Обратите внимание, что это далеко не полный список ограничений, имеющихся в клиентском JavaScript. Различные броузеры используют различные стратегии безопасности и могут накладывать различные ограничения. Кроме того, некоторые броузеры могут также предоставлять возможность ужесточать или ослаблять ограничения с помощью пользовательских настроек.

13.6.2. Политика общего происхождения

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

<iframe>

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

окнах и фреймах. В частности, сценарий может читать только свойства окон и документов, имеющих общее с самим сценарием происхождение (о том, как использовать JavaScript для работы с несколькими окнами и фреймами, рассказывается в разделе 14.8).

Происхождение документа определяется протоколом, именем хоста и номером порта URL-адреса, откуда был загружен документ. Документы, загружаемые с других веб-серверов, имеют другое происхождение. Документы, загруженные с разных портов одного и того же хоста, также имеют другое происхождение. Наконец, документы, загруженные по протоколу http:, по происхождению отличаются от документов, загруженных по протоколу https:, даже если загружены с одного и того же веб-сервера.

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

src

элемента

<script>

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

Политика общего происхождения на самом деле применяется не ко всем свойствам всех объектов в окне, имеющем другое происхождение, но она применяется ко многим из них, в частности, практически ко всем свойствам объекта

Document

. В любом случае можно считать, что любое окно или фрейм, содержащий документ, полученный с другого сервера, для ваших сценариев будут закрыты. Если такое окно было открыто самим сценарием, он сможет закрыть его, но не может «заглянуть внутрь» окна. Кроме того, политика общего происхождения действует при работе по протоколу HTTP с применением объекта

XMLHttpRequest

(глава 18). Этот объект позволяет JavaScript-сценариям, выполняющимся на стороне клиента, отправлять произвольные HTTP-запросы, но только тому веб-серверу, откуда был загружен документ, содержащий сценарий.

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

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» или другому имени домена верхнего уровня.