Código no administrado

El código de algunas bibliotecas necesita llamar a código no administrado (por ejemplo, las API de código nativo, como Win32). Como esto significa que el código no administrado sale del perímetro de seguridad, se requiere mucha precaución. Si es un código neutral respecto a la seguridad, su código y cualquier otro código que llame debe tener el permiso de código no administrado (SecurityPermission con el indicador UnmanagedCode especificado).

Sin embargo, con frecuencia es excesivo que el llamador tenga unos permisos tan eficaces. En estos casos, el código de plena confianza puede ser el intermediario de forma similar al código de contenedor o biblioteca administrado que se describe en Proteger código de contenedor. Si la funcionalidad de código subyacente no administrado es totalmente segura, se puede exponer directamente; en caso contrario, primero se requiere la correspondiente comprobación (petición) del permiso.

Cuando el código llama a código no administrado, pero no se desea exigir a los llamadores un permiso de acceso a código no administrado, se debe declarar este derecho. Una aserción bloquea el recorrido de la pila en el marco. Conviene tener cuidado de no crear una carencia de seguridad en este proceso. Normalmente, esto significa que es necesario exigir el permiso adecuado a los llamadores y, entonces, utilizar el código no administrado para realizar sólo lo que permite el permiso y nada más. En algunos casos (por ejemplo, una función que obtiene la hora del día), el código no administrado se puede exponer directamente a los llamadores sin ninguna comprobación de seguridad. En cualquier caso, todo código que se declara debe asumir la responsabilidad de la seguridad.

Como cualquier código administrado que proporciona una ruta de acceso a código nativo es un posible objetivo para un código malicioso, se debe tener un cuidado extremo al determinar qué código no administrado se puede utilizar de forma segura y cómo se debe utilizar. Por lo general, el código no administrado no debe exponerse nunca directamente a llamadores de confianza parcial. Hay que considerar dos factores principales al evaluar si es seguro utilizar código no administrado en bibliotecas a las puede llamar código de confianza parcial:

  • Funcionalidad. ¿Ofrece una API no administrada una funcionalidad que no permite a los llamadores realizar operaciones que pueden ser peligrosas? La seguridad de acceso a código utiliza los permisos para forzar el acceso a los recursos, por tanto, tenga en cuenta si la API utiliza archivos, una interfaz de usuario o subprocesos, o si expone información protegida. Si es así, el código administrado que la contenga debe exigir los permisos necesarios antes de permitir su entrada. Además, aunque no se proteja mediante un permiso, el acceso a la memoria debe estar limitado a una seguridad estricta de tipos.

  • Comprobación de parámetros. Un ataque habitual es pasar parámetros no esperados a métodos de la API de código no administrado en un intento de provocar que funcionen de forma distinta a la especificada. Las sobrecargas del búfer al utilizar un índice que está fuera del intervalo o valores de desplazamiento son un ejemplo frecuente de este tipo de ataque, como lo es cualquier parámetro que pueda aprovechar un error en el código subyacente. Así pues, aunque la API de código no administrado sea segura desde el punto de vista del funcionamiento (después de las peticiones necesarias) para los llamadores de confianza parcial, el código administrado debe comprobar también la total validez de los parámetros para garantizar que las llamadas no previstas de código malicioso son posibles mediante el nivel de contenedor de código administrado.

Vea también

Otros recursos

Instrucciones de codificación segura