Вопросы безопасности сценариев JScript
Обновлен: Ноябрь 2007
Задача создания безопасного кода ставится в любом языке программирования. В языке JScript имеется несколько областей, в которых разработчики, сами того не зная, могут использовать код небезопасным образом, поскольку язык не требует от разработчиков использовать наиболее эффективные методы. При разработке языка JScript обеспечение безопасности рассматривалось как одна из приоритетных задач, однако основным назначением этого языка является быстрое создание эффективных приложений. В некоторых случаях эти две цели вступают в противоречие.
Можно избежать многих проблем безопасности, если принять во внимание потенциальные проблемы, которые могут возникать в некоторых ключевых областях. Эти проблемы перечислены ниже. Большинство вопросов безопасности (за исключением метода eval) связаны с новыми функциональными возможностями, появившимися в среде .NET Framework.
Метод eval
Чаще всего в языке JScript неправильно используют метод eval, который обеспечивает динамическое выполнение исходного кода JScript. Поскольку приложение JScript, в котором используется метод eval, может выполнять любой код, переданный ему программой, каждый вызов метода eval создает угрозу безопасности. Если приложение не должно быть настолько гибким, чтобы выполнять любой код, старайтесь явно записывать код, который приложение передает в метод eval.
Чтобы повысить безопасность приложений, которым требуется использовать все возможности метода eval, код, передаваемый в метод eval, по умолчанию выполняется в ограниченном контексте. Ограниченный контекст безопасности позволяет запретить доступ ко всем системным ресурсам, таким как файловая система, сеть или пользовательский интерфейс. При попытке доступа кода к таким ресурсам создается исключение. Тем не менее, код, выполняемый методом eval, может изменять локальные и глобальные переменные. Дополнительные сведения см. в разделе Метод eval.
Для кода, созданного в предыдущих версиях JScript, может требоваться, чтобы метод eval выполнял этот код в том контексте, в котором был вызван метод. Для поддержки такого поведения можно передать строку "unsafe" в качестве необязательного второго параметра метода eval. В этом случае следует выполнять только те строки кода, которые получены из надежного источника, поскольку в "небезопасном" режиме эти строки выполняются с теми же разрешениями, которые предоставлены вызывающему коду.
Атрибуты безопасности
Атрибуты безопасности, установленные по умолчанию в языке JScript, можно явно переопределить атрибутами безопасности среды .NET Framework. Однако значения параметров безопасности по умолчанию следует изменять только в том случае, если пользователь хорошо понимает все последствия этого действия. В частности, не следует применять пользовательский атрибут AllowPartiallyTrustedCallers (APTCA), поскольку ненадежные вызывающие объекты, как правило, не могут обеспечить безопасность при выполнении кода JScript. При создании доверенной сборки с атрибутом APTCA, которая затем загружается приложением, вызывающие объекты с неполным доверием получают доступ к полностью доверенным сборкам приложения. Дополнительные сведения см. в разделе Правила написания безопасного кода.
Код с неполным доверием и размещенный код JScript
Система, в которой размещается JScript, позволяет любому вызываемому коду изменять некоторые части этой системы, такие как глобальные и локальные переменные или цепочки прототипов произвольного объекта. Кроме того, любая функция может изменять свойства или методы "expando" произвольного переданного ей объекта "expando". Поэтому, если приложение JScript вызывает код с неполным доверием или выполняется в приложении с другим кодом (например, в ведущем приложении Visual Studio for Applications [VSA]), поведение приложения может быть изменено.
Вследствие этого, любой код JScript в приложении (или в экземпляре класса AppDomain) должен выполняться с уровнем доверия, который не превышает уровень доверия остального кода в приложении. В противном случае другой код получить возможность управлять системой класса JScript, который, в свою очередь, изменит данные и повлияет на другой код в приложении. Дополнительные сведения см. в разделе _AppDomain.
Доступ к сборкам
Код JScript может ссылаться на сборки, используя строгие имена или простые текстовые имена. Строгое имя содержит сведения о версии сборки, а также криптографическую подпись, которая подтверждает целостность и идентичность сборки. Конечно, при ссылке на сборку удобнее использовать простое имя, однако строгое имя помогает защитить код в том случае, когда в системе имеется другая сборка с тем же простым именем, но другой функциональностью. Дополнительные сведения см. в разделе Практическое руководство. Создание ссылки на сборку со строгим именем.
Работа с потоками
Среда выполнения JScript не обеспечивает потокобезопасность. Поэтому многопоточный код JScript может вести себя непредсказуемым образом. При разработке сборки на языке JScript следует учесть, что она может использоваться в многопоточном контексте. Чтобы при выполнении кода JScript в сборке выполнялась правильная синхронизация с другими потоками, необходимо использовать классы пространства имен System.Threading, например класс Mutex.
Написание кода с правильной синхронизацией представляет сложную задачу в любом языке, поэтому не следует создавать в JScript сборки общего назначения, за исключением случаев, когда разработчик прекрасно понимает, как реализовать необходимый код синхронизации. Дополнительные сведения см. в разделе System.Threading.
.gif "Примечание") Примечание. |
|---|
Для приложений ASP.NET, написанных на языке JScript, писать код синхронизации не требуется, поскольку технология ASP.NET сама управляет синхронизацией порождаемых ею потоков. Однако веб-элементы управления, написанные на языке JScript, должны содержать код синхронизации, поскольку они ведут себя как сборки. |
Ошибка времени выполнения
Поскольку JScript является слабо типизированным языком, он более устойчив к возможным несоответствиям типов, чем другие языки программирования, такие как Visual Basic и Visual C#. Несоответствия типов могут вызывать в приложениях ошибки времени выполнения, поэтому при разработке кода очень важно выявить все возможные несоответствия. Можно использовать параметр /warnaserror при выполнении компиляции из командной строки или атрибут warninglevel директивы @ Page на страницах ASP.NET. Дополнительные сведения см. в разделах /warnaserror и @ Page.
Режим совместимости
Сборки, скомпилированные в режиме совместимости (то есть с параметром /fast-), в меньшей степени зашифрованы, чем сборки, скомпилированные в быстром режиме (который является режимом по умолчанию). Параметр /fast- обеспечивает поддержку возможностей языка, которые недоступны по умолчанию, но требуются для совместимости со сценариями, написанными на языке JScript 5.6 или более ранних версий. В режиме совместимости, например, можно динамически добавлять свойства "expando" к встроенным объектам, таким как объект String.
Режим совместимости предоставляется для помощи разработчикам, которым необходимо выполнять построение автономных исполняемых файлов на основе устаревшего кода JScript. При разработке новых исполняемых файлов или библиотек используйте режим по умолчанию. Этот режим, во-первых, позволяет защитить приложения, а также помогает обеспечить более высокую производитель и улучшенное взаимодействие с другими сборками. Дополнительные сведения см. в разделе /fast.
См. также
Основные понятия
Обновление приложений, созданных в предыдущих версиях JScript