Объекты XPCOM

16.5.3. Настройки

Скрипты позволяют изменять текущие настройки профиля пользователя, текущие глобальные настройки, а также файлы настроек, хранящиеся на локальном компьютере. Для этого используется следующая пара XPCOM:

@mozilla.org/preferences-service;1 nsIPrefService

По умолчанию скрипты, не установленные в chrome, не могут изменять настроек пользователя или платформы. Чтобы предоставить им такую возможность, необходимо отключить стандартные ограничения защиты. В версиях Mozilla начиная с 1.3 пользователь может изменять любые настройки в окне браузера, введя в строке адреса следующий URL: about:config.

16.5.4. Защита

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

В браузерах Netscape 4.x такого рода проверки выполнялись с помощью подсистемы Java. Платформа Mozilla содержит собственную подсистему защиты, которая обеспечивает необходимые проверки и ограничения, не используя Java.

Фрагмент кода Mozilla может находиться в одном из четырех режимов защиты: Web Safe (защищенный для работы в Web), Trusted (режим доверия), Certified (защита на основе сертификатов) или Domain Policied (политика защиты на основе доменов). На практике эти режимы относятся, прежде всего, к скриптам JavaScript, однако они применимы и к любым загружаемым документам, включая HTML-документы.

Поддержка протокола WDSL, недавно реализованная в составе платформы, привела к добавлению дополнительных мер защиты. Они подразумевают дополнительную проверку при первом обращении к удаленному Web-сервису – платформа должна запросить разрешение на его использование. Это делается с целью защиты сервера, предоставляющего Web-сервис, а не локальной платформы, которая обращается к нему. В момент подготовки книги к печати предполагалось, что на стороне клиента для такой проверки будет использоваться интерфейс nsIWebScriptsAccessService.

Большинство механизмов защиты, хотя и не все, реализованы в составе кода XPConnect, который обеспечивает доступ скриптов JavaScript к функциональности платформы Mozilla.

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

16.5.4.1. Режим защиты Web Safe

Режим Web Safe (защищенный для работы в Web) – режим защиты, применяемый к приложениям Mozilla по умолчанию. В частности, в этом режиме выполняются приложения XUL, установленные за пределами chrome, а также любые Web-приложения, выполняемые в контексте окон браузера, содержащих документы XML или HTML. Режим Web Safe обеспечивает высокий уровень защиты, налагая два типа ограничений на операции, выполняемые скриптами.

Первая группа ограничений призвана обеспечить контроль пользователя над интерфейсом и сделать заметными любые действия с ним. Пример такого ограничения – требование, чтобы любые окна имели размер не менее 100 пикселей в ширину и высоту и, следовательно, были заметны для пользователя.

Второй тип ограничений связан с принципом "общего источника" (Same Origin), который широко применяется в рамках платформы Mozilla. Согласно этому принципу, скрипт может использовать лишь ресурсы, доступные при помощи того же протокола, по тому же доменному имени и номеру порта IP, что и сам скрипт или содержащий его документ. Таким образом, скрипт, полученный по протоколу HTTP с сервера www.test.com, не может взаимодействовать с Web-страницами, полученными с таких ресурсов, как www.pages.com, ftp://www.test.com или даже www.test.com:99 (если сам скрипт не был получен с порта 99).

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

Принцип "общего источника" не распространяется на специальный URL about:blank, который доступен для любых скриптов.

16.5.4.2. Режим защиты Trusted

Режим Trusted (режим доверия) представляет собой противоположность режиму Web Safe. В режиме Trusted на выполнение скриптов не налагается никаких ограничений. Они могут осуществлять доступ к любым компонентам XPCOM, а также скриптам и документам из любого источника без каких-либо ограничений или подтверждений пользователя. Скрипты и другие ресурсы, установленные в chrome, выполняются в режиме Trusted. В частности, они никогда не запрашивают разрешения пользователя на доступ к тем или иным объектам.

Некоторая проблема заключается в том, что при добавлении к chrome нового содержимого практически невозможно удостовериться в отсутствии у него вредоносных функций. Система XPInstall, о которой идет речь в "Система распространения и установки - XPInstall" "Развертывание", в настоящее время не требует аутентификации пакетов, устанавливаемых в chrome. Для такой аутентификации было бы необходимо использование сертификатов или цифровых подписей. Это означает, что в настоящее время подлинность указанного источника пакета, устанавливаемого в chrome, не гарантирована. Теоретически возможна ситуация, при которой пользователь соглашается установить пакет в chrome, будучи введен в заблуждение недостоверной информацией о его происхождении, приведенной в пакете. В результате вредоносный скрипт может получить все права, предоставляемые режимом Trusted. На практике сведения о таких атаках на платформу Mozilla отсутствуют.

16.5.4.3. Режим защиты Certified

Режим Certified (защита на основе сертификатов) можно рассматривать как промежуточный между режимами Web Safe и Trusted. Скрипты и другие ресурсы могут быть защищены при помощи цифровой подписи. В свою очередь, подлинность открытого ключа, используемого для проверки этой подписи, (принадлежность ключа определенному владельцу) может быть подтверждена специальной организацией – центром сертификации. В режиме Certified на любые скрипты до проверки их цифровой подписи распространяются те же ограничения, что и в режиме Web Safe. После того, как подпись проверена и сертификат, удостоверяющий подлинность ее открытого ключа, принят пользователем (непосредственно или в силу ранее выбранных установок), скрипт выполняется в режиме Trusted.

Цифровые подписи и сертификаты – самостоятельная обширная тема, поэтому здесь мы затронем лишь те ее аспекты, которые значимы для прикладных скриптов. Для цифровой подписи скриптов и других ресурсов используется утилита SignTool. Эта утилита не входит в состав Mozilla, но доступна вместе с документацией на ресурсе компании Netscape http://devedge.netscape.com. SignTool позволяет не только подписывать файлы, но и генерировать тестовые сертификаты, которые могут использоваться в процессе отладки вместо "настоящих" сертификатов. Последние, как правило, выдаются центрами сертификации за плату.

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

Разница между режимами защиты Trusted и Certified состоит в том, что последний требует, как минимум, одного интерактивного подтверждения со стороны пользователя. Единственный способ избежать этого – создать специализированный вариант платформы, где необходимая информация о сертификатах и разрешениях уже содержится в профиле пользователя с момента установки.

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

user_pref("signed.applets.codebase_principal_support", 
true);

Эта настройка полезна, главным образом, при разработке и отладке приложений, которые будут выполняться в режиме защиты Certified.

Если приложение использует модель защиты Certified, каждый фрагмент кода (скрипт) перед тем, как выполнить операцию, запрещенную в режиме Web Safe (например, обращение к объекту XPCOM), должен запросить у пользователя необходимые привилегии. Это делается при помощи следующей функции:

window.netscape.security.PrivilegeManager.enablePrivilege("
P1 P2 P3");

Эта функция запрашивает у пользователя подтверждение, открывая диалоговое окно, и, в случае согласия, предоставляет скрипту необходимые привилегии. Если соответствующее разрешение было дано раньше и сохранено в настройках пользователя, привилегии предоставляются без обращения к пользователю. При этом скрипт получает не все права, соответствующие режиму Trusted, а лишь запрошенные привилегии. Действие привилегий прекращается с окончанием текущей области видимости JavaScript (как правило – при выходе из данной функции или метода).

В данном примере "P1 P2 P3" представляет собой список ключевых слов привилегий, разделенных пробелами. В вызове метода enablePrivilege должно быть использовано, по крайней мере, одно ключевое слово. Допустимые ключевые слова, а также функциональность, на которую распространяются соответствующие привилегии, приведены в таблице 16.20. Во внутренней реализации платформы наличие необходимых привилегий проверяется в разных местах, что обеспечивает высокий уровень защиты.

Данные, приведенные в таблице, любезно предоставлены Джесси Рудерманом и mozilla.org.

16.5.4.4. Режим защиты Domain Policied

В режиме защиты Domain Policied (политика защиты на основе доменов) те или иные действия разрешаются или запрещаются всем документам, происходящим из определенного источника. Под источником, как и в принципе "общего источника", понимается совокупность протокола, доменного имени и номера порта. Этот режим защиты позволяет разрешать или запрещать скриптам JavaScript выполнение определенных операций. Совокупность разрешений и запретов объединяется в элемент конфигурации, называемый политикой. Одна политика может применяться к нескольким источникам. Эта модель защиты наиболее сложна и редко используется в приложениях Mozilla.

С другой стороны, она является наиболее гибкой – при ее использовании на выполнение скриптов может быть наложено как меньше, так и больше ограничений, чем в режиме Web Safe. Таким образом, в зависимости от конкретных настроек режим Domain Policied может быть как наиболее свободным, так и наиболее строгим режимом защиты.

Большинство параметров, связанных с режимом Domain Policied, недоступны пользователю через графический интерфейс настроек Mozilla. Некоторые из доступных настроек реализованы с помощью этой системы защиты, однако данный факт для конечного пользователя неочевиден.

Данная система защиты реализована для следующих целей:

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

Чтобы использовать эту модель защиты, необходимо добавить к пользовательским настройкам определенные правила. Это можно сделать в три этапа: определить имя политики защиты; задать источники, к которым применима эта политика; задать правила доступа к конкретным объектам для данной политики. Ниже мы последовательно рассмотрим все эти этапы.

Существует три типа имен политик защиты – явные имена, групповое имя и политика по умолчанию. Эти имена образуют иерархию. Каждое свойство или объект, для которых может быть определено правило доступа, могут быть связаны с одним из имен каждого типа.

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

На следующем уровне находится групповая политика, обозначенная именем "*" (звездочка). Она применяется в том случае, если задана в явном виде, и имеет приоритет над политиками по умолчанию.

На вершине иерархии находятся политики, заданные явными именами. Их имена всегда должны быть определены в явном виде. Эти политики имеют приоритет над всеми прочими.

Для задания имен политик используются следующие настройки:

user_pref("capability.policy.policynames","p1 test foo");
user_pref("capability.policy.default_policynames","normal,off");

Имена политик не могут содержать символ точки, списки имен разделяются пробелами или запятыми. В первой строке заданы имена трех политик; во второй строке заданы имена двух политик по умолчанию. Существует единственная групповая политика с именем "*", поэтому имя для нее не нужно задавать в явном виде.

Определив имена политик, необходимо задать для каждой политики список источников. Каждая политика применяется лишь к документам, полученным из указанных для нее источников. Ниже приведен пример задания источников для политики с именем mypol:

user_pref("capability.policy.mypol.sites", "http://test.com http://x.org");

Значением свойства в данном случае является список URL, разделенных пробелами или запятыми. URL может относиться к серверу в целом, но не к отдельным его каталогам. Каждый сайт не может входить более чем в одну строку настроек такого вида. Если указанная политика является политикой по умолчанию, именно она будет политикой по умолчанию для перечисленных сайтов. Это позволяет использовать для различных сайтов различные политики по умолчанию. Если вы хотите задать сайты, к которым должна применяться групповая политика, укажите * вместо mypol.

После того, как заданы имена политик и соответствующие источники, остается определить правила доступа. Существует три типа правил. Каждому правилу соответствует одна строка в файле настроек пользователя.

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

user_pref("capabilities.policy.mypol.Iface.Prop","Keywords")

Iface, Prop и Keywords необходимо заменить соответствующими строками.

• Iface – имя объекта JavaScript, которому принадлежит нужное свойство. На практике в качестве имени объекта должно использоваться имя интерфейса XPCOM с удаленным префиксом nsIDOM. Примерами допустимых имен являются ChromeWindow, HTMLDocument и XULImageElement. Некоторые объекты DOM имеют сокращенные имена, например Image, однако в данном случае должно использоваться полное имя – HTMLImageElement.
• Prop – имя свойства, к которому относится правило доступа. Как правило, оно представляет собой атрибут или метод интерфейса XPCOM, например свойство value для многих элементов HTML-форм.
• Keywords – разделенный пробелами или запятыми список имен привилегий, приведенных в таблице 16.20 или одно из следующих ключевых слов: AllAccess, NoAccess или sameOrigin. AllAccess эквивалентно указанию всех ключевых слов из таблицы 16.20. sameOrigin означает, что будут применяться ограничения режима Web Safe. NoAccess полностью запрещает доступ к свойству как на чтение, так и на запись.

Ниже приведен пример правила:

user_pref("capabilities.policy.*.History.back","NoAccess");

Это правило означает, что групповая политика запрещает использование метода back() объекта nsIDOMHistory. Этот объект используется только в браузере Mozilla, и приведенное правило отключает функцию возврата к ранее просмотренным страницам.

Второй тип синтаксиса применяется только к атрибутам JavaScript (свойствам, не являющимся методами) и позволяет разрешать или запрещать операции ECMAScript [[Get]] и [[Set]] для этих атрибутов. Правила имеют следующий вид:

user_pref("capabilities.policy.mypol.Iface.Prop.Access","Keyword");

Iface и Prop имеют то же значение, что и в предыдущем случае. Keywords должно иметь одно из следующих значений: AllAccess, NoAccess или sameOrigin. Access должно быть одной из двух строк – set или get. Таким образом, этот синтаксис допускает два правила для каждого свойства – для чтения и для записи. Ниже приведен пример правила, которое запрещает изменять текст заголовка окон XUL:

user_pref("capabilities.policy.default.ChromeWindow.title.set","NoAccess");

Третий тип синтаксиса относится к JavaScript в целом. Он позволяет при помощи единственного правила полностью запретить или разрешить выполнение скриптов JavaScript для группы источников:

user_pref("capabilities.policy.mypol.javascript.enabled","Keyword");

В этом случае можно задать лишь имя политики и значение строки Keyword. Вместо Keyword можно поставить одно из двух значений: NoAccess (отключить JavaScript) или AllAccess (активизировать JavaScript). Если JavaScript отключен глобально, правила такого типа игнорируются.

Типичная политика содержит ряд правил такого рода, разрешающих или запрещающих определенные действия. Если вы хотите запретить какое-либо действие, будьте внимательны и задайте правила для всех свойств, которые могут обеспечивать доступ к этому действию. Чтобы получить полный список свойств, следует изучить нужный объект при помощи Инспектора DOM, выбрав для правой панели Инспектора режим JavaScript Object.

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

Согласно "Оранжевой книге" Министерства обороны США, защита на основе политики является ограниченной формой защиты. Она основана на так называемом дискреционном контроле доступа; принятие любых мер по защите оставлено на усмотрение администратора (составителя политики). Кроме того, для обеспечения эффективной защиты составитель политики должен предусмотреть все возможные обходные пути доступа к защищаемым свойствам.

16.5.4.5. Специальные ограничения

Следует упомянуть еще несколько ограничений, которые не относятся к описанным режимам защиты. Эти ограничения действуют, по крайней мере, начиная с версии Mozilla 1.4.

• Невозможно загрузить набор строк из удаленного источника, поскольку код платформы для работы с наборами строк не поддерживает протокола HTTP.
• Если апплет Java подписан, JavaScript не может обращаться к привилегированным методам данного объекта.

На этом обсуждение системы защиты платформы Mozilla заканчивается.

16.5.5. Профили пользователя

Служба каталогов Mozilla обеспечивает доступ к папкам и каталогам текущего профиля пользователя. Также можно управлять набором существующих профилей. Для этого используется следующая пара XPCOM:

@mozilla.org/profile/manager;1 nsIProfile

Однако интерфейс nsIProfile не позволяет осуществлять доступ к файлам внутри заданного профиля. Для этого используется другая пара XPCOM:

@mozilla.org/profile/manager;1 nsIProfileInternal