Seguridad en comunicación remota
Este tema es específico de una tecnología heredada que se mantiene para la compatibilidad con versiones anteriores con aplicaciones existentes y no se recomienda para nuevo desarrollo. Las aplicaciones distribuidas se deberían desarrollar utilizando Windows Communication Foundation (WCF).
Al igual que un programador de aplicaciones de .NET Remoting, usted debe tener un buen conocimiento no solo de las implicaciones de seguridad de .NET Remoting, sino también de las aplicaciones distribuidas en general. Sin una implementación segura, cualquiera podría llamar a un método en su objeto remoto o interceptar información confidencial que se envía al objeto remoto o desde él. Para evitar que esto suceda, usted debe autenticar los clientes (y los posibles servidores) y cifrar la comunicación entre los dos.
También existen problemas menos sencillos. Considere un objeto remoto que define un método que toma un delegado como un parámetro. Un programador malintencionado podría utilizar al delegado para obligar a la aplicación del servidor a ejecutar cualquier código él o ella desea. Cuando un delegado ajusta un método estático, cualquier llamada en ese delegado no se transmitirá de forma remota, se llama al código del dominio de aplicación que invocó el delegado. Por ejemplo, un cliente pícaro puede utilizar esta vulnerabilidad para realizar una llamada al objeto remoto y pasar a un delegado que ajusta un método estático. El ensamblado que implementa el método estático se puede copiar en el servidor y al invocar al delegado se ejecutaría el método estático en el servidor. Para evitar que esto ocurra, usted debería declarar siempre delegados que se utilicen en objetos remotos con tipos y parámetros personalizados que no pueden ser supuestos por piratas informáticos. Además, no debería permitir a un cliente definir y pasar un tipo a su objeto remoto que se va a deserializar.
En esta sección se describen varios enfoques relativos a la seguridad basados en ciertas decisiones de diseño. Aquí no se resuelven todos los escenarios, pero estos temas son un buen punto inicial.
Seguridad de acceso del código
La seguridad de acceso del código es un mecanismo que ayuda a limitar el acceso que el código tiene a recursos y operaciones protegidos. Normalmente, cuando el código intenta tener acceso a un recurso protegido, se realiza un recorrido de pila para asegurarse de que todos los marcos de pila tienen permiso para acceder al recurso. Cuando se realiza una llamada en un objeto remoto, este recorrido de pila no se realiza por el límite remoto. Por consiguiente, la infraestructura remota exige permiso FullTrust para ejecutarse bien en el cliente o en el servidor. Los permisos FullTrust desactivan esencialmente la seguridad de acceso del código. Cualquier uso no autorizado de una aplicación remota proporciona acceso no autorizado a los permisosFullTrust.
.gif "9hwst9th.note(es-es,VS.100).gif") Nota: |
|---|
| Varios tipos de sistema extienden MarshalByRefObject pero también realizan comprobaciones de seguridad durante el tiempo de ejecución para evitar que cualquier elemento de fuera del dominio de aplicación invoque remotamente a un objeto de ese tipo. AppDomain y System.Windows.Forms.Form son dos ejemplos de tales tipos de sistema. |
Consideraciones de seguridad en aplicaciones remotas
En general, existen dos áreas de seguridad que se deben direccionar en una aplicación distribuida: proteger el canal de comunicación y proteger a la aplicación contra el uso indebido.
Proteger el canal de comunicación implica asegurarse de que se cifran los mensajes y de que éstos no se modifican en tránsito. E proteger una aplicación contra el uso impropio implica autenticar y autorizar a llamadores. Autenticar a un llamador significa comprobar que el llamador es quién dice ser. Autorizar a un llamador significa comprobar que el llamador tiene los privilegios exigidos para realizar cierta llamada o tener acceso a un recurso protegido.
Los canales integrados admiten la seguridad como sigue:
HttpChannel - Solo admite autenticación cuando Internet Information Services (IIS) hospeda a los objetos remotos. Solo se admite el cifrado cuando IIS se configura para utilizar SSL.
TcpChannel - Admite autenticación y cifrado.
IpcChannel - Admite autenticación.
| Nota: |
|---|
| La autorización es algo que se proporciona en su código. Los canales integrados no le pueden proporcionar esto porque no conocen qué hace su código ni cuales son las restricciones le usted le ha impuesto. |
.gif "9hwst9th.Caution(es-es,VS.100).gif") Precaución: |
|---|
| La comunicación remota de .NET Framework no lleva a cabo la autenticación o el cifrado de forma predeterminada. Por consiguiente, se recomienda que dé todos los pasos necesarios para asegurarse de la identidad de los clientes o de los servidores antes de interactuar de forma remota con ellos. Dado que las aplicaciones remotas de .NET Framework exigen permisos FullTrust para ejecutarse, si a un cliente no autorizado se le permitiera el acceso a su servidor, el cliente podría ejecutar el código como si fuese un cliente de plena confianza. Autentique siempre a los clientes y cifre las secuencias de comunicación. |
Vea también
Referencia
RemotingConfiguration
ChannelServices
Context
MethodCall
RemotingServices
Conceptos
Autenticación con el canal HTTP