Compartir a través de

Directrices de codificación segura

La mayoría del código de aplicación simplemente puede usar la infraestructura implementada por .NET. En algunos casos, se requiere una seguridad adicional específica de la aplicación, creada mediante la extensión del sistema de seguridad o mediante nuevos métodos ad hoc.

Con los permisos aplicados por .NET y otra aplicación de su código, debe establecer barreras para evitar que código malintencionado acceda a información que no quiera que tenga o que realice otras acciones no deseadas. Además, debe lograr un equilibrio entre la seguridad y la facilidad de uso en todos los escenarios esperados mediante código de confianza.

En esta introducción se describen las distintas formas en que el código se puede diseñar para trabajar con el sistema de seguridad.

Protección del acceso a recursos

Al diseñar y escribir el código, debe proteger y limitar el acceso que el código tiene a los recursos, especialmente cuando se usa o invoca código de origen desconocido. Por lo tanto, tenga en cuenta las siguientes técnicas para asegurarse de que el código es seguro:

  • No use seguridad de acceso de código (CAS).

  • No use código de confianza parcial.

  • No use el atributo AllowPartiallyTrustedCaller (APTCA).

  • No utilice .NET Remoting.

  • No use el modelo de objetos de componente distribuido (DCOM).

  • No use formateadores binarios.

La Seguridad de Acceso al Código y el código Security-Transparent no están soportados como límites de seguridad cuando se utiliza código de confianza parcial. Se recomienda cargar y ejecutar código de orígenes desconocidos sin poner en marcha medidas de seguridad alternativas. Las medidas de seguridad alternativas son:

  • Virtualización

  • Contenedores de Aplicaciones

  • Usuarios y permisos del sistema operativo (SO)

  • Contenedores de Hyper-V

Código neutro de seguridad

El código neutral respecto a la seguridad no hace nada explícito con el sistema de seguridad. Funciona con los permisos que obtiene. Aunque las aplicaciones que no detectan excepciones de seguridad asociadas a operaciones protegidas (como el uso de archivos, redes, etc.) pueden dar lugar a una excepción no controlada, el código independiente de seguridad sigue aprovechando las tecnologías de seguridad de .NET.

Una biblioteca neutra de seguridad tiene características especiales que debe comprender. Supongamos que la biblioteca proporciona elementos de API que usan archivos o llaman a código no administrado. Si el código no tiene el permiso correspondiente, no se ejecutará como se describe. Sin embargo, aunque el código tenga el permiso , cualquier código de aplicación que lo llame debe tener el mismo permiso para poder funcionar. Si el código de llamada no dispone del permiso adecuado, aparecerá un SecurityException como resultado del recorrido de la pila de seguridad de acceso al código.

Código de aplicación que no es un componente reutilizable

Si el código forma parte de una aplicación a la que no llamarán otros códigos, la seguridad es sencilla y no se necesita una codificación especial. Sin embargo, recuerde que el código malintencionado puede llamar a su código. Aunque la seguridad de acceso al código podría impedir que el código malintencionado acceda a los recursos, este código todavía podría leer valores de los campos o propiedades que podrían contener información confidencial.

Además, si el código acepta la entrada del usuario de Internet u otros orígenes no confiables, debe tener cuidado con la entrada malintencionada.

Implementación de contenedor administrado en código nativo

Normalmente en este escenario, algunas funciones útiles se implementan en código nativo que desea poner a disposición del código administrado. Los contenedores administrados son sencillos de escribir mediante la invocación de plataforma o interoperabilidad COM. Sin embargo, si lo hace, los llamadores de los contenedores deben tener derechos de código no administrado para ser correctos. Según la directiva predeterminada, esto significa que el código descargado de una intranet o de Internet no funcionará con los envoltorios.

En lugar de conceder derechos de código no administrados a todas las aplicaciones que usan estos contenedores, es mejor conceder estos derechos solo al código contenedor. Si la funcionalidad subyacente no expone ningún recurso y la implementación es igualmente segura, el contenedor solo necesita asegurar sus derechos, lo que permite que cualquier código pueda realizar llamadas a través de él. Cuando los recursos intervienen, la codificación de seguridad debe ser la misma que el caso de código de biblioteca descrito en la sección siguiente. Dado que el contenedor puede exponer a los llamadores a esos recursos, se necesita una cuidadosa comprobación de la seguridad del código nativo, lo que es responsabilidad del contenedor.

Código de biblioteca que expone recursos protegidos

El siguiente enfoque es el más eficaz y, por lo tanto, potencialmente peligroso (si se hace incorrectamente) para la codificación de seguridad: la biblioteca actúa como una interfaz para que otro código acceda a determinados recursos que no están disponibles de otro modo, al igual que las clases de .NET exigen permisos para los recursos que usan. Siempre que exponga un recurso, el código primero debe exigir el permiso adecuado para el recurso (es decir, debe realizar una comprobación de seguridad) y, a continuación, normalmente aserer sus derechos para realizar la operación real.

Consulte también