[System.Security.Permissions.PermissionSetAttribute(System.Security.

  Permissions.SecurityAction.InheritanceDemand, Name="FullTrust")]

[System.Security.Permissions.PermissionSetAttribute

  (System.Security.Permissions.SecurityAction.LinkDemand, Name="FullTrust")]

public class CanDeriveFromMe

[System.Security.Permissions.PermissionSetAttribute

  (System.Security.Permissions.SecurityAction.LinkDemand, Name="FullTrust")]

public sealed class CannotDeriveFromMe

[System.Security.Permissions.PermissionSetAttribute

  (System.Security.Permissions.SecurityAction.InheritanceDemand, Name="FullTrust")]

[System.Security.Permissions.PermissionSetAttribute

  (System.Security.Permissions.SecurityAction.LinkDemand, Name="FullTrust")]

public abstract class CannotCreateInstanceOfMe_CanCastToMe

class Base {

[System.Security.Permissions.PermissionSetAttribute

  (System.Security.Permissions.SecurityAction.InheritanceDemand,

  Name="FullTrust")]

[System.Security.Permissions.PermissionSetAttribute(

  System.Security.Permissions.SecurityAction.LinkDemand,

  Name="FullTrust")]

public override void CanOverrideOrCallMe() { ... }

class Base {

[System.Security.Permissions.PermissionSetAttribute

  (System.Security.Permissions.SecurityAction.InheritanceDemand, Name="FullTrust")]

[System.Security.Permissions.PermissionSetAttribute

  (System.Security.Permissions.SecurityAction.LinkDemand,

  Name="FullTrust")]

public override void CanOverrideMe() { ... }

class Derived {

[System.Security.Permissions.PermissionSetAttribute

(System.Security.Permissions.SecurityAction.Demand, Name="FullTrust")]

public override void CanOverrideOrCallMe() { ... }

class Derived {

[System.Security.Permissions.PermissionSetAttribute

  (System.Security.Permissions.SecurityAction.LinkDemand,

  Name="FullTrust")]

public override void CanOverrideOrCallMe() { ... }

[System.Security.Permissions.PermissionSetAttribute

  (System.Security.Permissions.SecurityAction.InheritanceDemand,

  Name="FullTrust")]

[System.Security.Permissions.PermissionSetAttribute

  (System.Security.Permissions.SecurityAction.LinkDemand,

  Name="FullTrust")]

public interface CanCastToMe

Demand и LinkDemand

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

Итак, декларативная защита поддерживает следующие проверки.

Применяя LinkDemand, вам придется самостоятельно позаботиться о дополнительных мерах предосторожности (в реализации эти мер вам поможет система защиты). Любая ошибка откроет брешь в защите. Для реализации дополнительной защиты любой авторизованный код, использующий ваш код, должен:

• ограничивать доступ вызывающего кода к классу или сборке;
• выполнять те же проверки защиты в вызывающем коде и заставлять делать то же самое вызывающих. Например, если вы пишете код, который вызывает метод, защищенный LinkDemand для разрешения SecurityPermission.UnmanagedCode, ваш метод также должен выполнять проверку LinkDemand (или более строгую проверку Demand) этого разрешения. Исключение составляет тот случай, когда ваш код вызывает метод, защищенный LinkDemand, с соблюдением определенных ограничений, обеспечивающих безопасность (по крайней мере, на ваш взгляд) через другие механизмы защиты, например запросы. В этом исключительном случае вызывающий берет на себя ответственность за ослабление защиты в нижележащем коде;
• гарантировать, что вызывающие не смогут обманом использовать защищенный код в своих интересах (т. е. не смогут заставить авторизованный код передавать защищенному коду определенные параметры или получать возвращаемые им результаты).

Интерфейсы и проверки LinkDemand

Если виртуальный метод, свойство или событие с проверкой LinkDemand переопределяет метод базового класса, то к методу базового класса тоже должна применяться проверка LinkDemand, чтобы обеспечить безопасность переопределенного метода. Злонамеренный код может привести тип обратно к базовому и вызвать метод базового класса. Кроме того, имейте в виду, что проверки LinkDemand могут неявно добавляться к сборкам, у которых нет атрибута AllowPartiallyTrustedCallersAttribute уровня сборки.

При защите реализаций методов с помощью LinkDemand желательно использовать LinkDemand и для методов интерфейса.

Используя проверки LinkDemand при работе с интерфейсами, имейте в виду следующее.

• Атрибут AllowPartiallyTrustedCallers может влиять на интерфейсы.
• Вы можете указывать для интерфейсов проверки LinkDemand, чтобы выборочно запрещать частично доверяемому коду обращение к определенным интерфейсам, например при использовании атрибута AllowPartiallyTrustedCallers.
• Если вы определили интерфейс в сборке, не содержащей атрибута AllowPartiallyTrustedCallers, то можете реализовать этот интерфейс для частично доверяемого класса.
• Если указать LinkDemand для открытого метода класса, реализующего метод интерфейса, то LinkDemand не сработает при приведении типа к интерфейсу и вызове метода. В этом случае - из-за того, что вы осуществляете связывание с интерфейсом, - LinkDemand выполняется только для интерфейса.

Кроме того, примите во внимание следующее.

• Явные требования к связыванию (explicit link demands) для методов интерфейса. Убедитесь, что эти требования обеспечивают ожидаемый уровень защиты. Проверьте, может ли злонамеренный код использовать приведение типов, чтобы обойти требования к связыванию ранее описанным способом.
• Виртуальные методы с требованиями к связыванию.
• Типы и реализуемые ими интерфейсы должны согласованно использовать проверки LinkDemand.

Внутренние виртуальные переопределения

Учтите одну тонкость, если вы хотите, чтобы к вашему коду нельзя было обращаться из других сборок. Метод, объявленный как virtual и internal, может переопределять запись в таблице виртуальных методов (vtable) базового класса и доступен только в пределах своей сборки, так как является внутренним. Однако ключевое слово virtual делает метод доступным для переопределения, и он может быть переопределен из другой сборки, если ее код имеет доступ к самому классу. Чтобы исключить возможность переопределения, используйте декларативную защиту или удалите ключевое слово virtual, если в нем нет острой необходимости.

Код оболочки

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

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

Делегаты

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

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

Проверки LinkDemand и оболочки

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

Если полностью доверяемый код вызывает свойство, событие или метод, защищенный LinkDemand, вызов выполняется успешно при успешной проверке разрешений LinkDemand. Кроме того, если полностью доверяемый код предоставляет класс, который принимает имя свойства и вызывает его аксессор get через механизм отражения, то вызов аксессора get выполняется успешно, даже если у пользовательского кода нет прав доступа к этому свойству. Дело в том, что LinkDemand проверяет непосредственного вызывающего, который является полностью доверяемым кодом. По сути, полностью доверяемый код выполняет привилегированный вызов в интересах пользовательского кода, не проверяя, есть ли у него право на такой вызов. Если вы создаете оболочку для функциональности, использующей механизм отражения, прочтите статью Version 1 Security Changes for the Microsoft .NET Framework.

Чтобы избежать дыр в защите, подобных описанной выше, исполняющая среда полностью проверяет стек при любом использовании метода Invoke (создавая экземпляр или вызывая метод, аксессор set или get) для вызова метода, конструктора, свойства или события, защищенного требованием к связыванию (link demand). Такая защита вызывает некоторое снижение производительности (одноуровневая проверка LinkDemand проходит быстрее) и изменяет семантику проверки защиты - полная проверка стека может потерпеть неудачу там, где одноуровневая проверка пройдет успешно.

Оболочки, загружающие сборки

Несколько методов, используемых для загрузки управляемого кода, в частности Assembly.Load(byte[]), загружают сборки с признаком (evidence) вызывающего. Если вы создаете оболочки для таких методов, система защиты при загрузке сборок будет использовать разрешения вашего кода вместо разрешений вызывающего. Вы вряд ли захотите, чтобы через вашу оболочку менее доверяемый код мог загружать по своему усмотрению код, которому выдаются более высокие разрешения по сравнению с вызывающим.

Любой полностью доверяемый код или код, значительно более доверяемый по сравнению с потенциальными вызывающими (в том числе обладающими разрешениями уровня кода, загружаемого из Интернета), может оказаться уязвимым по отношению к такому ослаблению безопасности. Если в вашем коде есть открытый метод, который принимает массив байтов и передает его Assembly.Load(byte[]), тем самым создавая сборку в интересах вызывающего, это может привести к разрушению защиты.

Такая проблема возникает при использовании следующих API-элементов:

• System.AppDomain.DefineDynamicAssembly
• System.Reflection.Assembly.LoadFrom
• System.Reflection.Assembly.Load

Обработка исключений

Выражение фильтра (filter expression), расположенное выше по стеку, вычисляется до выполнения любого оператора finally. Блок catch, связанный с этим фильтром, выполняется после оператора finally. Рассмотрим следующий псевдокод:

void Main() {

    try {

        Sub();

    } except (Filter()) {

        Console.WriteLine("catch");

    }

}

bool Filter () {

    Console.WriteLine("filter");

    return true;

}

void Sub() {

    try {

        Console.WriteLine("throw");

        throw new Exception();

    } finally {

        Console.WriteLine("finally");

    }

}                     

Вот что выводит этот код:

Throw

Filter

Finally

Catch

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

            try {

                        Alter_Security_State();

                           // Здесь возможны любые изменения (изменение

                           // переменных состояния, переключение в

                           // неуправляемый контекст, олицетворение и т. д.).

                           // Этим может воспользоваться злонамеренный код,

                           // выполняемый до восстановления состояния.

                        Do_some_work();

            } finally {

                        Restore_Security_State();

                           // Здесь просто восстанавливается ранее

                           // измененное состояние.

            }

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

Рекомендуемое решение - ввести обработчик исключения, изолирующий изменения в состоянии потока вашего кода от блоков фильтрации вызывающих. Однако важно правильно установить обработчик исключения, иначе решить эту проблему не удастся. В следующем примере код на Microsoft Visual Basic® переключает культуру пользовательского интерфейса (UI), но аналогичным образом возможны и другие изменения состояния потока.

YourObject.YourMethod()

{

   CultureInfo saveCulture = Thread.CurrentThread.CurrentUICulture;

   try {

      Thread.CurrentThread.CurrentUICulture = new CultureInfo("de-DE");

      // Выполняется действие, приводящее к генерации исключения.

}

   finally {

      Thread.CurrentThread.CurrentUICulture = saveCulture;

   }

}



Public Class UserCode

   Public Shared Sub Main()

      Try

         Dim obj As YourObject = new YourObject

         obj.YourMethod()

      Catch e As Exception When FilterFunc

         Console.WriteLine("An error occurred: '{0}'", e)

         Console.WriteLine("Current Culture: {0}",

Thread.CurrentThread.CurrentUICulture)

      End Try

   End Sub



   Public Function FilterFunc As Boolean

      Console.WriteLine("Current Culture: {0}", Thread.CurrentThread.CurrentUICulture)

      Return True

   End Sub



End Class

Правильным решением в этом случае является включение существующего блока try/finally в блок try/catch. Простое указание catch-throw в существующем блоке try/finally не решает проблему:

YourObject.YourMethod()

{

   CultureInfo saveCulture = Thread.CurrentThread.CurrentUICulture;



   try {

      Thread.CurrentThread.CurrentUICulture = new CultureInfo("de-DE");

      // Выполняется действие, приводящее к генерации исключения.

}

catch { throw; }

   finally {

      Thread.CurrentThread.CurrentUICulture = saveCulture;

   }

}

Проблема не решается, так как оператор finally не выполняется до тех пор, пока функция FilterFunc не получит управление.

Но в следующем коде эта проблема устранена, так как оператор finally гарантировано выполняется до проверки исключения блоками фильтрации исключений вызывающего.

YourObject.YourMethod()

{

   CultureInfo saveCulture = Thread.CurrentThread.CurrentUICulture;

   try {

      try {

         Thread.CurrentThread.CurrentUICulture = new CultureInfo("de-DE");

         // Выполняется действие, приводящее к генерации исключения.

}

      finally {

         Thread.CurrentThread.CurrentUICulture = saveCulture;

      }

   }

   catch { throw; }

}

Неуправляемый код

Иногда библиотечный код должен вызывать неуправляемый код (например, встроенные функции такого API, как Win32). Поскольку это означает выход за периметр защиты управляемого кода, соблюдайте осторожность. Если ваш код нейтрален к защите (см. раздел Код, нейтральный к защите), то и ваш код, и код, который его вызывает, должен иметь разрешения на выполнение неуправляемого кода (SecurityPermission.UnmanagedCode).

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

Когда ваш код вызывает неуправляемый код, но вы не хотите, чтобы вызывающие вас могли делать то же самое, объявляйте (assert) свои права. Объявление блокирует проверку стека в пределах вашего фрейма. Будьте крайне осторожны, чтобы при этом не создать дыру в системе защиты. Обычно это означает, что вы должны запрашивать соответствующие разрешения для вызывающих и в дальнейшем использовать неуправляемый код только для выполнения действий, предусмотренных разрешениями. В некоторых случаях (например, при получении времени дня) неуправляемый код можно напрямую предоставлять вызывающим без проверки защиты. Но любой код, объявляющий права, всегда несет ответственность за безопасность.

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

Использование SuppressUnmanagedCodeSecurity

При объявлении прав (asserting) и последующем вызове неуправляемого кода следует принимать во внимание вопросы производительности. При каждом таком вызове система защиты автоматически запрашивает разрешение неуправляемого кода, из-за чего каждый раз проверяется весь стек. Если вы объявили права и тут же вызвали неуправляемый код, проверять стек бессмысленно: в нем содержатся только ваши объявление прав и вызов неуправляемого кода.

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

При использовании атрибута SuppressUnmanagedCodeSecurity учитывайте следующее.

• Точка входа в неуправляемый код должна быть недоступной вне вашего кода (ее можно, например, объявить как внутреннюю).
• Любое место, из которого вызывается неуправляемый код, - потенциальная дыра в системе защиты. Убедитесь, что ваш код не служит своего рода порталом для злонамеренного кода, позволяющим косвенно вызывать неуправляемый код и обходить проверку защиты. Если есть возможность, требуйте разрешения.
• Используйте такую схему именования, которая позволяет четко видеть потенциально рискованный путь доступа к неуправляемому коду (об этом рассказывается в следующем разделе).

Схема именования методов неуправляемого кода

Для методов неуправляемого кода весьма полезна и настоятельно рекомендуется следующая схема именования. Все методы неуправляемого кода делятся на три категории: safe (безопасный), native ("родной") и unsafe (небезопасный). Эти ключевые слова можно использовать как имена классов, содержащих точки входа в неуправляемый код. В исходном коде эти ключевые слова следует добавлять к имени класса, например Safe.GetTimeOfDay, Native.Xyz или Unsafe.DangerousAPI. Принадлежность к любой из этих категорий однозначно указывает разработчикам, как использовать метод (см. таблицу ниже).

Пользовательский ввод

Пользовательские данные, каким бы образом они ни передавались (через Web-запрос или URL, ввод в элементы управления Microsoft Windows Forms и т. д.), могут неблагоприятно повлиять на код, так как эти данные часто напрямую используются в качестве параметров при вызове другого кода. Эта ситуация аналогична той, где злонамеренный код вызывает ваш код, передавая недопустимые параметры, так что она требует принятия тех же мер предосторожности. На практике сделать пользовательский ввод безопасным гораздо труднее, так как в этом случае нет стека, где можно было бы проверить наличие потенциально недоверяемых данных.

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

Ниже перечислено, на что следует обращать внимание при работе с пользовательскими данными.

· Любые пользовательские данные, возвращаемые сервером, обрабатываются на клиенте в контексте сайта сервера. Если ваш Web-сервер получает данные от пользователя и вставляет их в возвращаемую Web-страницу, то они могут, например, содержать тэг <script> и выполняться так, будто получены с сервера.

• Помните, что клиент может запросить любой URL.
• Учитывайте возможность ввода "хитрых" или неправильных путей:
  • ..\ , а также крайне длинных путей;
  • использования знаков подстановки (*);
  • раскрытия маркеров (%token%);
  • путей странного вида, имеющих особый смысл;
  • альтернативных имен NTFS-потоков (streams), например имя_файла::$DATA;
  • кратких версий имен файлов, например longfilename и longfi~1.
• Eval(пользовательские_данные) позволяет делать что угодно.
• Позднее связывание (late binding) с именем, включающим некие пользовательские данные.
• Если вы имеете дело с Web-данными, учитывайте допустимость разных видов escape-последовательностей, в том числе:
  • шестнадцатеричных последовательностей (%nn);
  • Unicode-последовательностей (%nnn);
  • очень длинных последовательностей UTF-8 (%nn%nn);
  • двойных последовательностей (%nn превращается в %mmnn, где %mm - escape-последовательность для '%').
• Будьте осторожны с именами пользователей, которые могут быть представлены более чем в одном каноническом формате. Так, в Microsoft Windows 2000 вместо username@redmond.microsoft.com нередко используется REDMOND\username.

Удаленное взаимодействие

Удаленное взаимодействие (remoting) позволяет реализовать прозрачные вызовы между доменами приложений (application domains, AppDomains), процессами или компьютерами. Однако защита по правам доступа кода не позволяет проверять стек при межмашинном или межпроцессном вызове (такая проверка выполняется только при вызовах между доменами приложений в одном и том же процессе).

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

Кроме того, обычно не следует предоставлять доступ к методам, свойствам или событиям, защищенным декларативными проверками защиты LinkDemand и InheritanceDemands. При удаленном взаимодействии эти проверки не выполняются. Другие проверки, например Demand, Assert и т. д., выполняются при взаимодействии между доменами приложения в процессе, но не между процессами и компьютерами.

Защищенные объекты

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

Рассмотрим, например, создание объекта FileStream. Во время создания запрашивается разрешение FileIOPermission и, если оно получено, возвращается файловый объект. Однако, если ссылка на этот объект передается объекту, не имеющему файловых разрешений, то последний получает возможность выполнять чтение/запись в данный файл.

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

Сериализация

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

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

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

Интерфейс ISerializable предназначен для использования только инфраструктурой сериализации. Однако, если он не защищен, через него можно получить доступ к закрытой информации. Если вам нужна нестандартная сериализация с реализацией интерфейса ISerializable, примите следующие меры предосторожности.

• GetObjectData следует явным образом защищать, требуя разрешение SecurityPermission.SerializationFormatter или добиваясь, чтобы в выходных данных метода не было закрытой информации. Например:
  
   

  [SecurityPermissionAttribute(SecurityAction.Demand,SerializationFormatter
  =true)]
  public override void GetObjectData(SerializationInfo info,
  StreamingContext context)
  
  

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

Проблемы, связанные с пересечением границ доменов приложений

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

Один домен приложения может заставить другой загрузить сборку и выполнить содержащийся в ней код вызовом прокси объекта, находящегося в другом домене приложения. Чтобы получить прокси из другого домена приложения, домен приложения, содержащий объект, должен передать его (как параметр метода или возвращаемое значение). Кроме того, если домен приложения только что создан, его создатель получает прокси объекта AppDomain. Таким образом, чтобы избежать нарушения изоляции кода, более доверяемый домен приложения не должен передавать ссылки на свои объекты MarshalByRefObject менее доверяемым доменам приложений.

Обычно домен приложения по умолчанию (default application domain) создает дочерние домены приложения с управляющим объектом (control object) в каждом из них. Этот объект управляет новым доменом приложения и иногда получает указания от домена приложения по умолчанию, но не может взаимодействовать с доменом напрямую. В некоторых случаях домен приложения по умолчанию вызывает свой прокси управляющего объекта. Однако возможны случаи, когда управляющему объекту необходимо выполнять обратный вызов домена приложения по умолчанию. Тогда домен приложения по умолчанию передает объект обратного вызова с маршалингом по ссылке конструктору управляющего объекта. За защиту этого прокси отвечает управляющий объект. Если управляющий объект поместит прокси в открытое статическое поле или открытый класс или каким-то другим способом откроет доступ к прокси, другой код сможет выполнять обратный вызов домена приложения по умолчанию, что весьма опасно. Поэтому управляющие объекты всегда неявно хранят прокси в закрытом виде.

Выдача разрешений

Защита на основе признаков основана на предположении, что высокий уровень доверия (с широкими полномочиями) присваивается лишь коду, заслуживающему доверия, а злонамеренный код является мало доверяемым или вообще не имеет разрешений. В политике по умолчанию в .NET Framework разрешения выдаются на основе зон (так, как они определены в Microsoft Internet Explorer). Ниже приведено упрощенное описание этой политики по умолчанию.

• Зона локального компьютера (например, c:\app.exe) является полностью доверяемой. Предполагается, что пользователи помещают на свой компьютер только код, которому они доверяют, и что большинство пользователей не собираются разбивать свой жесткий диск на области с разной степенью доверия. По существу, этот код может делать все, что угодно, поэтому от злонамеренного кода, находящегося в этой зоне, никакой защиты нет.
• Зона Интернета (например, http://www.microsoft.com/). Коду из этой зоны предоставляется очень ограниченный набор разрешений, который неопасно предоставить даже злонамеренному коду. Обычно этому коду нельзя доверять, поэтому его можно безопасно выполнять только с очень узкими разрешениями, с которыми он не сумеет нанести ущерб:
  • WebPermission - доступ к серверу сайта, с которого получен код;
  • FileDialogPermission - доступ только к файлам, специально указанным пользователем;
  • IsolatedStorageFilePermission - постоянное хранилище, ограниченное пределами Web-сайта;
  • UIPermission - возможность записи информации в окно пользовательского интерфейса.
• Зона интрасети (например, \\UNC\share). Код из этой зоны выполняется с чуть большими разрешениями, чем код из Интернета, но среди них все равно нет таких, которые предоставляли бы широкие полномочия:
  • FileIOPermission - доступ только для чтения к файлам каталога, из которого загружен код;
  • WebPermission - доступ к серверу, с которого загружен код;
  • DNSPermission - допускается разрешение DNS-имен в IP-адреса;
  • FileDialogPermission - доступ только к файлам, специально указанным пользователем;
  • IsolatedStorageFilePermission - постоянное хранилище (с меньшими ограничениями);
  • UIPermission - код может свободно использовать собственные окна верхнего уровня.
• Зона ограниченных сайтов, код из которой выполняется только с минимальными разрешениями.

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

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

Опасные разрешения

Для выполнения некоторых защищенных операций .NET Framework предоставляет разрешения, потенциально позволяющие обойти систему защиты. Эти опасные разрешения следует предоставлять только коду, заслуживающему доверия, и только при абсолютной необходимости. Обычно, если злонамеренный код получает такие разрешения, то защититься нельзя.

К опасным разрешениям относятся:

• SecurityPermission:
   
  • UnmanagedCode - позволяет управляемому коду вызывать неуправляемый код, что зачастую весьма опасно;
  • SkipVerification - код может делать что угодно без всякой верификации;
  • ControlEvidence - управление признаками позволяет обмануть систему защиты;
  • ControlPolicy - возможность изменять политику безопасности позволяет отключить защиту;
  • SerializationFormatter - за счет сериализации можно обойти управление доступом (см. раздел по сериализации);
  • ControlPrincipal - возможность указывать текущего пользователя позволяет обходить защиту на основе ролей;
  • ControlThread - возможность манипуляций с потоками опасна, так как с ними связано состояние защиты;
• ReflectionPermission:
  • MemberAccess - позволяет отключать механизм управления доступом (становится возможным использование закрытых членов).

Защита и конкуренция

Еще одна проблема обеспечения безопасности - возникновение дыр в системе защиты из-за конкуренции (race conditions). Конкуренция проявляется в нескольких ситуациях. В следующих подразделах рассказывается о некоторых типичных ловушках, которых должны избегать разработчики.

Конкуренция в методе Dispose

Если метод Dispose класса не синхронизирован, код очистки в этом методе может быть выполнен более одного раза. Рассмотрим такой код:

void Dispose() {

   if( _myObj != null ) {

      Cleanup(_myObj);

      _myObj = null;

   }

}

Так как реализация Dispose не синхронизирована, возможна ситуация, когда Cleanup вызывается первым потоком, а затем - вторым потоком до того, как _myObj получит значение null. Возникнут ли при этом проблемы с безопасностью, зависит от того, что произойдет при выполнении кода Cleanup. Основная проблема, связанная с несинхронизированными реализациями Dispose, состоит в использовании описателей ресурсов (файлов и т. д.). Некорректное уничтожение объектов может привести к использованию не тех описателей, а это часто приводит к нарушению защиты.

Конкуренция в конструкторах

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

Конкуренция при использовании кэшированных объектов

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

void SomeSecureFunction() {

   if(SomeDemandPasses()) {

      _fCallersOk = true;

      DoOtherWork();

      _fCallersOk = false;

   }

}

void DoOtherWork() {

   if(  _fCallersOK ) {

      DoSomethingTrusted();

   }

   else {

      DemandSomething();

      DoSomethingTrusted();

   }

}

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

Если ваш код кэширует информацию, связанную с защитой, убедитесь в отсутствии этого слабого места.

Конкуренция при подготовке объекта к уничтожению

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

Другие технологии защиты

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

Генерация кода "на лету"

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

Вы всегда должны точно знать, какой код генерируется. Это значит, что нужно строго контролировать любые значения, получаемые от пользователя: строки в кавычках (их следует избегать, так как в них можно помещать непредсказуемые элементы кода), идентификаторы (проверяйте их на допустимость) и любые другие данные. Идентификаторы могут быть опасными, поскольку появляется возможность изменить скомпилированную сборку так, чтобы ее идентификаторы содержали "странные" символы, а это, вероятно, нарушит работу сборки (хотя во многих случаях это не создает уязвимости в защите).

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

Продумайте, не может ли злонамеренная программа изменить код при его компиляции. Посмотрите, не возникает ли небольшой промежуток времени, в течение которого злонамеренный код способен изменить исходный код на диске перед чтением компилятором или загрузкой DLL вашим кодом? Если да, защищайте каталог с этими файлами, используя в зависимости от ситуации защиту по правам доступа кода или список управления доступом (Access Control List, ACL) файловой системы.

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

Выполняйте сгенерированный код с наименьшими возможными разрешениями (используя PermitOnly или Deny).

Защита на основе ролей: аутентификация и авторизация

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

Управление секретами

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

Шифрование и подписи

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

Случайные числа

Если для системы защиты нужно генерировать случайные числа и требуется, чтобы они были истинно случайными, используйте System.Security.Cryptography.RandomNumberGenerator. Применение генераторов псевдослучайных чисел приводит к их предсказуемости, чем может воспользоваться злоумышленник.

Проблемы установки

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

1. Настройте систему на использование двух разделов жесткого диска.
2. Переформатируйте второй раздел; не изменяйте ACL по умолчанию в корневом каталоге диска.
3. Установите свою программу, сменив каталог установки на каталог, создаваемый во втором разделе.

Проверьте следующее.

1. Имеется ли код, выполняемый как служба или обычно запускаемый пользователями с правами администратора и доступный для записи кому угодно?
2. Если код устанавливался на терминальный сервер, работающий в режиме сервера приложений: могут ли одни пользователи записывать двоичные файлы, а другие - их запускать?
3. Есть ли файлы в системном каталоге или его подкаталогах, доступные для записи пользователям, отличным от администраторов?

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