Поделиться через

Рекомендации по безопасному написанию кода

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

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

В этом обзоре описаны различные способы работы кода с системой безопасности.

Защита доступа к ресурсам

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

  • Не используйте безопасность доступа к коду (CAS).

  • Не используйте частичный доверенный код.

  • Не используйте атрибут AllowPartiallyTrustedCaller (APTCA ).

  • Не используйте .NET Remoting.

  • Не используйте объектную модель распределенного компонента (DCOM).

  • Не используйте двоичные форматировщики.

Управление доступом к коду и код Security-Transparent не поддерживаются в качестве границы безопасности с частично доверенным кодом. Мы советуем загружать и выполнять код неизвестных источников без применения альтернативных мер безопасности. Альтернативные меры безопасности:

  • Виртуализация

  • Контейнеры приложений

  • Пользователи и разрешения операционной системы (ОС)

  • контейнеры Hyper-V

Нейтральный код безопасности

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

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

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

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

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

Управляемая оболочка для реализации машинного кода

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

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

Код библиотеки, предоставляющий защищенные ресурсы

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

См. также