Seguridad de aplicaciones Web en tiempo de ejecución
Actualización: noviembre 2007
El desarrollo de una aplicación exige trabajar con un conjunto de cuestiones de seguridad. El otro conjunto de cuestiones (que suelen ser las más destacadas en cualquier comentario acerca de la seguridad Web) se refieren a la seguridad de la aplicación una vez implementada y en ejecución.
Las aplicaciones Web, por definición, permiten el acceso de usuarios a recursos centrales, el servidor Web y, a través de éste, a otros como los servidores de base de datos. Comprender e implementar las medidas de seguridad adecuadas permite:
Proteger los recursos propios contra accesos no autorizados.
Restringir los niveles de acceso por usuario o por función.
Establecer integridad de datos y confidencialidad, proporcionando un entorno relativamente seguro en el que los usuarios se encuentren cómodos al trabajar con su aplicación.
Establecer control sobre cómo la aplicación obtiene acceso a recursos restringidos.
Garantizar que el código de la aplicación se ejecuta de la forma esperada.
Este tema proporciona un comentario general sobre cómo llevar a cabo estos objetivos, e incluye vínculos con temas adicionales en los que se pueden obtener más detalles acerca de las tecnologías implicadas.
Puede ayudar a proteger su aplicación de acceso no autorizado aprovechando estos tipos de características de seguridad:
Características de seguridad que ofrece Internet Information Services (IIS) como parte de su funcionalidad general de servidor Web. Esto es, seguridad de nivel de usuario, equipo y archivo de Windows.
La seguridad que se puede incorporar a la aplicación ASP.NET para proporcionar acceso específico para la aplicación.
Proceso de seguridad en ASP.NET
IIS proporciona muchas opciones de seguridad para los sitios Web. Sin embrago, los mecanismos de seguridad de IIS son muy genéricos, ya que se utilizan los mismos mecanismos para todas las aplicaciones. Además, es posible que las opciones de seguridad de IIS, por ejemplo, la seguridad integrada de Windows, no siempre sean adecuadas para su aplicación. (Por otro lado, para las aplicaciones de intranet, tal vez prefiera utilizar la seguridad integrada de Windows que es más sencilla.)
Por lo tanto, para proporcionar acceso a partes específicas de su aplicación, puede utilizar seguridad de ASP.NET. La seguridad de ASP.NET funciona junto con la seguridad IIS pero la amplía para que pueda personalizar características, como por ejemplo, la obtención de credenciales de usuario.
IIS recibe en primer lugar solicitudes de los clientes, y efectúa las comprobaciones de seguridad establecidas para la aplicación mediante las herramientas de administración de IIS. Por ejemplo, si la aplicación se ha configurado en IIS de forma que permita el acceso anónimo, IIS no efectúa comprobación de credenciales. Una vez efectuada la comprobación inicial de autenticación, IIS envía una solicitud a ASP.NET, que puede llevar a cabo un segundo nivel de comprobación. ASP.NET permite especificar restricciones de acceso a la aplicación mediante diversos criterios: se puede restringir el acceso a páginas específicas, a usuarios específicos, etc.
Autenticación
La siguiente tabla describe los métodos de autenticación compatibles con ASP.NET. Algunos de estos métodos se superponen con la autenticación IIS. Para obtener información detallada, vea Autenticación de ASP.NET.
Tipo de autenticación |
Descripción |
|---|---|
Acceso anónimo |
Para aplicaciones en las que usuarios anónimos efectúen solicitudes (generalmente, aplicaciones Web públicas). Se superpone con IIS. |
Autenticación básica y de texto implícita |
(Opción de seguridad de IIS) En este escenario, a los usuarios sin credenciales se les solicita que proporcionen un nombre de usuario y una contraseña. |
Seguridad integrada de Windows (también denominada Seguridad NTLM) |
(Opción de seguridad de IIS) Si el usuario que hace la solicitud ya ha sido autenticado en una red basada en Windows, IIS puede pasar las credenciales del usuario cuando solicite acceso a un recurso. |
Autenticación de certificados |
(Opción de seguridad de IIS) En este escenario, el cliente tiene un certificado (una identificación digital) que ha obtenido de un recurso de terceros. La identidad asignada al certificado del cliente pasa a ASP.NET. |
Kerberos |
(Opción de seguridad de IIS) El protocolo de autenticación Kerberos define las interacciones entre un cliente y un Servicio de autenticación de red denominado Centro de distribución de claves (KDC). Windows 2000 y 2003 implementan un KDC como servicio de autenticación en cada controlador de dominio. |
Autenticación de Windows |
(Opción de seguridad de ASP.NET) Se integra con las opciones de seguridad de IIS mostradas previamente . ASP.NET adopta el símbolo de seguridad creado por IIS y hace que esté disponible como un objeto WindowsPrincipal establecido como el valor de la propiedad User del HttpContext actual. |
Autenticación mediante formularios |
(Opción de seguridad de ASP.NET) Si un usuario necesita autenticarse, ASP.NET redirige la solicitud a la página que especifique. Esta página suele contener un formulario en el que se obtiene la información del nombre de usuario. Para mayor seguridad, el formulario puede intercambiarse mediante el protocolo HTTPS. Cuando la aplicación obtiene la información del formulario, puede llevar a cabo una comprobación de las credenciales del usuario específicas de la aplicación. Una cuestión importante es que el proceso de autenticación está bajo su control (a diferencia de IIS), lo que permite especificar el aspecto del formulario y la forma de almacenar la información de usuario. Si un usuario se autentica satisfactoriamente, ASP.NET emite una cookie cifrada que contiene un símbolo que identifica al usuario para su acceso subsiguiente. |
La autenticación mediante formularios es la elección más fácil para las aplicaciones ASP.NET en Internet ya que ofrece un control considerable sobre la forma de autenticación de los usuarios y permite almacenar una autenticación en un símbolo del explorador.
Para obtener información detallada sobre la seguridad de IIS, vea los temas relativos al control de accesos en Windows Server TechCenter for IIS en el sitio Web Microsoft TechNet. Para obtener detalles acerca de la autenticación de ASP.NET, vea Autenticación de ASP.NET.
Para obtener información detallada sobre la utilización de la autenticación mediante formularios con transición de protocolos y delegación restringida en un entorno de dominios Windows Server 2003, vea Kerberos Protocol Transition and Constrained Delegation.
Autorización
Cuando se ejecuta, la aplicación Web solicita recursos del servidor Web y, con frecuencia, también de otros procesos, como una base de datos. El proceso de ASP.NET se ejecuta en un contexto de usuario que determina cómo solicitará esos recursos la aplicación. El proceso ASP.NET se ejecuta como un usuario local especial denominado ASPNET (de forma predeterminada) en Windows 2000 y Windows XP Professional Edition, o se ejecuta como la identidad de la agrupación de aplicaciones para la aplicación ASP.NET en Windows 2003 (de forma predeterminada, la cuenta local NETWORK SERVICE). Estas cuentas se ejecutan con permisos limitados. Puede especificar un contexto de usuario diferente para el proceso ASP.NET, incluida la cuenta local SYSTEM (que ejecuta la aplicación en un contexto administrador) o un usuario cuyas credenciales proporcione explícitamente, aunque no se recomienda.
En la aplicación ASP.NET se puede especificar que distintos usuarios tengan acceso autorizado a distintos recursos. Si su aplicación utiliza autenticación de Windows, se pueden utilizar permisos de Windows para determinar la autorización para obtener acceso a archivos o carpetas específicos del servidor.
Otra posibilidad es utilizar autorización basada en URL, en la que la autorización se puede conceder o denegar según distintos criterios:
Usuarios específicos, o identidades, basados en las credenciales proporcionadas por el usuario.
Roles, que son entidades definidas para permitir que varios usuarios compartan privilegios según un rol o función común.
Verbos, que son los procesos HTTP (como GET y POST) para obtener acceso a partes de la aplicación.
Por ejemplo, se puede especificar que todos los usuarios puedan obtener páginas (llevar a cabo el verbo GET) de la aplicación, pero que únicamente usuarios específicos puedan enviar páginas a la misma. De forma similar, se puede especificar que todos los usuarios puedan obtener (GET) páginas, pero que se deniegue el derecho a enviar a roles específicos.
Se puede conceder autorización de URL para la aplicación en su conjunto, o directorio por directorio. Un uso típico es permitir a los usuarios ver páginas en un directorio público, pero conservar las páginas restringidas en un directorio distinto, autorizado únicamente para usuarios o roles específicos.
.gif "Nota") Nota: |
|---|
De forma predeterminada, los archivos estáticos, como imágenes y hojas de estilos, no están sujetos a la autorización de ASP.NET cuando se proporcionan a través de IIS. Las características de seguridad de IIS se pueden utilizar para restringir el acceso a archivos estáticos si no desea que todos los usuarios tengan acceso a los archivos. Si utiliza el servidor de desarrollo de ASP.NET para probar la aplicación ASP.NET, notará un comportamiento diferente debido a que los archivos estáticos están sujetos a la autorización de ASP.NET y no se proporcionarán a un usuario anónimo cuando el acceso anónimo a esos archivos esté deshabilitado. También puede asignar extensiones estáticas de nombre de archivo en IIS a la extensión ISAPI de ASP.NET, en cuyo caso se aplicarán las reglas de autorización de ASP.NET. |
Para obtener más información, vea Autorización de ASP.NET y Procedimientos de seguridad básicos para aplicaciones Web.
Archivos de configuración de ASP.NET
Las opciones de seguridad de ASP.NET se establecen con los valores de un archivo Web.config. El archivo permite incluir elementos predefinidos para diversas opciones de seguridad, incluidas secciones para autenticación y autorización. Las secciones importantes del archivo Web.config pueden tener el siguiente aspecto.
<configuration>
<system.web>
<authentication mode="Forms">
<forms loginUrl="login.aspx" />
</authentication>
<authorization>
<deny user="?" />
</authorization>
</system.web>
</configuration>
La aplicación puede contener más de un archivo de configuración. De forma predeterminada, existe un archivo de configuración en la raíz de la aplicación que especifica la seguridad para la aplicación en su conjunto; es decir, las subcarpetas heredan los parámetros de seguridad. Sin embargo, se pueden también crear archivos de configuración en carpetas individuales para crear los parámetros de seguridad de cada carpeta.
Para obtener más información, vea Arquitectura de ASP.NET.
Seguridad del servicio Web XML
Los servicios Web XML que utilicen archivos .asmx se ejecutan como aplicaciones Web que utilizan ASP.NET y por lo tanto participan en el mismo modelo de seguridad que cualquier aplicación ASP.NET. Por ejemplo, un servicio Web XML puede configurarse para utilizar autenticación básica o seguridad integrada en Windows.
En tiempo de diseño, al intentar agregar una referencia a un servicio Web XML (es decir, al solicitar los documentos de detección del servicio Web XML), dicho servicio efectuará una autenticación estándar de aplicación Web, según su configuración. Por ejemplo, si el servicio Web XML está configurado para utilizar autenticación básica, esperará obtener un nombre de usuario y una contraseña del cliente que efectúa la solicitud. Si el servicio Web XML utiliza autenticación básica, por ejemplo, el cuadro de diálogo Agregar referencia Web solicitará credenciales.
Si construye una aplicación que incluya llamadas a un servicio Web XML, deberá asegurarse de que dispone de las credenciales apropiadas antes de efectuar la llamada, o ésta fallará. En tiempo de ejecución, se pueden pasar credenciales al servicio Web XML estableciendo la propiedad Credentials del objeto de cliente que representa el servicio Web XML antes de llamar a sus métodos.
Puesto que otras opciones de seguridad de ASP.NET pueden no tener la suficiente flexibilidad, los servicios Web XML pueden implementar una solución de autenticación personalizada en la que la información de credenciales se pasa en encabezados SOAP. En esta solución, las credenciales se pasan como parte opcional del mensaje intercambiado entre cliente y servidor. Entonces se puede escribir un módulo HTTP personalizado (mediante la implementación de la interfaz IHttpModule) que puede escuchar la información del encabezado y llamar al código de autenticación.
Como sucede con otras aplicaciones ASP.NET, el servicio Web XML puede implementar autorizaciones específicas basadas en un rol para limitar el acceso a partes específicas de la aplicación.
Para obtener más detalles, vea Infraestructura de servicios Web XML y Proteger servicios Web XML creados mediante ASP.NET.
Establecer la integridad y confidencialidad de los datos
La autenticación y autorización establecen quiénes son los usuarios y a qué recursos pueden tener acceso. Estas características de seguridad se han diseñado principalmente para ayudarle a proteger la aplicación Web de un uso no autorizado.
Sin embargo, existe otro aspecto distinto de la seguridad, que consiste en ayudar a proteger la información de los usuarios y darles confianza para intercambiar información confidencial con el usuario. Por ejemplo, si la aplicación pregunta a los usuarios números de tarjetas de crédito u otro tipo de números de cuenta, información personal o cualquier dato que los usuarios no deseen que se conozca, se deberá ofrecer un procedimiento para enviar dicha información de forma segura.
Secure Sockets Layer (SSL) puede utilizarse en IIS para intercambiar información cifrada mediante el protocolo HTTPS. SSL proporciona cifrado en ambas direcciones: la información se transmite al usuario mediante cifrado y la información que envía el usuario a la aplicación está asimismo cifrada.
Establecer SSL y cifrado
Para utilizar SSL y cifrado, se debe obtener un certificado de servidor para la compañía o identidad. El certificado es una firma digital que identifica al sitio de forma que no pueda suplantarse. Para las aplicaciones de Internet (públicas), el certificado de servidor se obtiene de una autoridad de certificación externa reconocida. Para aplicaciones privadas (intranet), uno mismo puede emitir un certificado de servidor. El propósito de esto podría ser ayudar a proteger una aplicación interna, como un sitio personal.
Su certificado de servidor también le permite configurar conexiones cifradas SSL con los usuarios del explorador. SSL utiliza un método de cifrado llamado cifrado de clave pública. En este método de cifrado existen dos claves: una clave pública que se utiliza para cifrar los datos, y una clave privada que se mantiene en secreto y que se utiliza para cifrar la información cifrada con la calve pública. El certificado de servidor obtenido contiene una clave pública. Cuando los usuarios desean utilizar SSL, la aplicación envía al explorador el certificado y la clave pública. El explorador y el servidor utilizan a continuación la clave pública para establecer una forma de cifrado de la información intercambiada.
| Nota: |
|---|
El uso de SSL requiere que el explorador admita una clave de cifrado de al menos 40 bits de longitud. Este nivel está disponible en la mayoría de los exploradores. Sin embargo esta longitud de clave no se considera segura. Opcionalmente, puede configurar la aplicación en IIS para permitir solamente las conexiones SSL con una clave de 128 bits. |
Una vez obtenido un certificado de servidor, se puede instruir a los usuarios para que utilicen SSL, indicándoles que utilicen el prefijo https:// para obtener y enviar páginas Web. El sitio Web también puede configurarse en IIS para que solo acepte conexiones HTTPS. IIS y el explorador utilizarán automáticamente un canal cifrado para el intercambio de información.
Para obtener información detallada sobre cómo utilizar SSL, vea el artículo Q307267, "How to: Secure XML Web Services with Secure Sockets Layer in Windows 2000" en Microsoft Knowledge Base. Para obtener más información sobre cifrado, vea Información general sobre criptografía. Para obtener más información sobre los certificados y la configuración de SSL, vea Windows Server TechCenter for IIS en el sitio Web Microsoft TechNet.
Usar seguridad de código .NET
Un último aspecto con relación a la seguridad sería asegurarse de que el código de su aplicación está protegido contra un uso incorrecto, ya sea por ejecutarlo de forma inadvertida en un contexto incorrecto o por utilizarlo de forma malintencionada. Al formar parte ASP.NET de .NET Framework, también puede beneficiarse de la seguridad de acceso a código para establecer permisos sobre lo que se permite hacer al código. Para obtener información, vea Seguridad de acceso a código.