Безопасность доступа к методам
Некоторые методы могут не подходить для их вызова произвольным ненадежным кодом. Использование таких методов несет в себе некоторые опасности: метод может дать доступ к некоторой закрытой информации, он может доверять любым полученным на входе данным, он может не осуществлять проверку значений параметров, а в случае получения параметров с некорректными значениями метод может работать неправильно или даже причинить вред. Необходимо отслеживать такие ситуации и принимать соответствующие меры для обеспечения безопасности метода.
В некоторых случаях может потребоваться особым образом ограничить методы, которые не предназначены для свободного использования, но тем не менее должны быть объявлены как открытые. Например, может использоваться интерфейс, который должен вызываться через данные библиотеки DLL, и, соответственно, должен быть открытым методом, но нежелательно предоставлять к нему общий доступ, чтобы предотвратить использование метода клиентами или не дать вредоносному коду использовать точку входа в данный компонент. Другой распространенной причиной ограничения метода, который не предназначен для открытого использования (но должен быть объявлен как открытый), является устранение документирования и поддержки того, что является сугубо внутренним интерфейсом.
Управляемый код позволяет ограничить доступ к методу различными способами.
Ограничьте области действия до класса, сборки, производных классов, если они являются доверенными. Это самый простой пусть ограничения доступа к методу. Следует заметить, что обычно производные классы являются в меньшей степени доверенными, чем класс, от которого они наследуются, хотя в некоторых случаях они имеют свидетельство родительского класса. В частности, не делайте вывод о доверенности на основании зарезервированного слова protected, которое не обязательно используется в контексте обеспечения безопасности.
Ограничьте доступ к методу вызывающими объектами с определенными свидетельствами, в сущности, с любым конкретным свидетельством (строгое имя, издатель, зона и т. д.).
Ограничьте доступ к методу только теми вызывающими объектами, у которых есть выбранные вами разрешения.
Подобным образом декларативная безопасность позволяет контролировать наследование классов. Можно использовать InheritanceDemand в следующих целях.
Для требования того, чтобы производный класс имел особое удостоверение или разрешение.
Для требования того, чтобы производный класс, который переопределяет некоторые методы, имел заданное удостоверение или разрешение.
В следующем примере показано, как ограничить доступ к открытому классу с помощью требования, чтобы все вызывающие объекты были подписаны конкретным строгим именем. Данный пример использует StrongNameIdentityPermissionAttribute, где в качестве требования Demand выступает строгое имя. Сведения о подписании сборки строгим именем см. в разделе Создание и использование сборок со строгими именами.
<StrongNameIdentityPermissionAttribute(SecurityAction.Demand, PublicKey := "…hex…", Name := "App1", Version := "0.0.0.0")> _
Public Class Class1
End Class
[StrongNameIdentityPermissionAttribute(SecurityAction.Demand, PublicKey="…hex…", Name="App1", Version="0.0.0.0")]
public class Class1
{
}