Proteger acceso a métodos
Actualización: noviembre 2007
Puede ocurrir que algunos métodos no sean apropiados para permitir que un código arbitrario que no es de confianza efectúe una llamada. Estos métodos plantean muchos riesgos ya que pueden proporcionar algún tipo de información confidencial, admitir cualquier información que se les pase, no comprobar los errores en parámetros; o con los parámetros erróneos, pueden no funcionar correctamente o generar errores. Tenga en cuenta estos casos y adopte medidas para ayudar a proteger el método.
En algunos casos, puede ser necesario restringir métodos que no están destinados a un uso público aunque tienen que ser públicos. Por ejemplo, suponga que tiene una interfaz a la que es necesario llamar entre las DLL y, por tanto, debe ser pública, pero no desea exponerla públicamente para evitar que los clientes la utilicen o que un código malicioso utilice el punto de entrada del componente. Otro motivo habitual para restringir un método que no está diseñado para uso público (pero que debe ser público) es evitar tener que documentar y admitir lo que puede ser una interfaz muy interna.
El código administrado ofrece diversas maneras de restringir el acceso a un método:
Limitar el ámbito de accesibilidad a la clase, ensamblado o clases derivadas, si son de confianza. Esta es la forma más sencilla de limitar el acceso a un método. Tenga en cuenta que, en general, las clases derivadas pueden ser de menos confianza que la clase de la que se derivan, aunque en algunos casos compartan la identidad de la clase principal. En particular, tenga en cuenta que la palabra clave protected no siempre significa confianza, ya que no se utiliza necesariamente en el contexto de seguridad.
Limitar el acceso a un método a llamadores de una identidad específica, esencialmente, cualquier prueba (nombre seguro, editor, zona, etc.) concreta que elija.
Limitar el acceso a un método a llamadores que tengan los permisos que seleccione.
De forma similar, la seguridad declarativa permite controlar la herencia de clases. Puede utilizar InheritanceDemand para hacer lo siguiente:
Requerir que las clases derivadas tengan una identidad o permiso específico.
Requerir que las clases derivadas que reemplazan métodos específicos tengan una identidad o permiso específico.
El ejemplo siguiente muestra cómo ayudar a proteger una clase pública mediante el acceso limitado al requerir que los llamadores estén firmados con un nombre seguro específico. Este ejemplo utiliza StrongNameIdentityPermissionAttribute con Demand para el nombre seguro. Para obtener información basada en tareas acerca de cómo firmar un ensamblado con un nombre seguro, vea Crear y utilizar ensamblados con nombre seguro.
<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
{
}