Planeamiento del paso 4: planear la seguridad de la aplicación
de Keith Newman y Robert McMurray
En esta fase de la creación de su sitio web, tenga en cuenta las necesidades de seguridad de la aplicación de ASP.NET. En las siguientes secciones se describe la configuración de la seguridad de las aplicaciones disponible en IIS 8:
4.1. Aislar las aplicaciones web
Una de las maneras más eficaces para mejorar la seguridad de una aplicación web es aislarla de otras aplicaciones en el servidor web. Un grupo de aplicaciones tiene su propio proceso de trabajo, que procesa las solicitudes y ejecuta el código de aplicación. El proceso de trabajo tiene un identificador de seguridad (SID). Además, cada grupo de aplicaciones tiene una identidad única del grupo de aplicaciones. De forma predeterminada, cuando se crea una aplicación web, también se crea un nuevo grupo de aplicaciones con el mismo nombre que la aplicación. Si mantiene las aplicaciones web en grupos de aplicaciones independientes, puede aislarlas entre sí.
El aislamiento de aplicaciones web implica lo siguiente:
- Aislamiento del sitio: separe las aplicaciones diferentes en distintos sitios con grupos de aplicaciones diferentes.
- Privilegio mínimo: ejecute el proceso de trabajo como una identidad con privilegios bajos (identidad del grupo de aplicaciones virtuales) que sea única para cada sitio.
- Aislamiento temporal: configure una carpeta temporal ASP.NET independiente para cada sitio y únicamente conceda acceso a la identidad de proceso adecuada.
- Aislamiento de contenido: asegúrese de establecer una ACL (lista de control de acceso) en cada raíz del sitio para permitir el acceso solo a la identidad de proceso adecuada.
Sugerencia
es una buena idea hospedar el contenido de la aplicación web y el sitio web en una unidad distinta de la unidad del sistema (C:).
4.2. Niveles de confianza de .NET
Los niveles de confianza de las aplicaciones determina los permisos que concede la directiva de seguridad de acceso del código (CAS) de ASP.NET. La seguridad de acceso del código define dos categorías de confianza: plena confianza y confianza parcial. Las aplicaciones que tienen permisos de plena confianza puede acceder a todo tipo de recursos que pueda haber en servidor, así como a realizar operaciones con privilegios. A las aplicaciones de la categoría plena confianza solo les afecta configuración de seguridad del sistema operativo.
Las aplicaciones web de la categoría confianza parcial no tienen plena confianza y disponen de un conjunto limitado de permisos de acceso al código. En consecuencia, las aplicaciones de la categoría confianza parcial están limitadas a la hora de acceder a los recursos protegidos y realizar otras operaciones con privilegios. Ciertos permisos se deniegan a las aplicaciones de confianza parcial, por lo que no se puede acceder directamente a recursos que requieran esos permisos. Otros permisos se conceden de forma restringida, por lo que los recursos que los requieran podrían estar accesibles, pero de forma limitada. Por ejemplo, con un permiso restringido de E/S de archivos, la aplicación puede acceder al sistema de archivos, pero solo en los directorios que estén debajo del directorio raíz de la aplicación.
Al configurar una aplicación web o un servicio web para incluirlos en la categoría de confianza parcial, puede restringir la capacidad de la aplicación para acceder a recursos fundamentales del sistema o a recursos que pertenezcan a otras aplicaciones web. Si concede solo los permisos que necesita la aplicación (no más) puede crear aplicaciones web con privilegios mínimos y limitar los posibles daños que podría sufrir la aplicación web en caso de ataque mediante la inserción de código.
La siguiente lista muestra las restricciones asociadas a cada nivel de confianza:
- Las aplicaciones de la categoría de plena confianza tienen acceso sin restricciones a todos los tipos de recursos y pueden realizar operaciones con privilegios.
- Las aplicaciones de confianza alta, media, baja o mínima no pueden llamar al código no administrado ni a los componentes con servicio, y tampoco pueden escribir en el registro de eventos, acceder a las colas de Microsoft Message Queuing ni acceder a los orígenes de datos de OLE DB.
- Las aplicaciones de confianza alta tienen acceso sin restricciones al sistema de archivos.
- Las aplicaciones de confianza media tienen acceso restringido al sistema de archivos y solo pueden acceder a los archivos que tengan la misma jerarquía en el directorio de aplicaciones.
- Las aplicaciones de confianza baja o mínima no pueden acceder a las bases de datos de SQL Server.
- Las aplicaciones de confianza mínima no tienen acceso a los recursos.
4.3. Autenticación de .NET
La autenticación le ayuda a confirmar la identidad de los clientes que solicitan acceso a sus sitios y aplicaciones. Cuando se habilita la autenticación, IIS 8 utiliza las credenciales de la cuenta proporcionadas por el usuario para determinar qué permisos se han concedido al usuario y los recursos a los que este puede acceder.
En esta sección se describen los modos de autenticación específicos de las aplicaciones de ASP.NET.
Autenticación mediante formularios de ASP.NET
La autenticación de formularios usa el redireccionamiento del lado cliente para enviar a usuarios no autenticados a un formulario HTML en el que pueden especificar sus credenciales, que suelen ser un nombre de usuario y una contraseña. Después de validar las credenciales, se redirige a los usuarios a la página que solicitaron inicialmente. La autenticación mediante formularios a menudo emplea cookies para la transmisión de credenciales de usuario entre el servidor y el explorador web del cliente.
En las siguientes secciones se describe todo lo que hay que saber para planear la incorporación de la autenticación mediante formularios a cualquier sitio web:
Conceptos básicos de la autenticación mediante formularios
La autenticación basada en formularios de ASP.NET funciona bien para sitios o aplicaciones en servidores web públicos que reciben muchas solicitudes. Este modo de autenticación permite administrar el registro y la autenticación de cliente en el nivel de aplicación, en lugar de confiar en los mecanismos de autenticación del sistema operativo.
Importante
Dado que la autenticación mediante formularios envía el nombre de usuario y la contraseña al servidor web en forma de texto sin formato, use el cifrado del protocolo Capa de sockets seguros (SSL) tanto para la página de inicio de sesión como para las restantes páginas de la aplicación, salvo la página principal. Para obtener más información acerca de SSL, consulte 4.5. Comunicación TLS/SSL.
La autenticación mediante formularios permite a los usuarios iniciar sesión con las identidades de una base de datos de miembros de ASP.NET. Este método de autenticación usa el redireccionamiento a una página de inicio de sesión HTML para confirmar la identidad del usuario. La autenticación mediante formularios se puede configurar en los niveles de sitio o de aplicación.
La autenticación mediante formularios es cómoda por los siguientes motivos:
- Permite usar un almacén de datos personalizado, como una base de datos de SQL Server o Active Directory para la autenticación.
- Se integra fácilmente con una interfaz de usuario web.
- Los clientes pueden usar cualquier explorador web.
Si desea usar los roles de pertenencia para la autorización, utilice la autenticación mediante formularios o un método de autenticación personalizado similar.
Importante
Si selecciona la autenticación mediante formularios, no podrá usar dos métodos de autenticación basados en desafíos al mismo tiempo.
De forma predeterminada, la dirección URL de inicio de sesión para la autenticación mediante formularios es Login.aspx. Puede crear una página de inicio de sesión única para los clientes que visitan un sitio o aplicación. Por ejemplo, puede que quiera recopilar información específica de los visitantes u ofrecer una suscripción a determinadas páginas del sitio o determinadas aplicaciones.
El valor de tiempo de espera predeterminado para la autenticación mediante formularios es de 30 minutos. Considere la posibilidad de cambiar el valor de tiempo de espera a un período más corto para reducir la duración de la sesión y el riesgo de ataques de reproducción de cookies.
Cookies de autenticación
Las cookies de autenticación se utilizan como un token para comprobar que los clientes tienen acceso a todas las páginas de una aplicación, o a algunas de ellas. Por el contrario, las cookies de personalización contienen una configuración específica del usuario, que determina la experiencia de este en un sitio o aplicación concretos.
Importante: dado que las cookies de autenticación se transfieren entre el cliente y el servidor con cada solicitud, debe protegerlas siempre mediante el protocolo Capa de sockets seguros (SSL). Para obtener más información acerca de SSL, consulte 4.5. Comunicación TLS/SSL.
Las cookies son una forma de realizar un seguimiento de las personas que visitan un sitio que es más eficaz que las cadenas de consulta, ya que no requieren redireccionamiento. Sin embargo, dependen del explorador, y algunos exploradores no admiten su uso. Además, el uso de la autenticación basada en cookies no siempre es eficaz porque algunos usuarios deshabilitan la compatibilidad con las cookies en los exploradores.
De forma predeterminada, el nombre de la cookie para las aplicaciones de ASP.NET es ASPXAUTH. En su lugar, puede usar un nombre de cookie único y una ruta de acceso para cada aplicación. Al hacerlo, puede evitar que los usuarios que tengan autenticación para una aplicación la tengan para otras de un servidor web.
Puede elegir uno de los siguientes modos de cookie para su sitio o aplicación:
| Mode | Descripción |
|---|---|
| Usar cookies | Las cookies siempre se utilizan independientemente del dispositivo. |
| No usar cookies | No se utilizan cookies. |
| Detección automática | Las cookies se usansi el perfil del dispositivo las admite. Si no, no se usan cookies. En los exploradores de escritorio de los que se sabe que admiten cookies, ASP.NET comprueba si las cookies están habilitadas. Esta es la configuración predeterminada. |
| Usar el perfil del dispositivo | Las cookies se usan si el perfil del dispositivo las admite. Si no, no se usan cookies. ASP.NET no comprueba si las cookies están habilitadas en los dispositivos que admiten cookies. Este es el valor predeterminado de esta configuración es IIS 8. |
El modo de protección de cookies define la función que realiza una cookie de autenticación mediante formularios para una aplicación concreta. En la siguiente tabla se muestran los modos de protección de cookies que se pueden definir:
| Mode | Descripción |
|---|---|
| Cifrado y validación | Especifica que la aplicación utiliza tanto la validación como el cifrado de datos para ayudarle proteger la cookie. Esta opción utiliza el algoritmo de validación de datos configurado (basado en la clave de la máquina). Si está disponible el algoritmo Triple DES (3DES) y si la clave es suficientemente larga (48 bytes o más), se usa 3DES para el cifrado. Este es el valor predeterminado (y recomendado). |
| None | Especifica que tanto el cifrado como la validación están deshabilitados para los sitios que utilizan cookies únicamente para personalización y que tienen requisitos de seguridad más débiles. No se recomienda utilizar las cookies de esta manera. Sin embargo, este es el modo que menos recursos utiliza para habilitar la personalización mediante el uso de .NET Framework. |
| Cifrado | Especifica que las cookies se cifran mediante Triple DES o DES, pero la validación de datos no se realiza en la cookie. Las cookies usadas de esta manera pueden sufrir ataques de texto no cifrado. |
| Validation | Especifica que un esquema de validación comprueba que el contenido de una cookie cifrada no se ha cambiado durante el tránsito. |
Importante
Por motivos de seguridad, se recomiendan que las cookies de cifrado y de validación estén separadas unas de otras. El robo de cookies de cifrado supondría un mayor riesgo para la seguridad que el robo de cookies de validación.
Si una aplicación contiene objetos que los clientes solicitan con frecuencia, puede mejorar su rendimiento almacenando dichos objetos en la caché. Si el usuario accede al objeto almacenado en caché antes de que se agote el tiempo de espera de la cookie de autenticación, IIS 8 permite que siga en la caché y se restablece el temporizador. Sin embargo, si el usuario no accede al objeto almacenado en la caché durante ese tiempo, IIS 8 lo quita de la memoria caché.
Considere la posibilidad de habilitar esta configuración en las siguientes circunstancias:
- Tiene una cantidad limitada de memoria disponible para el almacenamiento en caché.
- Tiene muchos objetos que almacenar en la caché, ya que esta configuración solo permite que estén en la caché los objetos más solicitados.
Nota:
Especifique el tiempo de espera, en minutos, de una cookie de autenticación con Tiempo de espera de cookie de autenticación (en minutos).
Autenticación de suplantación de ASP.NET
Utilice la suplantación de ASP.NET cuando desee ejecutar la aplicación de ASP.NET en un contexto de seguridad diferente del contexto de seguridad predeterminado para las aplicaciones de ASP.NET.
Si habilita la suplantación en una aplicación de ASP.NET, esa aplicación puede ejecutarse en uno de los dos contextos diferentes: como usuario autenticado por IIS 8 o como una cuenta arbitraria que se configura. Por ejemplo, si utiliza la autenticación anónima y decide ejecutar la aplicación de ASP.NET como usuario autenticado, la aplicación se ejecutaría en una cuenta configurada para usuarios anónimos (normalmente IUSR). Del mismo modo, si decidiera ejecutar la aplicación bajo una cuenta arbitraria, se ejecutaría en el contexto de seguridad que se configurase para esa cuenta.
De forma predeterminada, la suplantación de ASP.NET está deshabilitada. Si habilita la suplantación, la aplicación ASP.NET se ejecuta bajo el contexto de seguridad del usuario autenticado por IIS 8.
4.4. Configuración de las claves de una máquina
Las claves de máquina ayudan a proteger tanto los datos de las cookies de autenticación mediante formularios como los datos del estado de vista de nivel de página. También comprueban la identificación del estado de la sesión fuera de proceso. ASP.NET usa los siguientes tipos de claves de máquina:
- Las claves de validación calculan un código de autenticación de mensajes (MAC) para confirmar la integridad de los datos. Esta clave se anexa a la cookie de autenticación mediante formularios o al estado de vista de una página concreta.
- Las claves de descifrado se usan para cifrar y descifrar los vales de autenticación mediante formularios y el estado de vista.
IIS 8 permite configurar las opciones de cifrado y validación y generar claves de máquina para su uso con los servicios de aplicaciones de ASP.NET, como el estado de la vista, la autenticación mediante formularios, la suscripción, los roles y la identificación anónima.
Antes de generar las claves de la máquina para la aplicación, realice las siguientes decisiones de diseño:
- Decida el método de validación que desea usar: AES, MD5, SHA1 (predeterminado), TripleDES, HMACSHA256, HMACSHA384 o HMACSHA512.
- Decida qué método de cifrado se va a usar: Automático (valor predeterminado), AES, TripleDES o DES.
- Decida si va a generar automáticamente la clave de validación en tiempo de ejecución.
- Decida si desea generar una clave de validación única para cada aplicación.
- Decida si va a generar automáticamente la clave de descifrado en tiempo de ejecución.
- Decida si desea generar una clave de cifrado única para cada aplicación.
4.5. Comunicación TLS/SSL
La Seguridad de la capa de transporte (TLS) y sus predecesoras, la Capa de sockets seguros (SSL), son los protocolos que proporcionan seguridad en las comunicaciones con su sitio web. Puede usar TLS/SSL para autenticar servidores y clientes y usarlo para cifrar mensajes entre las partes autenticadas.
En el proceso de autenticación, un cliente TLS/SSL envía un mensaje a un servidor TLS/SSL y el servidor responde con la información que necesita para autenticarse a sí mismo. El cliente y el servidor realizan un intercambio adicional de claves de sesión y el cuadro de diálogo de autenticación finaliza. Cuando se completa la autenticación, puede iniciarse una comunicación protegida mediante SSL entre el servidor y el cliente mediante el uso de las claves de cifrado simétrico que se establecen durante el proceso de autenticación.
Para configurar SSL/TSL para su sitio web, haga lo siguiente:
- Obtenga un certificado de servidor de una entidad de certificación (CA). Consulte Certificados de servidor.
- Agregue enlace SSL al sitio. Consulte Enlace SSL.
- Establezca IIS para requerir SSL en el sitio. Consulte Requerir SSL para un sitio.
- Considere la posibilidad de usar certificados de cliente en el sitio. Consulte Certificados de cliente.
Certificados de servidor
Los certificados de servidor se obtienen de una entidad de certificación (CA). La obtención de un certificado de servidor de una entidad de certificación es un paso de la configuración de los protocolos Capa de sockets seguros (SSL) o Seguridad de la capa de transporte (TLS). Los certificados de servidor se pueden obtener de una autoridad de certificado de terceros. Las autoridades de certificado de terceros podrían requerir que proporcione una prueba de identidad antes de emitir un certificado. También puede emitir sus propios certificados de servidor usando una autoridad de certificado en línea, como los Servicios de servidor de certificados de Microsoft.
Los certificados digitales son archivos electrónicos que funcionan como una contraseña en línea para comprobar la identidad de un usuario o un equipo. Se utilizan para crear el canal SSL cifrado que, a su vez, se utiliza para las comunicaciones del cliente. Un certificado es un documento digital emitido por una entidad de certificación (CA) que garantiza la identidad del titular del certificado y permite a las partes implicadas comunicarse de forma segura mediante el cifrado.
Los certificados digitales hacen lo siguiente:
- Autentican Confirman que sus titulares (personas, sitios web o incluso recursos de red, como enrutadores) son realmente quienes dicen ser.
- Protegen los datos que se intercambian en línea contra robos o alteraciones.
Los certificados digitales los emite una entidad de certificación de terceros de confianza o una infraestructura de clave pública (PKI) de Microsoft Windows mediante Servicios de certificados, aunque también puede firmarlos uno mismo. Cada tipo de certificado tiene sus ventajas y desventajas. Todos los tipos de certificado digital está protegidos contra la alteración y no se pueden falsificar.
Los certificados pueden emitirse para varios usos. Estos usos incluyen la autenticación de usuarios web, la autenticación de servidores web, el protocolo Extensiones seguras multipropósito al correo de Internet (S/MIME),el protocolo de seguridad de Internet (IPsec), el protocolo Seguridad de la capa de transporte (TLS) y la firma de código.
Un certificado contiene una clave pública y asocia esa clave pública a la identidad de una persona, equipo o servicio que posea la clave privada correspondiente. El cliente y el servidor usan claves públicas y privadas para cifrar los datos antes de transmitirlos. En el caso de los usuarios, los equipos y los servicios basados en Windows, la confianza en una entidad de certificación se establece cuando hay una copia del certificado raíz en el almacén de certificados raíz de confianza y el certificado contiene una ruta de acceso de certificación válida. Para que el certificado sea válido, no debe haberse revocado ni haber expirado el período de validez.
Enlace SSL
Puede asignar varios enlaces a un sitio cuando su contenido sirva para propósitos distintos o exija un protocolo diferente. Por ejemplo, un sitio de comercio puede tener una aplicación que requiera que los usuarios inicien sesión con una cuenta para comprar productos. La empresa hospeda el sitio a través de HTTP, pero los usuarios deben iniciar sesión en su cuenta en una página HTTPS. En este ejemplo, el sitio tiene dos enlaces: uno para la parte HTTP y otro para la parte HTTPS.
De forma predeterminada, Administrador de IIS no permite agregar enlaces para protocolos distintos de HTTP y HTTPS. Si desea agregar un enlace para un protocolo diferente, como un protocolo compatible con Windows Communication Foundation (WCF), utilice otra herramienta de administración. Sin embargo, si instala el servidor de protocolo de transferencia de archivos (FTP) de IIS, puede agregar enlaces FTP mediante el Administrador de IIS. También se pueden descargar otros módulos o funciones de terceros que extiendan la interfaz de usuario.
Requerir SSL para el sitio
El cifrado de Capa de sockets seguros (SSL) protege la información personal o confidencial enviada entre un cliente y un servidor. Cuando se habilita SSL, los clientes remotos utilizan dirección URL que comienzan por https:// para acceder a su sitio.
Primero, debe configurar un certificado de servidor y crear un enlace HTTPS que habilite cualquier configuración de SSL. Luego, debe exigir el cifrado de Capa de sockets seguros (SSL) en una o varias de las siguientes circunstancias:
- Cuando el contenido del servidor sea personal o confidencial, se debe proteger mediante un canal cifrado.
- Cuando quiera que los usuarios puedan confirmar la identidad de su servidor antes de que envíen información personal.
- Cuando quiera usar certificados de cliente para autenticar a los clientes que accedan a su servidor.
Certificados de cliente
Si desea que los clientes verifiquen su identidad antes de que accedan al contenido de su servidor web, configure los certificados de cliente. De forma predeterminada, se ignoran los certificados de cliente.
Para configurar un certificado de cliente en el sitio web, configure un certificado de servidor y cree un enlace HTTPS para habilitar cualquier configuración de la Capa de sockets seguros (SSL).
Si desea que todos los clientes verifiquen su identidad, especifique qué certificados de cliente son necesarios. Si algunos clientes pueden acceder al contenido sin verificar antes su identidad, especifique que se aceptan certificados de cliente.