¿Le resultó útil esta página?
Sus comentarios sobre este contenido son muy importantes. Háganos saber su opinión.
¿Tiene comentarios adicionales?
Caracteres restantes: 1500
Exportar (0) Imprimir
Expandir todo
Este artículo proviene de un motor de traducción automática. Mueva el puntero sobre las frases del artículo para ver el texto original. Más información.
Traducción
Original

Demand frente a LinkDemand

La seguridad declarativa ofrece dos clases de comprobaciones de seguridad que son similares, aunque realicen comprobaciones muy diferentes. Es importante comprender las dos clases, puesto que una elección equivocada puede tener como resultado un debilitamiento de la seguridad o una pérdida de rendimiento. Para obtener más información, vea Peticiones de seguridad.

La seguridad declarativa ofrece las siguientes comprobaciones de seguridad:

  • Demand especifica el recorrido de pila de seguridad de acceso del código. Todos los llamadores en la pila deben tener el permiso o la identidad especificada para pasar. Demand se produce en cada llamada debido a que la pila puede contener distintos llamadores. Si se llama a un método repetidas veces, cada vez que se llama se provoca esta comprobación de seguridad. Demand es una buena protección contra los ataques trampa, ya que el código no autorizado que intente pasar será detectado.

  • LinkDemand tiene lugar durante el tiempo de la compilación Just-In-Time (JIT) y comprueba sólo el llamador inmediato. Esta comprobación de seguridad no comprueba el llamador del llamador. Una vez que se pasa esta comprobación, no hay ninguna seguridad adicional independientemente del número de veces que pueda llamar el llamador. No obstante, tampoco hay protección contra los ataques trampa. Con LinkDemand, cualquier código que pase la prueba y pueda hacer referencia al código, puede crear un punto de interrupción en la seguridad y permitir que el código malintencionado llame mediante el código autorizado. Por consiguiente, no utilice LinkDemand, salvo que se puedan evitar completamente todos los posibles puntos débiles.

    Nota Nota

    En .NET Framework 4, las peticiones de vínculo se han reemplazado por el atributo SecurityCriticalAttribute en los ensamblados Level2. SecurityCriticalAttribute equivale a una petición de vínculo de plena confianza; sin embargo, también afecta a las reglas de herencia. Para obtener más información sobre este cambio, vea Código transparente en seguridad, nivel 2.

Las precauciones adicionales que son necesarias cuando se utiliza LinkDemand se deben programar por separado; el sistema de seguridad puede ayudar exigiendo que se cumplan esas precauciones. Cualquier error abre un punto débil en la seguridad. Todo código autorizado que utilice su código debe ser responsable de implementar una seguridad adicional y, por tanto, realizar lo siguiente:

  • Restringir el acceso del código de llamada a la clase o ensamblado.

  • Establecer las mismas comprobaciones de seguridad en el código de llamada que aparece en el código al que se llama y obligar a sus llamadores a hacer lo mismo. Por ejemplo, si escribe código que llama a un método protegido con una LinkDemand para el permiso SecurityPermission con el marcador UnmanagedCode seleccionado, el método debe generar también una LinkDemand (o Demand, que es más seguro) para este permiso. La excepción es cuando el código utiliza el método protegido mediante LinkDemand de una forma limitada que decida que es segura debido a la existencia de otros mecanismos de protección de la seguridad (como peticiones) en el código. En este caso excepcional, el llamador tiene la responsabilidad de proteger los puntos débiles en la seguridad en el código subyacente.

  • Garantizar que los llamadores de código no puedan confundir al código llamando al código protegido en nombre de éste. En otras palabras, los llamadores no pueden forzar al código autorizado a pasar parámetros específicos al código protegido ni obtener resultados de este código.

Si un método, propiedad o evento virtual utilizado con LinkDemand reemplaza un método de clase base, el método de la clase base también debe tener la misma LinkDemand para que sea efectivo el método reemplazado. Un código malintencionado se puede convertir al tipo base y llamar al método de la clase base. También hay que tener en cuenta que las peticiones de vínculo se pueden agregar implícitamente a los ensamblados que no tienen el atributo del nivel de ensamblado AllowPartiallyTrustedCallersAttribute.

Es conveniente proteger las implementaciones de método con peticiones de vínculo cuando los métodos de la interfaz también tienen peticiones de vínculo. Conviene señalar lo siguiente acerca de la utilización de peticiones de vínculo con interfaces:

  • El atributo AllowPartiallyTrustedCallersAttribute también se aplica a interfaces.

  • Las peticiones de vínculo se pueden colocar en interfaces para proteger selectivamente interfaces específicas de forma que no se utilicen con código de confianza parcial, como con el atributo AllowPartiallyTrustedCallersAttribute.

  • Si define una interfaz en un ensamblado que no contiene el atributo AllowPartiallyTrustedCallersAttribute, puede implementar esta interfaz en una clase de confianza parcial.

  • Si coloca una LinkDemand en un método público de una clase que implementa un método de interfaz, LinkDemand no se fuerza si, a continuación, se convierte a la interfaz y se llama al método. En este caso, como se ha vinculado con la interfaz, sólo se admite LinkDemand en la interfaz.

Revise los problemas de seguridad de los elementos siguientes:

  • Peticiones de vínculo explícitas en métodos de interfaz. Compruebe que estas peticiones de vínculo ofrecen la protección esperada. Determine si un código malintencionado puede utilizar una conversión para evitar las peticiones de vínculo de la forma descrita anteriormente.

  • Se aplican métodos virtuales con peticiones de vínculo.

  • Los tipos y las interfaces que implementan. Éstos deben utilizar las peticiones de vínculo de forma coherente.

Adiciones de comunidad

Mostrar:
© 2015 Microsoft