Seguridad para WCF RIA Services
En este tema se proporciona orientación para garantizar el uso seguro de un servicio de dominio. Cuando se expone un servicio de dominio mediante la aplicación del atributo EnableClientAccessAttribute, el servicio de dominio está disponible para todos los usuarios en la red donde se expone. No se puede suponer que una aplicación cliente propia es la única aplicación que tendrá acceso al servicio de dominio. Esta consideración es particularmente importante en una red pública, pero también lo es en una red restringida, como en el caso de una red corporativa cuando se exponen datos confidenciales.
El cuadro de diálogo Agregar nueva clase de servicio de dominio genera código cuya misión es ayudar a empezar a trabajar con un servicio de dominio. El código generado no está necesariamente listo para la implementación. Debe revisar el código y modificarlo para que cumpla los requisitos de seguridad de la aplicación. En particular, debe tener en cuenta las operaciones que está poniendo a disposición de cualquier usuario en la red. La siguiente lista de comprobación es un punto de partida para garantizar el uso seguro de un servicio de dominio.
Lista de comprobación de seguridad
Para garantizar el uso seguro de un servicio de dominio, tenga en cuenta la orientación siguiente.
Minimice los datos y operaciones expuestos por un servicio de dominio. Esta es la primera línea de defensa contra la divulgación de información y la denegación de servicio.
Exponga solo las entidades que necesita el cliente. Este enfoque puede requerir separar la validación y lógica de servidor de la validación y lógica de cliente, si esto permite reducir el número de entidades expuestas. Por ejemplo, una aplicación de informe de gastos que no necesita la entidad Employee en el cliente no debe exponerla a través de un servicio de dominio.
Dé forma a las entidades para evitar la exposición de datos confidenciales. Puede utilizar el atributo ExcludeAttribute o el elemento Modelos de presentación para reducir los datos disponibles para un cliente. Por ejemplo, si la fecha de nacimiento y el número de la Seguridad Social no se requieren en una aplicación, exclúyalos de la forma que está visible para el cliente.
Haga que los métodos de consulta tomen los parámetros que necesita su aplicación, en lugar de confiar en las capacidades de filtrado de datos en LINQ. Por ejemplo, si se muestran los informes de gastos para un empleado determinado, debe requerir un identificador de empleado como parámetro en el método de consulta y no debe proporcionar un método que obtenga todos los informes de gastos. Este enfoque minimiza la posibilidad de recopilación de datos para todos los empleados.
Cree métodos de consulta que proporcionen solamente los datos necesitados para escenarios concretos en su aplicación. Este enfoque significa que puede proporcionar varios métodos de consulta que devuelvan partes de los datos en lugar de un método de consulta único que devuelva todos los datos. Por ejemplo, si los productos se muestran por categoría o por proveedor, puede proporcionar dos métodos que acepten información sobre categorías o proveedores, en lugar de un solo método que devuelva todos los productos.
Filtre los datos de manera que se proporcionen solo los datos requeridos normalmente para la aplicación. Por ejemplo, puede tener un método de consulta que devuelva solo los pedidos cumplimentados el último año.
Restrinja el número de resultados que se pueden devolver de una consulta para minimizar la sobrecarga accidental o deliberada del servidor. Utilice la propiedad ResultLimit en el atributo QueryAttribute para limitar los números de resultados que se pueden devolver. Por ejemplo, si se puede devolver un número elevado de productos, exija la paginación en el cliente limitando los resultados a 20. Considere también la posibilidad de usar el atributo OutputCacheAttribute para el almacenamiento en memoria caché de los resultados con el fin de reducir la carga en el nivel intermedio y la base de datos.
Minimice el número de operaciones para cada entidad expuesta. Por ejemplo, si una aplicación de pedidos solo necesita agregar o modificar pedidos, debe exponer operaciones de consulta, inserción y actualización en la entidad de pedidos, pero no operaciones de eliminación. Además, debe exponer solamente operaciones de consulta para la entidad de productos pero no operaciones de modificación de datos.
Siempre que sea posible, utilice métodos de actualización con nombres que restrinjan los miembros que se pueden actualizar.
Restrinja el acceso a datos y operaciones a usuarios autenticados y usuarios pertenecientes a roles concretos.
Siempre que sea posible, evite el acceso anónimo utilizando el atributo RequiresAuthenticationAttribute. Cuando deba permitir el acceso anónimo, limítelo al conjunto más pequeño de servicios de dominio y al subconjunto más pequeño de operaciones dentro de esos servicios de dominio.
Siempre que sea posible, agregue el atributo RequiresRoleAttribute específico de la operación. Considere cada operación por separado en un servicio de dominio. Por ejemplo, puede que todos los usuarios necesiten consultar la entidad de productos, pero solo los usuarios pertenecientes al rol de administrador necesiten actualizarla.
Considere la posibilidad de utilizar la propiedad AuthorizationContext para proporcionar un modelo de autorización personalizado.
Trate como sospechosos los datos enviados por un cliente. Un cliente malintencionado (incluso uno que esté autenticado y autorizado) puede proporcionar valores manipulados en un conjunto de cambios para los valores actuales y originales. La lógica de aplicación no debe dar por supuesto que estos valores son de confianza. En su lugar, considere las amenazas potenciales de valores originales manipulados.
Utilice el protocolo HTTPS para la autenticación mediante formularios. El envío de contraseñas en texto no cifrado es una vulnerabilidad significativa, pero se puede mitigar utilizando HTTPS.
Exponga el número mínimo de extremos. De forma predeterminada, RIA Services crea un extremo binario para un servicio de dominio. Agregue extremos adicionales solo si tiene clientes que necesiten concretamente los extremos. Deshabilite los extremos que no se estén utilizando.