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

  • Статья

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

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

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

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

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

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

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

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

  • Не используйте удаленное взаимодействие .NET.

  • Не используйте модель DCOM.

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

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

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

  • Контейнеры AppContainer

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

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

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

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

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

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

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

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

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

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

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

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

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

См. также