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

Пользователи с ослабленным зрением применяют такие «вспомогательные технологии», как программы чтения с экрана, когда слова, выводимые на экран, преобразуются в речевые аналоги. Некоторые программы чтения с экрана способны распознавать JavaScript-код, другие лучше работают, когда поддержка JavaScript отключена. Если вы разрабатываете сайт, который требует выполнения JavaScript-кода на стороне клиента для отображения информации, вы ограничиваете доступность своего сайта для пользователей подобных программ чтения с экрана. (И ограничиваете тех, кто преднамеренно отключил поддержку JavaScript в броузере.) Главная цель JavaScript заключается в улучшении представления информации, а не собственно в ее представлении. Основное правило применения JavaScript заключается в том, что веб-страница, в которую встроен JavaScript-код, должна оставаться работоспособной (хотя бы ограниченно), даже когда интерпретатор JavaScript отключен.

Другое важное замечание относительно доступности касается пользователей, которые могут работать с клавиатурой, но не могут (или не хотят) применять указывающие устройства, такие как мышь. Если программный код ориентирован на события, возникающие от действий мышью, вы ограничиваете доступность страницы для тех, кто не пользуется мышью. Веб-броузеры позволяют задействовать клавиатуру для перемещения по веб-странице и выполнять операции с элементами графического интерфейса в них, то же самое должен позволять делать и ваш JavaScript-код. Как демонстрируется в главе 17, наряду с поддержкой событий, зависящих от типа устройства, таких как onmouseover или onmousedown, JavaScript обладает поддержкой событий, не зависящих от типа устройства, таких как onfocus и onchange. Для достижения максимальной доступности следует отдавать предпочтение событиям, не зависящим от типа устройства.

Создание максимально доступных веб-страниц - нетривиальная задача, а обсуждение проблем обеспечения доступности выходит за рамки этой книги. Разработчики веб-приложений, для которых проблемы доступности имеют немаловажное значение, должны ознакомиться со стандартами WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications) http://www.w3.org/WAI/intro/aria.

13.6. Безопасность

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

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

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

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