Capítulo 8 Seguridad de

Crear aplicaciones ASP.
NET seguras
Autenticacin, autorizacin y comunicacin segura
Captulo 8: Seguridad de ASP.NET

J.D. Meier, Alex Mackman, Michael Dunner y Srinath Vasireddy Microsoft Corporation Octubre de 2002 Consulte la Pgina de entrada como punto de partida y para obtener una descripcin completa del documento Crear aplicaciones ASP.NET seguras.
Resumen
Este captulo se presenta a modo de gua e incluye recomendaciones que le ayudarn a crear aplicaciones Web ASP.NET seguras. Muchos de los consejos y las recomendaciones de este captulo tambin pueden resultar tiles para desarrollar servicios Web ASP.NET y objetos .NET Remoting alojados en ASP.NET.
Contenido
Arquitectura de seguridad de ASP.NET Autenticacin y autorizacin Configurar la seguridad Programar la seguridad Autenticacin de Windows Autenticacin mediante Formularios Autenticacin de Passport Autenticacin personalizada Identidad del proceso para ASP.NET Suplantacin Obtener acceso a recursos de sistema Obtener acceso a recursos de red Comunicacin segura Almacenar secretos
Proteger los estados de sesin y vista Consideraciones acerca de las bateras de servidores Web Resumen
Arquitectura de seguridad de ASP.NET

ASP.NET acta en combinacin con IIS, .NET Framework y los servicios de seguridad subyacentes proporcionados por el sistema operativo para ofrecer una serie de mecanismos de autenticacin y autorizacin. Dichos mecanismos se reflejan en la ilustracin 8.1.
{Insert figure: CH08 - ASP.NET Security Services.gif} Ilustracin 8.1

Servicios de seguridad de ASP.NET
La ilustracin 8.1 muestra los mecanismos de autenticacin y autorizacin que ofrecen IIS y ASP.NET. Cuando un cliente enva una solicitud Web, se produce la siguiente secuencia de eventos de autenticacin y autorizacin: 1. Se recibe la solicitud Web HTTP(S) de la red. Puede utilizarse SSL para proteger la identidad del servidor (mediante certificados de servidor) y, a modo opcional, la identidad del cliente. Nota: SSL tambin proporciona un canal seguro para proteger los datos importantes que se transfieren del cliente al servidor (y viceversa). 2. IIS autentica al llamador mediante la autenticacin bsica, implcita, integrada (NTLM o Kerberos) o mediante certificados. Si el sitio, parcial o totalmente, no requiere acceso autenticado, IIS puede configurarse para la autenticacin annima. IIS crea un testigo de acceso a Windows para cada uno de los
usuarios autenticados. Si selecciona la autenticacin annima, IIS crear un testigo de acceso para la cuenta de usuario annima de Internet (que, de manera predeterminada, es IUSR_MACHINE). 3. IIS autoriza al llamador para que obtenga acceso al recurso solicitado. Para autorizar el acceso se utilizan los permisos NTFS definidos por las listas ACL adjuntas al recurso solicitado. IIS tambin puede configurarse para que acepte solicitudes nicamente de los equipos cliente con unas direcciones IP especficas. 4. IIS transfiere el testigo de acceso a Windows del llamador autenticado a ASP.NET (que puede ser el testigo de acceso del usuario de Internet annimo si se utiliza la autenticacin annima). 5. ASP.NET autentica al llamador. Si se configura ASP.NET para la autenticacin de Windows, no se efectuar ningn otro tipo de autenticacin adicional en esta fase. ASP.NET aceptar cualquier testigo que reciba de IIS. Si se configura ASP.NET para la autenticacin mediante Formularios, las credenciales que proporcione el llamador (mediante un formulario HTML) se autenticarn con un almacn de datos que suele ser una base de datos de Microsoft SQL Server o un servicio de directorio Active Directory. Si ASP.NET se configura para la autenticacin de Passport, el usuario ser redirigido a un sitio Passport y ser el servicio de autenticacin de Passport el que se encargar de autenticar al usuario. 6. ASP.NET autoriza el acceso al recurso o la operacin solicitados. UrlAuthorizationModule (un mdulo HTTP proporcionado por el sistema) utiliza unas reglas de autorizacin configuradas en el archivo Web.config (en especial, en el elemento <authorization>) para garantizar que el llamador pueda obtener acceso al archivo o la carpeta solicitados. En el caso de la autenticacin de Windows, FileAuthorizationModule (otro mdulo HTTP) comprueba que el llamador disponga de los permisos necesarios para obtener acceso al recurso solicitado. El testigo de acceso del llamador se compara con la ACL de proteccin del recurso. Las funciones .NET tambin pueden utilizarse (mediante declaraciones o programacin) para garantizar que el llamador reciba autorizacin para obtener acceso al recurso solicitado o para llevar a cabo la operacin solicitada. 7. El cdigo de la aplicacin obtiene acceso a los recursos locales o remotos mediante una determinada identidad. De forma predeterminada, ASP.NET no lleva a cabo ninguna suplantacin, motivo por el que es la cuenta de proceso ASP.NET configurada la que proporciona dicha identidad. Otras opciones alternativas incluyen la identidad del llamador original (si se habilita la suplantacin) o una identidad de servicio configurada.
Equipos selectores
Los puntos de autorizacin (o equipos selectores) de una aplicacin Web ASP.NET los proporcionan IIS y ASP.NET.
IIS
Con la autenticacin annima desactivada, IIS slo admite solicitudes de usuarios que puede autenticar en su propio dominio o bien en un dominio de confianza. En el caso de los tipos de archivos estticos (como los archivos .jpg, .gif y .htm, archivos que no estn asignados a ninguna extensin ISAPI), IIS utiliza permisos NTFS asociados al archivo solicitado para llevar a cabo el control de acceso.
ASP.NET
Los equipos selectores de ASP.NET incluyen los mdulos UrlAuthorizationModule, FileAuthorizationModule y peticiones de permisos Principal adems de comprobaciones de funciones.
UrlAuthorizationModule
Puede configurar elementos <authorization> del archivo Web.config de la aplicacin para controlar los usuarios y grupos de usuarios que deberan tener acceso a la aplicacin. La autorizacin se basa en el objeto IPrincipal almacenado en HttpContext.User.
FileAuthorizationModule
En cuanto a los tipos de archivos que IIS asigna a la extensin ISAPI de ASP.NET (Aspnet_isapi.dll), se realizan comprobaciones de acceso automticas mediante el testigo de Windows del usuario autenticado (que puede ser IUSR_MACHINE) y con la ACL adjunta al archivo ASP.NET solicitado. Nota: no es necesaria la suplantacin para que funcione la autorizacin de archivos. La clase FileAuthorizationModule slo realiza comprobaciones de acceso para el archivo solicitado, no para los archivos a los que el cdigo obtiene acceso en la pgina solicitada, a pesar de que se trate de accesos que comprueba IIS. Por ejemplo, si solicita el archivo Default.aspx y ste contiene un control de usuario incrustado (Usercontrol.ascx), que a su vez incluye un marcador de imagen (que dirige a Image.gif), FileAuthorizationModule llevar a cabo la comprobacin de acceso para Default.aspx y Usercontrol.ascx, porque IIS asigna estos tipos de archivo a la extensin ISAPI de ASP.NET. FileAuthorizationModule no realiza ninguna comprobacin para Image.gif porque se trata de un archivo esttico que IIS controla internamente. No obstante, dado que IIS comprueba el acceso para los archivos estticos, el usuario autenticado tambin necesita permisos de lectura para el archivo y una ACL configurada correctamente. La ilustracin 8.2 refleja este escenario. Nota para administradores de sistemas: es preciso que el usuario autenticado disponga de permisos de lectura NTFS para todos los archivos que intervienen en este escenario. La nica variable hace referencia al equipo selector que se utilizar para aplicar el control de acceso. La cuenta del proceso ASP.NET slo necesita acceso de lectura para los tipos de archivo ASP.NET registrados.
{Insert figure: CH08 ASP.NET and IIS Gatekeepers.gif} Ilustracin 8.2

Interaccin entre los equipos selectores de IIS y ASP.NET
Este escenario permite impedir el acceso en la puerta de archivos. Si configura la lista ACL adjunta a Default.aspx y deniega el acceso a un determinado usuario, el cdigo de Default.aspx no podr enviar al cliente el control de usuario ni las imgenes incrustadas. Si el usuario solicita las imgenes directamente, IIS realizar las comprobaciones de acceso l mismo.
Peticiones de permisos Principal y comprobaciones de funciones explcitas

Adems de los equipos selectores configurables de IIS y ASP.NET, tambin puede utilizar las peticiones de permisos Principal (mediante declaraciones o programacin) como mecanismo adicional de control de acceso de mayor precisin. Las comprobaciones de permisos Principal (que ejecuta la clase PrincipalPermissionAttribute) permiten controlar el acceso a las clases, mtodos o bloques de cdigo individuales en funcin de la identidad y la pertenencia a grupos de los usuarios individuales, segn se hayan definido en el objeto IPrincipal adjunto al subproceso en curso. Nota: las peticiones de permisos Principal utilizadas para comprobar la pertenencia a funciones son distintas de las llamadas IPrincipal.IsInRole para la comprobacin de la pertenencia a funciones; las primeras dan lugar a una excepcin si el llamador no es miembro de la funcin especificada, mientras que las ltimas se limitan a devolver un valor booleano para confirmar la pertenencia a las funciones. Con la autenticacin de Windows, ASP.NET adjunta de forma automtica un objeto WindowsPrincipal que representa al usuario autenticado en la solicitud Web actual (mediante HttpContext.User). La autenticacin mediante Formularios y de Passport crea un objeto GenericPrincipal con la identidad adecuada, pero sin funciones, y lo adjunta a HttpContext.User.
Ms informacin
Si desea obtener ms informacin acerca de cmo configurar la seguridad, consulte "Configurar la seguridad" en este mismo captulo. Si desea obtener ms informacin acerca de cmo programar la seguridad (y los objetos IPrincipal), consulte "Programar la seguridad" en este mismo captulo.
Estrategias de autenticacin y autorizacin

ASP.NET proporciona una serie de mecanismos de autorizacin mediante declaraciones y programacin que pueden utilizarse junto con una gran variedad de esquemas de autenticacin. De este modo puede desarrollar una estrategia de autorizacin exhaustiva y otra que pueda configurarse para ofrecer diferentes grados de granularidad: por ejemplo, por usuario o por grupo (basado en funciones). Esta seccin describe las opciones de autorizacin (tanto configurables como programticas) disponibles para una serie de opciones de autenticacin que se utilizan habitualmente. A continuacin se resumen las opciones de autenticacin: Autenticacin de Windows con suplantacin Autenticacin de Windows sin suplantacin Autenticacin de Windows con identidad fija Autenticacin mediante Formularios Autenticacin de Passport
Opciones de autorizacin disponibles

La siguiente tabla refleja el conjunto de opciones de autorizacin disponibles. Se indica para cada opcin si son necesarias la autenticacin de Windows o la suplantacin. En caso de no ser necesaria la autenticacin de Windows, se indica la opcin de autorizacin especfica disponible para el resto de los tipos de autenticacin. Esta tabla le permitir ajustar el funcionamiento de su estrategia de autenticacin/autorizacin. Tabla 8.1: autenticacin de Windows y requisitos de suplantacin Opcin de autorizacin
FileAuthorizationModule UrlAuthorizationModule Peticiones de permisos Principal Funciones .NET Funciones de Servicios Empresariales Permisos NTFS (para tipos de archivos estticos solicitados directamente; no asignados a extensiones ISAPI)
Requiere autenticacin de Windows

S No No No S N/D: estos archivos no los controla ASP.NET. Si se utiliza cualquier mecanismo de autenticacin IIS (distinto del annimo), los permisos deberan configurarse para usuarios autenticados individualmente.
Requiere suplantacin
No No No No S (en la aplicacin Web ASP.NET) No (IIS realiza la comprobacin de acceso.)
Si se utiliza la autenticacin annima, deberan configurarse los permisos de IUSR_MACHINE. Permisos NTFS (para archivos a los que obtiene acceso el cdigo de la aplicacin Web) No No Si se ejecuta la suplantacin, configure las listas ACL segn la identidad de Windows suplantada, que puede ser el llamador original o la identidad especificada en el elemento <identity> de Web.config*.
* La identidad suplantada puede corresponder al llamador original o la identidad especificada en el elemento <identity> de Web.config. Observe los dos siguientes elementos <identity>.
<identity impersonate="true" /> <identity impersonate="true" userName="Bob" password="pwd" />
La primera configuracin se traduce en la suplantacin del llamador original (segn lo haya autenticado IIS), mientras que la segunda da lugar a la identidad Bob. La segunda configuracin no es recomendable por dos motivos: Exige conceder a la identidad del proceso ASP.NET el privilegio Actuar como parte del sistema operativo del sistema operativo Microsoft Windows 2000. Tambin requiere incluir una contrasea de texto sin cifrar en el archivo Web.config.
Ambas restricciones se eliminarn en la siguiente versin de .NET Framework.
Autenticacin de Windows con suplantacin

Los siguientes elementos de configuracin muestran cmo habilitar la autenticacin de Windows (IIS) y la suplantacin mediante declaraciones en los archivos Web.config o Machine.config. Nota: es recomendable configurar la autenticacin en funcin de cada aplicacin en el archivo Web.config de las aplicaciones.
<authentication mode="Windows" /> <identity impersonate="true" />
Con esta configuracin, el cdigo de la aplicacin ASP.NET suplanta al llamador autenticado por IIS.
Seguridad configurable
El empleo de la autenticacin de Windows junto con la funcionalidad de suplantacin ofrece las siguientes opciones de autorizacin: Listas ACL de Windows Recursos solicitados por los clientes. FileAuthorizationModule de ASP.NET realiza comprobaciones de acceso para los tipos de archivo
solicitados que se hayan asignado a la ISAPI de ASP.NET. A fin de realizar dichas comprobaciones de acceso se utiliza el testigo de acceso del llamador original y la lista ACL adjuntos a los recursos solicitados. En el caso de los tipos de archivo estticos (no asignados a ninguna extensin ISAPI), IIS realiza comprobaciones de acceso mediante el testigo de acceso del llamador y la lista ACL adjunta al archivo. Recursos a los que obtiene acceso la aplicacin . Pueden configurarse las listas ACL de Windows de los recursos a los que obtenga acceso la aplicacin (archivos, carpetas, claves de registro, objetos de Active Directory, etc.) en funcin del llamador original.
Autorizacin mediante direcciones URL. La autorizacin mediante direcciones URL se configura en el archivo Web.config. Con la autenticacin de Windows, los nombres de usuario adoptan la forma DomainName\UserName (NombreDominio\NombreUsuario) y las funciones se asignan una a una a los grupos de Windows.
<authorization> <deny user="DomainName\UserName" /> <allow roles="DomainName\WindowsGroup" /> </authorization>
Funciones de Servicios Empresariales (COM+). Las funciones se almacenan en el catlogo COM+. Puede configurar estas funciones con ayuda de la herramienta de administracin o la secuencia de comandos de Servicios de componentes.
Seguridad mediante programacin

La seguridad mediante programacin hace referencia a las comprobaciones de seguridad ubicadas en el cdigo de la aplicacin Web. Las siguientes opciones de seguridad mediante programacin estn disponibles cuando se utiliza la autenticacin de Windows con la funcin de suplantacin. Peticiones de permisos PrincipalPermission Imperativas (en las lneas del cdigo del mtodo)
PrincipalPermission permCheck = new PrincipalPermission( null, @"DomainName\WindowsGroup"); permCheck.Demand();
Declarativas (atributos previos a las interfaces, clases y mtodos)

[PrincipalPermission(SecurityAction.Demand, Role=@"DomainName\WindowsGroup)]
Comprobaciones de funciones explcitas. Puede realizar la comprobacin de funciones mediante la interfaz IPrincipal.
IPrincipal.IsInRole(@"DomainName\WindowsGroup");
Funciones de Servicios Empresariales (COM+). Puede realizar la comprobacin de funciones mediante programacin con la clase ContextUtil.
ContextUtil.IsCallerInRole("Manager")
Escenarios de uso
Utilice la autenticacin de Windows y la suplantacin cuando se den las siguientes condiciones: Los usuarios de la aplicacin tienen cuentas de Windows que puede autenticar el servidor. Es necesario transferir el contexto de seguridad del llamador original al nivel medio o al nivel de datos de la aplicacin Web para admitir la autorizacin de granularidad fina (por usuario). Se requiere transferir el contexto de seguridad del llamador original a los niveles indirectos a fin de admitir la auditora de nivel del sistema operativo.
Antes de utilizar la suplantacin con la aplicacin, asegrese de que comprende las repercusiones de este enfoque en relacin con el empleo del modelo de subsistema de confianza. Se ha llevado a cabo un compendio de dichas repercusiones, que se presentan en la seccin "Seleccionar un modelo de acceso a los recursos" en el captulo 3, "Autenticacin y autorizacin." Entre las desventajas de la suplantacin figuran: Escalabilidad reducida de la aplicacin debido a la imposibilidad de agrupar efectivamente conexiones de bases de datos. Mayor esfuerzo de administracin porque las listas ACL de los recursos servidor deben configurarse para cada uno de los usuarios. La delegacin exige la autenticacin Kerberos y un entorno configurado correctamente.
Ms informacin
Si desea obtener ms informacin acerca de la autenticacin de Windows, consulte la seccin "Autenticacin de Windows" en este mismo captulo. Si desea obtener ms informacin acerca de la suplantacin, consulte el apartado "Suplantacin" que figura ms adelante en este captulo. Si desea obtener ms informacin acerca de la autorizacin mediante direcciones URL, consulte "Notas acerca de la autorizacin mediante direcciones URL" en este mismo captulo. Si desea obtener ms informacin acerca de las funciones de Servicios Empresariales (COM+), consulte el captulo 9, "Seguridad de la aplicacin de Servicios Empresariales". Si desea obtener ms informacin acerca de las peticiones PrincipalPermission, consulte el apartado "Identidades y principales" del captulo 2, "Modelo de seguridad para aplicaciones ASP.NET".
Autenticacin de Windows sin suplantacin

Los siguientes elementos de configuracin muestran cmo habilitar la autenticacin de Windows (IIS) sin suplantacin de forma declarativa en el archivo Web.config.
<authentication mode="Windows" />  <identity impersonate="false" />
El empleo de la autenticacin de Windows sin la suplantacin ofrece las siguientes opciones de autorizacin: Listas ACL de Windows
Recursos solicitados por los clientes. FileAuthorizationModule de ASP.NET realiza comprobaciones de acceso para los tipos de archivo solicitados que se hayan asignado a la ISAPI de ASP.NET. A fin de realizar dichas comprobaciones de acceso se utiliza el testigo de acceso del llamador original y la lista ACL adjuntos a los recursos solicitados. No se requiere la suplantacin. En el caso de los tipos de archivo estticos (no asignados a ninguna extensin ISAPI), IIS realiza comprobaciones de acceso mediante el testigo de acceso del llamador y la lista ACL adjuntos al archivo. Recursos a los que obtiene acceso la aplicacin . Puede configurar las listas ACL de Windows de los recursos a los que tenga acceso la aplicacin (archivos, carpetas, claves de registro, objetos de Active Directory, etc.) con la identidad del proceso ASP.NET.
Autorizacin mediante direcciones URL. La autorizacin mediante direcciones URL se configura en el archivo Web.config. Con la autenticacin de Windows, los nombres de usuario adoptan la forma DomainName\UserName y las funciones se asignan una a una a los grupos de Windows.
<authorization> <deny user="DomainName\UserName" /> <allow roles="DomainName\WindowsGroup" /> </authorization>

Tiene a su disposicin las siguientes opciones de seguridad mediante programacin: Peticiones de permisos Principal Imperativas
PrincipalPermission permCheck = new PrincipalPermission( null, @"DomainName\WindowsGroup"); permCheck.Demand();
Declarativas
[PrincipalPermission(SecurityAction.Demand, Role=@"DomainName\WindowsGroup")]
IPrincipal.IsInRole(@"DomainName\WindowsGroup");
Escenarios de uso
Utilice la autenticacin de Windows sin suplantacin cuando se den las siguientes condiciones: Los usuarios de la aplicacin tienen cuentas de Windows que puede autenticar el servidor. Desea utilizar una identidad fija para obtener acceso a los recursos indirectos (bases de datos por ejemplo) a fin de admitir la agrupacin de conexiones.
Ms informacin
Si desea obtener ms informacin acerca de la autenticacin de Windows, consulte la seccin "Autenticacin de Windows" en este mismo captulo. Si desea obtener ms informacin acerca de la autorizacin mediante direcciones URL, consulte Notas acerca de la autorizacin mediante direcciones URL" que encontrar ms adelante en este mismo captulo. Si desea obtener ms informacin acerca de las peticiones PrincipalPermission, consulte el apartado "Principals" de la seccin Introduccin" de esta gua.
Autenticacin de Windows con identidad fija

El elemento <identity> del archivo Web.config es compatible con los atributos opcionales de nombre de usuario y contrasea, lo cual permite configurar una identidad fija especfica para que la aplicacin la suplante. El siguiente fragmento del archivo de configuracin es una muestra de este enfoque.
<identity impersonate="true" userName="DomainName\UserName" password="ClearTextPassword" />
Escenarios de uso
Este enfoque no es recomendable para la versin actual (versin 1) de .NET Framework en entornos seguros por dos motivos: Los nombres de usuario y las contraseas no deberan almacenarse en formato de texto sin cifrar en los archivos de configuracin, en especial en los archivos de configuracin que se almacenan en los directorios virtuales. En Windows 2000, este enfoque obliga a conceder a la cuenta de proceso ASP.NET el privilegio Actuar como parte del sistema operativo. Esta concesin reduce la seguridad de la aplicacin Web y aumenta el riesgo de la amenaza en caso de que un intruso pudiera llegar a exponer el proceso de la aplicacin Web.
.NET Framework versin 1.1 incluir una mejora para este escenario en Windows 2000: Se cifrarn las credenciales. El inicio de sesin lo llevar a cabo el proceso IIS, de manera que ASP.NET no requiera el privilegio Actuar como parte del sistema operativo.
Autenticacin mediante Formularios

Los siguientes elementos de configuracin muestran cmo habilitar la autenticacin mediante Formularios mediante declaraciones en el archivo Web.config.
<authentication mode="Forms" > <forms loginUrl="logon.aspx" name="AuthCookie" timeout="60" path="/"> </forms> </authentication>
El empleo de la autenticacin mediante Formularios pone a su disposicin las siguientes opciones de autorizacin: Listas ACL de Windows
Recursos solicitados por los clientes. Los recursos solicitados exigen que las listas ACL permitan el acceso de lectura a la cuenta annima de usuario de Internet. (IIS debera configurarse para permitir el acceso annimo cuando se utiliza la autenticacin mediante Formularios.) La autorizacin de archivos de ASP.NET no est disponible porque requiere la autenticacin de Windows. Recursos a los que obtiene acceso la aplicacin . Pueden configurarse las listas ACL de Windows de los recursos a los que obtenga acceso la aplicacin (archivos, carpetas, claves de registro, objetos de Active Directory, etc.) con la identidad del proceso ASP.NET.
Autorizacin mediante direcciones URL Configure la autorizacin mediante direcciones URL en el archivo Web.config. Al utilizar la autenticacin mediante Formularios, el formato de los nombres de usuario viene determinado por el almacn de datos personalizado: una base de datos de SQL Server o Active Directory. Si utiliza un almacn de datos de SQL Server:
<authorization> <deny users="?" /> <allow users="Mary,Bob,Joe" roles="Manager,Sales" /> </authorization>
Si utiliza Active Directory como almacn de datos, los nombres de usuario y de los grupos adoptarn el formato X.500:
<authorization> <deny users="someAccount@domain.corp.yourCompany.com" /> <allow roles ="CN=Smith James,CN=FTE_northamerica,CN=Users, DC=domain,DC=corp,DC=yourCompany,DC=com" /> </authorization>

Tiene a su disposicin las siguientes opciones de seguridad mediante programacin: Peticiones de permisos Principal Imperativas
PrincipalPermission permCheck = new PrincipalPermission( null, "Manager"); permCheck.Demand();
Declarativas
[PrincipalPermission(SecurityAction.Demand, Role="Manager")]
IPrincipal.IsInRole("Manager");
Escenarios de uso
La autenticacin mediante Formularios resulta especficamente idnea para las aplicaciones de Internet. Utilice la autenticacin mediante Formularios si: Los usuarios de la aplicacin no tienen cuentas de Windows. Desea que los usuarios inicien sesin en la aplicacin escribiendo las credenciales en un formulario HTML.
Ms informacin
Si desea obtener ms informacin acerca de la autenticacin mediante Formularios, consulte la seccin "Autenticacin mediante Formularios" que figura ms adelante en este mismo captulo. Si desea obtener ms informacin acerca de la autorizacin mediante direcciones URL, consulte "Notas acerca de la autorizacin mediante direcciones URL" en este mismo captulo.
Autenticacin de Passport
Los siguientes elementos de configuracin muestran cmo habilitar la autenticacin de Passport de forma declarativa en el archivo Web.config.
<authentication mode="Passport" />
Escenarios de uso
La autenticacin de Passport se utiliza en Internet cuando los usuarios de la aplicacin no tienen cuentas de Windows y se desea implementar una solucin de inicio de sesin nico. Los usuarios que hayan iniciado una sesin previamente con una cuenta Passport en un sitio de Passport no tendrn que volver a iniciar sesin en su sitio si ste se ha configurado para la autenticacin de Passport.
Configurar la seguridad
En esta seccin se presentan los pasos que deben realizarse para configurar la seguridad de una aplicacin Web de ASP.NET. La ilustracin 8.3 resume estos pasos.
{Insert figure: CH08 Configuring ASP.NET Security.gif} Ilustracin 8.3

Configurar la seguridad de una aplicacin ASP.NET
Configurar los parmetros de IIS

Para configurar la seguridad de IIS debe seguir los siguientes pasos: 1. Si lo desea, puede instalar un certificado de servidor Web (si necesita SSL). Si desea obtener ms informacin, consulte "Cmo configurar SSL en un servidor Web" en la seccin de referencia de este manual. 2. Configure la autenticacin de IIS 3. Si lo desea, configure la asignacin de certificados de cliente (si utiliza la autenticacin mediante certificados). Si desea obtener ms informacin acerca de la asignacin de certificados de cliente, consulte el artculo Q313070, How to Configure Client Certificate Mappings in Internet Information Services (IIS) 5.0" (en ingls) que encontrar en la base de conocimiento Microsoft Knowledge Base.
4. Configure los permisos NTFS para archivos y carpetas. Entre dichos recursos, IIS y FileAuthorizationModule de ASP.NET comprueban que el usuario autenticado (o la cuenta annima de usuario de Internet) disponga de los derechos de acceso necesarios (segn la configuracin ACL) para obtener acceso al archivo solicitado.
Configurar los parmetros de ASP.NET

Los parmetros de configuracin del nivel de aplicacin se almacenan en los archivos Web.config, ubicados en el directorio raz virtual de la aplicacin y, en ocasiones, tambin en subcarpetas adicionales (esta configuracin puede suplantar algunas veces la configuracin de la carpeta principal). 1. Configurar la autenticacin. Debera configurarse en todos y cada uno de los archivos Web.config de las aplicaciones que se encuentran en el directorio raz virtual de la aplicacin (no en el archivo Machine.config).
<authentication mode="Windows|Forms|Passport|None" />
2. Configurar la suplantacin. De manera predeterminada, las aplicaciones ASP.NET no aplican la suplantacin. Las aplicaciones se ejecutan mediante la identidad del proceso configurada de ASP.NET (que suele ser ASPNET), utilizada para obtener acceso a los recursos. La suplantacin slo resulta necesaria en situaciones como las siguientes: Cuando se utiliza Servicios Empresariales y se desea utilizar funciones de Servicios Empresariales (COM+) para autorizar el acceso a las funciones que ofrecen los componentes revisados. IIS est configurado para la autenticacin annima y se desea utilizar la cuenta annima de usuario de Internet para obtener acceso a los recursos. Si desea obtener ms informacin acerca de este enfoque, consulte el apartado "Obtener acceso a recursos de red" que figura ms adelante en este captulo. Es necesario transmitir el contexto de seguridad del usuario autenticado al siguiente nivel (la base de datos, por ejemplo). Ha expuesto una aplicacin ASP clsica en ASP.NET y desea el mismo comportamiento de suplantacin. Las aplicaciones ASP clsicas suplantan al llamador de forma predeterminada.
Para configurar la suplantacin de ASP.NET, utilice el siguiente elemento <identity> del archivo Web.config de la aplicacin.
<identity impersonate="true" />
3. Configurar la autorizacin. La autorizacin mediante direcciones URL determina si un usuario o funcin pueden emitir un verbo HTTP (por ejemplo, GET, HEAD y POST) para un archivo especfico. Para implementar la autorizacin mediante direcciones URL es preciso que lleve cabo las siguientes tareas. a. Agregue un elemento <authorization> al archivo Web.config ubicado en el directorio raz virtual de la aplicacin. b. Restrinja el acceso a los usuarios y las funciones mediante los atributos allow y deny. El siguiente ejemplo del archivo Web.config utiliza la autenticacin de Windows y permite que tanto Bob como Mary obtengan acceso, pero se lo deniega al resto de los usuarios.
<authorization> <allow users="DomainName\Bob, DomainName\Mary" />
<deny users="*" /> </authorization>
Importante: es preciso agregar <deny users="?"/> o <deny users="*"/> al final del elemento <authorization>; de lo contrario, se conceder el acceso a todas las identidades autenticadas.
Notas acerca de la autorizacin mediante direcciones URL

Tenga en cuenta los siguientes aspectos cuando configure la autorizacin mediante direcciones URL: "*" hace referencia a todas las identidades. "?" hace referencia a las identidades no autenticadas (es decir, la identidad annima). No es necesario aplicar la suplantacin para que funcione la autorizacin mediante direcciones URL. La configuracin de la autorizacin en el archivo Web.config suele hacer referencia a todos los archivos del directorio actual, as como a todos los subdirectorios (excepto que un subdirectorio contenga su propio archivo Web.config con un elemento <authorization>). En este caso, la configuracin del subdirectorio sustituye la del directorio principal). Nota: la autorizacin mediante direcciones URL slo se aplica a los tipos de archivos a los que IIS asigna la extensin ISAPI de ASP.NET, aspnet_isapi.dll. Puede utilizar la etiqueta <location> para que la configuracin de la autorizacin se aplique a un archivo o directorio especficos. El siguiente ejemplo muestra cmo aplicar la autorizacin a un archivo especfico (Page.aspx).
<location path="page.aspx" /> <authorization> <allow users="DomainName\Bob, DomainName\Mary" /> <deny users="*" /> </authorization> </location>
Los usuarios y las funciones de la autorizacin mediante direcciones URL se determinan mediante la configuracin de la autenticacin: Cuando se establece el elemento en <authentication mode=Windows />, se autoriza el acceso para las cuentas de usuario y los grupos de Windows. Los nombres de usuario adoptan la forma "DomainName\WindowsUserName" (NombreDominio\NombreUsuarioWindows). Los nombres de las funciones adoptan la forma "DomainName\WindowsGroupName" (NombreDominio\NombreGrupoWindows). Nota: el grupo de administradores local se denomina "BUILTIN\Administrators". El grupo de usuarios local se denomina "BUILTIN\Users".
Cuando el elemento <authentication mode=Forms /> se establece en la autenticacin mediante Formularios, se autorizan los usuarios y las funciones para el objeto IPrincipal almacenado en el contexto HTTP actual. Por ejemplo, si utiliza formularios para autenticar usuarios con una base de datos, estar concediendo la autorizacin segn las funciones obtenidas de la base de datos. Cuando el elemento del modo de autenticacin se establece en Passport (<authentication mode=Passport />), la autorizacin se efecta con relacin al identificador del usuario de Passport (PUID) o las funciones obtenidas de un almacn. Por ejemplo, puede asignar un PUID a una cuenta y conjunto de funciones determinados almacenados en una base de datos SQL Server o en Active Directory. Nota: esta funcin se integrar en el sistema operativo Microsoft Windows Server 2003.
Cuando se establece el modo de autenticacin en ninguno (<authentication mode=None />), no se realiza ninguna autorizacin. "None" indica que no se desea realizar ninguna autenticacin o que no se desea utilizar ninguno de los mdulos de autenticacin .NET sino un mecanismo personalizado propio. No obstante, si utiliza la autenticacin personalizada, debera crear un objeto IPrincipal con funciones y almacenarlo en HttpContext.User. Cuando, posteriormente, lleve a cabo la autorizacin mediante direcciones URL, sta se ejecutar con el usuario y las funciones (independientemente de cmo se obtengan) almacenadas en el objeto IPrincipal.
Ejemplos de la autorizacin mediante direcciones URL

La siguiente lista muestra la sintaxis de algunos ejemplos habituales de la autorizacin mediante direcciones URL. Denegar el acceso a la cuenta annima.
<deny users="?" />
Denegar el acceso a todos los usuarios.

<deny users="*" />
Denegar el acceso a la funcin Manager.

<deny roles="Manager"/>
Ejemplo de la autenticacin mediante Formularios

<configuration> <system.web> <authentication mode="Forms" > <forms name=".ASPXUSERDEMO" loginUrl="login.aspx" protection="All" timeout="60" /> </authentication> <authorization> <deny users="jdoe@somewhere.com" /> <deny users="?" />
</authorization> </system.web> </configuration>
Ms informacin
El elemento <authorization> funciona con el objeto IPrincipal actual almacenado en HttpContext.User y HttpContext.Request.RequestType.
Proteger recursos
1. Utilice listas ACL de Windows para proteger recursos, incluidos archivos, carpetas y claves de registro. Si no utiliza la suplantacin, cualquier recurso al que necesite obtener acceso la aplicacin deber disponer de una lista ACL que conceda, como mnimo, el acceso de lectura a la cuenta de proceso de ASP.NET. Si utiliza la suplantacin, los archivos y las claves de registro deben contar con listas ACL que concedan, como mnimo, acceso de lectura al usuario autenticado (o a la cuenta annima de usuario de Internet, en caso de ser efectiva la autenticacin annima). 2. Proteja los archivos Web.config y Machine.config: Utilice las listas ACL correctas. Si ASP.NET utiliza la suplantacin, la identidad suplantada requerir acceso de lectura. De lo contrario, ser la identidad del proceso ASP.NET la que requerir el acceso de lectura. Especifique los siguientes niveles de permisos ACL en los archivos Web.config y Machine.config. Sistema: Control total Administradores: Control total Identidad de proceso o identidad suplantada: lectura Si no utiliza la suplantacin para la cuenta annima de usuario de Internet (IUSR_MACHINE), debera denegar el acceso a esta cuenta. Nota: si su aplicacin se asigna a un recurso compartido UNC, la identidad UNC requerir el acceso de lectura tambin para los archivos de configuracin. Elimine los mdulos HTTP no deseados. Machine.config contiene una serie de mdulos HTTP predeterminados (incluidos en el elemento <httpModules>). Estos mdulos son: WindowsAuthenticationModule FormsAuthenticationModule PassportAuthenticationModule UrlAuthorizationModule FileAuthorizationModule OutputCacheModule SessionStateModule
Si su aplicacin no utiliza ningn mdulo en especial, elimnelo para evitar en el futuro cualquier posible problema de seguridad asociado con un determinado mdulo debido a su explotacin por la aplicacin. 3. Si lo desea, bloquee la configuracin mediante el elemento < location> y el atributo allowOverride="false", tal como se describe ms abajo.
Bloquear los parmetros de configuracin

Los parmetros de configuracin son jerrquicos. La configuracin del archivo Web.config de los subdirectorios sustituye la configuracin del archivo Web.config de los directorios principales. Adems, la configuracin de Web.config tambin sustituye a la de Machine.config. Puede bloquear la configuracin para impedir que sea sustituida en niveles inferiores mediante el elemento <location> y el atributo allowOverride. Por ejemplo:
<location path="somepath" allowOverride="false" /> . . . arbitrary configuration settings . . . </location>
Tenga en cuenta que la ruta de acceso puede hacer referencia a un sitio Web o un directorio virtual y que se aplica al directorio designado y a todos los subdirectorios. Si establece el atributo allowOverride en el valor false, evitar que los archivos de configuracin de niveles inferiores reemplacen la configuracin especificada en el elemento <location>. La capacidad de bloquear la configuracin puede aplicarse a todos los tipos de configuracin, no slo a la configuracin de seguridad de los modos de autenticacin.
Impedir que se descarguen los archivos

Puede utilizar la clase HttpForbiddenHandler para evitar que se descarguen algunos tipos de archivos a travs del Web. Esta clase la utiliza internamente ASP.NET para evitar la descarga de algunos archivos de sistema (como por ejemplo los archivos de configuracin, incluido el archivo Web.config). Si desea obtener una lista completa de los tipos de archivos que presentan este tipo de restricciones, consulte la seccin <httpHandlers> del archivo Machine.config. Considere la posibilidad de utilizar HttpForbiddenHandler para los archivos que la aplicacin utiliza internamente pero que no se han concebido para la descarga. Nota: tambin debera proteger los archivos mediante listas ACL de Windows a fin de poder controlar los usuarios que obtienen acceso a los archivos cuando inician una sesin en el servidor Web. Para utilizar HttpForbiddenHandler con el fin de evitar la descarga de un determinado tipo de archivo 1. Cree una asignacin de aplicacin en IIS para el tipo de archivo en cuestin y asgnela a Aspnet_isapi.dll. a. En la barra de tareas, haga clic en el botn Inicio, seleccione Programas, Herramientas administrativas y, finalmente, seleccione Servicios de Internet Information Server. b. Seleccione el directorio virtual de la aplicacin, haga clic con el botn secundario del mouse (ratn) y haga clic en Propiedades. c. Seleccione Configuracin de la aplicacin y haga clic en Configuracin. d. Haga clic en Agregar para crear una nueva asignacin de aplicaciones. e. Haga clic en Examinar y seleccione c:\winnt\Microsoft.NET\Framework\v1.0.3705\aspnet_isapi.dll. f. Escriba la extensin de archivo correspondiente al tipo de archivo cuya descarga desee evitar (por ejemplo, .abc) en el campo Extensin.
g. Compruebe que estn seleccionadas las opciones Todos los verbos y Motor de secuencias de comandos y que la opcin Comprobar que existe el archivo est seleccionada. h. Haga clic en Aceptar para cerrar el cuadro de dilogo Agregar/Modificar asignacin de extensin de aplicacin. i. Haga clic en Aceptar para cerrar el cuadro de dilogo Configuracin de la aplicacin y, a continuacin, haga clic en Aceptar para cerrar el cuadro de dilogo Propiedades. 2. Agregue una asignacin <HttpHandler> al archivo Web.config para el tipo de archivo especificado. A continuacin encontrar un ejemplo para el tipo de archivo .abc.
<httpHandlers> <add verb="*" path="*.abc" type="System.Web.HttpForbiddenHandler"/> </httpHandlers>
Comunicacin segura
Utilice una combinacin de SSL y la Seguridad del protocolo de Internet (IPSec) para proteger la seguridad de los vnculos de comunicacin.
Ms informacin
Para obtener ms informacin acerca de cmo utilizar SSL para proteger el vnculo con el servidor de bases de datos, consulte "Cmo utilizar SSL para proporcionar comunicaciones seguras con SQL Server 2000." Para obtener informacin acerca de cmo utilizar IPSec entre dos equipos, consulte "Cmo utilizar IPSec para garantizar una comunicacin segura entre dos servidores."
Programar la seguridad
Una vez establecida la configuracin de seguridad configurable de la aplicacin Web, deber mejorar y ajustar la directiva de autorizacin de la aplicacin Web mediante programacin. Este proceso incluye atributos .NET declarativos de los ensamblados y la ejecucin de comprobaciones de autorizacin imperativas del cdigo. Esta seccin describe los pasos bsicos de programacin necesarios para llevar a cabo la autorizacin en una aplicacin Web ASP.NET.
Un modelo de autorizacin
A continuacin se describe brevemente el modelo bsico para la autorizacin de usuarios en la aplicacin Web: 1. Recuperar credenciales 2. Validar credenciales 3. Incluir usuarios en las funciones 4. Crear un objeto IPrincipal 5. Incluir el objeto IPrincipal en el contexto HTTP actual 6. Ejecutar la autorizacin en funcin de la identidad del usuario o la pertenencia a funciones
Importante: los pasos 1 a 5 los ejecuta automticamente ASP.NET si se ha configurado la autenticacin de Windows. En el caso de utilizar otros mecanismos de autenticacin (mediante Formularios, de Passport o personalizado) es preciso escribir el cdigo pertinente para llevar a cabo estos pasos, tal como se describe a continuacin.
Recuperar credenciales
Debe empezarse por recuperar un conjunto de credenciales (nombre de usuario y contrasea) del usuario. Si la aplicacin no utiliza la autenticacin de Windows, deber comprobar que se garantice correctamente la seguridad de las credenciales de texto no cifrado en la red a travs de SSL.
Validar credenciales
En caso de haber configurado la autenticacin de Windows, las credenciales se validarn automticamente mediante los servicios subyacentes. Si utiliza un mecanismo de autenticacin distinto, deber escribir el cdigo pertinente para validar las credenciales con un almacn de datos tal como una base de datos SQL Server o Active Directory. Si desea obtener ms informacin acerca de cmo almacenar de forma segura las credenciales de usuario en una base de datos SQL Server, consulte "Autenticar usuarios en una base de datos" en el captulo 12, "Seguridad del acceso a datos".
Incluir usuarios en las funciones

El almacn de datos de usuario tambin debera incluir una lista de las funciones de cada usuario. Es preciso escribir el cdigo adecuado para recuperar la lista de funciones del usuario validado.
Crear un objeto IPrincipal

La autorizacin se realiza con un usuario autenticado, cuya identidad y lista de funciones se almacena en un objeto IPrincipal (que se transmite junto con el contexto de la solicitud Web actual). En caso de haber configurado la autenticacin de Windows, ASP.NET crear automticamente un objeto WindowsPrincipal. Dicho objeto contiene la identidad del usuario autenticado adems de una lista de funciones, que equivale a la lista de grupos de Windows a los que pertenece el usuario. Si utiliza la autenticacin mediante Formularios, de Passport o un mecanismo personalizado, deber escribir el cdigo necesario en el controlador de eventos Application_AuthenticateRequest de Global.asax para crear un objeto IPrincipal. .NET Framework proporciona la clase GenericPrincipal, que debera utilizarse en la mayora de los escenarios.
Incluir el objeto IPrincipal en el contexto HTTP actual

Adjunte el objeto IPrincipal al contexto HTTP actual (mediante la variable HttpContext.User). ASP.NET lo hace automticamente cuando se utiliza la autenticacin de Windows. De lo contrario, deber adjuntar el objeto de forma manual.
Ejecutar la autorizacin en funcin de la identidad del usuario o la pertenencia a funciones

Utilice las funciones de .NET de forma declarativa (para obtener la autorizacin de clases o mtodos) o imperativa en el cdigo si la aplicacin requiere una lgica de autorizacin de mayor granularidad.
Puede utilizar las peticiones de permisos principales declarativas o imperativas (mediante la clase PrincipalPermission), o bien ejecutar las comprobaciones de funciones explcitas llamando al mtodo IPrincipal.IsInRole(). El siguiente ejemplo presupone que se utiliza la autenticacin de Windows y esboza una peticin declarativa de permisos principales. El mtodo que transfiere el atributo slo se ejecutar si el usuario autenticado es miembro del grupo Manager de Windows. Si el llamador no es miembro de este grupo, se generara una excepcin SecurityException.
[PrincipalPermission(SecurityAction.Demand, Role=@"DomainName\Manager")] public void SomeMethod() { }
El siguiente ejemplo muestra una comprobacin de funcin del cdigo explcita. El ejemplo asume que se utiliza la autenticacin de Windows. En caso de utilizarse un mecanismo de autenticacin distinto de Windows, el cdigo sigue siendo similar. En vez de convertir el objeto User a un objeto WindowsPrincipal, debera convertirse a un objeto GenericPrincipal.
// Extract the authenticated user from the current HTTP context. // The User variable is equivalent to HttpContext.Current.User if you are using // an .aspx or .asmx page WindowsPrincipal authenticatedUser = User as WindowsPrincipal; if (null != authenticatedUser) { // Note: To retrieve the authenticated user's username, use the // following line of code // string username = authenticatedUser.Identity.Name; // Perform a role check if (authenticatedUser.IsInRole(@"DomainName\Manager") ) { // User is authorized to perform manager functionality } } else { // User is not authorized to perform manager functionality }
Ms informacin
Si desea conocer un caso prctico de implementacin del modelo descrito para la autenticacin mediante Formularios, consulte la seccin "Autenticacin mediante Formularios" que figura ms adelante en este mismo captulo.
Crear una clase IPrincipal personalizada

.NET Framework proporciona la clase GenericPrincipal que debera utilizarse en la mayora de los escenarios que recurren a un mecanismo de autenticacin distinto de Windows. Esta clase permite ejecutar comprobaciones de funciones a travs del mtodo IPrincipal.IsInRole.
En algunas ocasiones quizs resulte necesario implementar una clase IPrincipal propia. Algunos de los motivos para implementar una clase IPrincipal propia: Se desean ampliar las funciones para la comprobacin de funciones. Quizs desee utilizar mtodos que permitan comprobar si un determinado usuario es miembro de varias funciones. Por ejemplo:
CustomPrincipal.IsInAllRoles( "Role", "Role2", "Role3" ) CustomPrincipal.IsInAnyRole( "Role1", "Role2", "Role3" )
Quizs desea implementar un mtodo o propiedad adicional que devuelva una lista de funciones en una matriz. Por ejemplo:
string[] roles = CustomPrincipal.Roles;
Desea que la aplicacin fuerce la lgica jerrquica de funciones. Por ejemplo, un director general se sita en un lugar de la jerarqua superior al que ocupa un director ejecutivo. Esta diferencia puede comprobarse con ayuda de mtodos como los que se indican a continuacin.
CustomPrincipal.IsInHigherRole("Manager"); CustomPrincipal.IsInLowerRole("Manager");
Desea implementar una inicializacin lenta de las listas de funciones. Por ejemplo, quizs desee cargar de forma dinmica la lista de funciones slo cuando se solicite una comprobacin de funcin. Desea implementar la interfaz IIdentity para que el usuario se identifique con un certificado X509ClientCertificate. Por ejemplo:
CustomIdentity id = CustomPrincipal.Identity; X509ClientCertificate cert = id.ClientCertificate;
Ms informacin
Para obtener ms informacin acerca de cmo crear una clase IPrincipal propia, consulte "Cmo implementar una clase IPrincipal personalizada" en la seccin de referencia de este manual.
Autenticacin de Windows
Utilice la autenticacin de Windows cuando los usuarios de la aplicacin dispongan de cuentas de Windows que pueda autenticar el servidor (por ejemplo, en escenarios de intranets). Si configura ASP.NET para la autenticacin de Windows, IIS realizar la autenticacin de los usuarios mediante el mecanismo de autenticacin configurado de IIS. La ilustracin 8.4 refleja este escenario.
{Insert figure: CH08 - IIS ASP.NET Relationship.gif} Ilustracin 8.4

La autenticacin de Windows en ASP.NET utiliza IIS para autenticar a los llamadores
El testigo de acceso del llamador autenticado (que puede ser la cuenta annima de usuario de Internet si se ha configurado IIS para la autenticacin annima) se pone a disposicin de la aplicacin ASP.NET. Tenga en cuenta las siguientes consideraciones: Este enfoque permite que FileAuthorizationModule de ASP.NET realice comprobaciones de acceso con los archivos ASP.NET solicitados mediante el testigo de acceso del llamador original. Importante: la autorizacin de archivos de ASP.NET realiza comprobaciones de acceso con los tipos de archivo que se hayan asignado a la extensin Aspnet_isapi.dll. La autorizacin de archivos no exige suplantacin. Cuando est habilitada la suplantacin, cualquier acceso que efecte la aplicacin a un recurso se llevar a cabo mediante la identidad del llamador suplantado. En estos casos, compruebe que las listas ACL adjuntas a los recursos incluyen una entrada de control de acceso (ACE) que concede, como mnimo, acceso de lectura a la identidad del llamador original.
Identificar al usuario autenticado

ASP.NET asocia el objeto WindowsPrincipal a la solicitud Web actual. Dicho objeto contiene la identidad del usuario de Windows autenticado adems de una lista de funciones de las que es miembro el usuario. En el caso de la autenticacin de Windows, la lista de funciones consta de un conjunto de grupos de Windows a los que pertenece el usuario. El siguiente fragmento de cdigo muestra cmo obtener la identidad del usuario de Windows autenticado y cmo llevar a cabo una comprobacin de funciones simple para la autorizacin.
WindowsPrincipal user = User as WindowsPrincipal;
if (null != user) { string username = user.Identity.Name; // Perform a role check if ( user.IsInRole(@"DomainName\Manager") ) { // User is authorized to perform manager functionality } } else { // Throw security exception as we don't have a WindowsPrincipal }
Autenticacin mediante Formularios

La ilustracin 8.5 muestra la secuencia de eventos que desencadena un usuario autenticado que intenta obtener acceso a un archivo o recurso seguro cuando se utiliza la autenticacin mediante Formularios (contexto en el que la autorizacin mediante direcciones URL deniega el acceso de usuario).
{Insert figure: CH08 - Forms auth sequence.gif} Ilustracin 8.5

Secuencia de eventos de la autenticacin mediante Formularios
A continuacin se describe la secuencia de eventos esbozada en la ilustracin 8.5. 1. El usuario enva una solicitud Web para Default.aspx. IIS permite la solicitud porque est activado el acceso annimo. ASP.NET comprueba los elementos <authorization> y busca un elemento <deny users=? />.
2. El usuario se redirige a la pgina de inicio de sesin (Login.aspx), tal como se especifica en el atributo LoginUrl del elemento <forms>. 3. El usuario proporciona las credenciales y enva el formulario de inicio de sesin. 4. Se validan las credenciales con un almacn (SQL Server o Active Directory) y, si se desea, se recuperan las funciones. Es preciso recuperar una lista de funciones si se desea utilizar la autorizacin basada en funciones. 5. Se crea una cookie mediante FormsAuthenticationTicket y se enva de vuelta al cliente. Si se desea, se pueden almacenar las funciones en el vale. Al almacenar la lista de funciones en el vale se evita tener que obtener acceso a la base de datos para volver a recuperar la lista con cada solicitud Web posterior del mismo usuario. 6. El usuario se redirige mediante la redireccin del cliente a la pgina solicitada originalmente (Default.aspx). 7. En el controlador de eventos Application_AuthenticateRequest (en Global.asax), el vale se utiliza para crear un objeto IPrincipal y se almacena en HttpContext.User. ASP.NET comprueba los elementos <authorization> y busca un elemento <deny users=? />. No obstante, esta vez s que se autentica el usuario. ASP.NET comprueba los elementos <authorization> para garantizar que el usuario figura en el elemento <allow>. El usuario recibe acceso a Default.aspx.
Pasos de desarrollo para la autenticacin mediante Formularios

La lista que figura a continuacin destaca los pasos bsicos que deben efectuarse para implementar la autenticacin mediante Formularios: 1. Configurar IIS para el acceso annimo 2. Configurar ASP.NET para la autenticacin mediante Formularios 3. Crear un formulario Web de inicio de sesin y validar las credenciales suministradas 4. Recuperar una lista de funciones del almacn de datos personalizado 5. Crear un vale de autenticacin mediante Formularios (almacenar funciones en el vale) 6. Crear un objeto IPrincipal 7. Incluir el objeto IPrincipal en el contexto HTTP actual 8. Autorizar a los usuarios en funcin del nombre de usuario o la pertenencia a funciones
Configurar IIS para el acceso annimo

El directorio virtual de la aplicacin debe configurarse en IIS para el acceso annimo. Para configurar IIS para el acceso annimo 1. Inicie la herramienta de administracin Servicios de Internet Information Server. 2. Seleccione el directorio virtual de la aplicacin, haga clic con el botn secundario del mouse (ratn) y haga clic en Propiedades. 3. Haga clic en Seguridad de directorios. 4. En el grupo Control de autenticacin y acceso annimo, haga clic en Modificar.
5. Seleccione Acceso annimo.
Configurar ASP.NET para la autenticacin mediante Formularios

A continuacin se incluye un fragmento de cdigo de muestra.
<authentication mode="Forms" > <forms name="MyAppFormsAuth" loginUrl="login.aspx" protection="Encryption" timeout="20" path="/" > </forms> </authentication>
Crear un formulario Web de inicio de sesin y validar las credenciales suministradas

La validacin de las credenciales debe efectuarse con una base de datos SQL Server o Active Directory.
Ms informacin
Consulte "Cmo utilizar la autenticacin mediante Formularios con SQL Server 2000" en la seccin de referencia de este manual. Consulte "Cmo utilizar la autenticacin mediante Formularios con Active Directory" en la seccin de referencia de este manual.
Recuperar una lista de funciones del almacn de datos personalizado

Las funciones deben obtenerse de una tabla de base de datos SQL Server, o bien grupos/listas de distribucin configuradas en Active Directory. Consulte los recursos anteriores para obtener informacin ms detallada.
Crear un vale de la autenticacin mediante Formularios

Las funciones recuperadas se almacenan en el vale. El siguiente fragmento de cdigo ilustra este paso.
// This event handler executes when the user clicks the Logon button // having supplied a set of credentials private void Logon_Click(object sender, System.EventArgs e) { // Validate credentials against either a SQL Server database // or Active Directory bool isAuthenticated = IsAuthenticated( txtUserName.Text, txtPassword.Text ); if (isAuthenticated == true ) { // Retrieve the set of roles for this user from the SQL Server // database or Active Directory. The roles are returned as a // string that contains pipe separated role names // for example "Manager|Employee|Sales|" // This makes it easy to store them in the authentication ticket string roles = RetrieveRoles( txtUserName.Text, txtPassword.Text );
// Create the authentication ticket and store the roles in the // custom UserData property of the authentication ticket FormsAuthenticationTicket authTicket = new FormsAuthenticationTicket( 1, txtUserName.Text, DateTime.Now, false, roles ); // Encrypt the ticket. string encryptedTicket = FormsAuthentication.Encrypt(authTicket); // Create a cookie and add the encrypted ticket to the // cookie as data. HttpCookie authCookie = new HttpCookie(FormsAuthentication.FormsCookieName, encryptedTicket); // Add the cookie to the outgoing cookies collection. Response.Cookies.Add(authCookie); // Redirect the user to the originally requested page Response.Redirect( FormsAuthentication.GetRedirectUrl( txtUserName.Text, false )); } } // version // user name // creation // Persistent // User data
DateTime.Now.AddMinutes(20),// Expiration
Crear un objeto IPrincipal

Cree el objeto IPrincipal en el controlador de eventos Application_AuthenticationRequest de Global.asax. Utilice la clase GenericPrincipal salvo si precisa una funcionalidad basada en funciones ampliada. De ser as, cree una clase personalizada que implemente IPrincipal.
Incluir el objeto IPrincipal en el contexto HTTP actual

A continuacin se incluye el cdigo que crea un objeto GenericPrincipal.
protected void Application_AuthenticateRequest(Object sender, EventArgs e) { // Extract the forms authentication cookie string cookieName = FormsAuthentication.FormsCookieName; HttpCookie authCookie = Context.Request.Cookies[cookieName]; if(null == authCookie) { // There is no authentication cookie. return; } FormsAuthenticationTicket authTicket = null; try { authTicket = FormsAuthentication.Decrypt(authCookie.Value); }
catch(Exception ex) { // Log exception details (omitted for simplicity) return; } if (null == authTicket) { // Cookie failed to decrypt. return; } // When the ticket was created, the UserData property was assigned a // pipe delimited string of role names. string[] roles = authTicket.UserData.Split(new char[]{'|'}); // Create an Identity object FormsIdentity id = new FormsIdentity( authTicket ); // This principal will flow throughout the request. GenericPrincipal principal = new GenericPrincipal(id, roles); // Attach the new principal object to the current HttpContext object Context.User = principal; }
Autorizar a los usuarios en funcin del nombre de usuario o la pertenencia a funciones

Utilice peticiones de permisos principales declarativas para restringir el acceso a los mtodos. Utilice peticiones de permisos principales imperativas y/o comprobaciones de funciones explcitas (IPrincipal.IsInRole) para llevar a cabo la autorizacin de granularidad precisa desde los mtodos.
Instrucciones para la implementacin de Formularios

Utilice SSL para la captura de credenciales mediante un formulario HTML. Adems de utilizar SSL para la pgina de inicio de sesin, tambin debera utilizar SSL para otras pginas siempre que las credenciales o la cookie de autenticacin se enven a travs de la red. De este modo se reduce la amenaza asociada a los ataques de reproduccin de la cookie. Autentique a los usuarios con un almacn de datos personalizado. Utilice SQL Server o Active Directory. Recupere una lista de funciones del almacn de datos personalizado y almacene una lista delimitada de funciones en la propiedad UserData de la clase FormsAuthenticationTicket. De este modo se mejora el rendimiento puesto que se elimina el acceso repetido al almacn de datos para cada solicitud Web y se evita tener que almacenar las credenciales del usuario en la cookie de autenticacin. Si la lista de funciones es muy amplia y existe el peligro de sobrepasar el tamao lmite de la cookie, almacene la informacin detallada de la cookie en el objeto de cach de ASP.NET o en la base de datos y recupere las funciones para cada solicitud que se efecte. Para cada solicitud y despus de realizar la autenticacin inicial: Recupere las funciones del vale del controlador de eventos Application_AuthenticateRequest.
Cree un objeto IPrincipal y almacnelo en el contexto HTTP (HttpContext.User). .NET Framework tambin asocia el objeto al proceso .NET actual (Thread.CurrentPrincipal). Utilice la clase GenericPrincipal salvo si precisa crear una implementacin IPrincipal personalizada: por ejemplo, para ofrecer compatibilidad con operaciones de funciones mejoradas.
Utilice dos cookies: una para la personalizacin y otra para la autenticacin y autorizacin seguras. Establezca el carcter persistente de la cookie de personalizacin (asegrese de que no contiene informacin que pudiese permitir a una solicitud ejecutar una operacin restringida como, por ejemplo, incluir una orden en una ubicacin segura de un sitio). Utilice un nombre de cookie (mediante el atributo Forms del elemento <forms>) y una ruta de acceso independientes para cada aplicacin Web. Este enfoque permite garantizar que los usuarios que obtienen la autenticacin de una aplicacin no reciban el trato de usuarios autenticados cuando utilizan una segunda aplicacin ubicada en el mismo servidor Web. Asegrese de que las cookies estn habilitadas en los exploradores cliente. Podr obtener informacin relativa al enfoque de autenticacin mediante Formularios que no precisa cookies en la seccin "Autenticacin mediante Formularios sin cookies" que figura ms adelante en este mismo captulo.
Ms informacin
Consulte "Cmo utilizar la autenticacin mediante Formularios con SQL Server 2000" en la seccin de referencia de este manual. Consulte "Cmo utilizar la autenticacin mediante Formularios con Active Directory" en la seccin de referencia de este manual. Consulte "Cmo utilizar la autenticacin mediante Formularios con objetos GenericPrincipal" en la seccin Referencia de esta gua.
Alojar varias aplicaciones mediante la autenticacin mediante Formularios

Si aloja varias aplicaciones Web que utilizan la autenticacin mediante Formularios en el mismo servidor Web, los usuarios autenticados por una aplicacin podrn enviar una solicitud a otra aplicacin sin ser redirigidos a la pgina de inicio de sesin de dicha aplicacin. Las reglas de la autorizacin mediante direcciones URL de la segunda aplicacin pueden denegar el acceso al usuario, sin brindarle la oportunidad de proporcionar las credenciales de inicio de sesin a travs del formulario de inicio de sesin. Estos casos slo pueden ocurrir si los atributos del nombre y la ruta de acceso del elemento <forms> son idnticos en diversas aplicaciones y si cada aplicacin utiliza un elemento <machineKey> comn en el archivo Web.config.
Ms informacin
Para obtener ms informacin acerca de este enfoque, y conocer las tcnicas de resolucin, consulte los siguientes artculos de la Knowledge Base: Q313116, "PRB: Forms Authentication Requests Are Not Directed to loginUrl Page" (en ingls). Q310415, "PRB: Mobile Forms Authentication and Different Web Applications" (en ingls).
Autenticacin mediante Formularios sin cookies

Si necesita una solucin de autenticacin mediante Formularios sin cookies, sopese la posibilidad de utilizar el enfoque empleado por el kit de herramientas para Internet
de Microsoft Mobile (Microsoft Mobile Internet Toolkit). La autenticacin mediante Formularios mvil se basa en la autenticacin mediante Formularios pero se diferencia en el hecho de que utiliza una cadena de consulta en vez de una cookie para transmitir el vale de autenticacin.
Ms informacin
Para obtener ms informacin acerca de la autenticacin mediante Formularios, consulte el artculo Q311568, "INFO: How To Use Mobile Forms Authentication with Microsoft Mobile Internet Toolkit" (en ingls) de la Microsoft Knowledge Base.
Autenticacin de Passport
Utilice la autenticacin de Passport cuando los usuarios de la aplicacin dispongan de cuentas de Passport y desee implementar una solucin de inicio de sesin nico con otros sitios habilitados para Passport. Cuando ASP.NET se configura para la autenticacin de Passport, el sistema solicita al usuario que inicie la sesin y lo redirige al sitio Passport. Despus de una validacin de credenciales satisfactoria, el usuario se redirige de nuevo al sitio.
Configurar ASP.NET para la autenticacin de Passport

Para configurar ASP.NET para la autenticacin de Passport, utilice la configuracin del archivo Web.config que se indica a continuacin.
<authentication mode="Passport"> <passport redirectUrl="internal" /> </authentication> <authorization> <deny users="?" /> <allow users="*" /> </authorization>
Asignar una identidad Passport a las funciones de Global.asax

Para asignar una identidad Passport a las funciones, implemente el controlador de eventos PassportAuthentication_OnAuthentication en el archivo Global.asax, tal como se indica a continuacin.
void PassportAuthentication_OnAuthenticate(Object sender, PassportAuthenticationEventArgs e) { if(e.Identity.Name == "0000000000000001") { string[] roles = new String[]{"Developer", "Admin", "Tester"}; Context.User = new GenericPrincipal(e.Identity, roles); } }
Probar la pertenencia a funciones

El fragmento de cdigo que figura a continuacin muestra cmo recuperar la identidad Passport autenticada y cmo comprobar la pertenencia a funciones en una pgina aspx.
PassportIdentity passportId = Context.User.Identity as PassportIdentity;
if (null == passportId) { Response.Write("Not a PassportIdentity<br>"); return; } Response.Write("IsInRole: Develeoper? " + Context.User.IsInRole("Developer"));
Autenticacin personalizada
Si ninguno de los mdulos de autenticacin suministrados por .NET Framework satisface sus necesidades especficas de autenticacin, puede utilizar la autenticacin personalizada e implementar un mecanismo de autenticacin propio. Por ejemplo, en casos en los que su empresa ya cuenta con una estrategia de autenticacin personalizada que utilizan masivamente otras aplicaciones. Para implementar una autenticacin personalizada en ASP.NET: Configure el modo de autenticacin en el archivo Web.config tal como se muestra a continuacin. Este comando notifica a ASP.NET que no invoque ninguno de los mdulos de autenticacin integrados.
<authentication mode="None" />
Cree una clase que implemente la interfaz System.Web.IHttpModule para crear un mdulo HTTP personalizado. Este mdulo debera crear un enlace en el evento HttpApplication.AuthenticateRequest y proporcionar un delegado al que llamar con cada solicitud de la aplicacin cuando se precise la autenticacin. Un mdulo de autenticacin debe: Obtener las credenciales del llamador Validar las credenciales con relacin a un almacn Cree un objeto IPrincipal y almacenarlo en HttpContext.User Crear y proteger un testigo de autenticacin y enviarlo de nuevo al usuario (normalmente mediante una cadena de consulta, una cookie o un campo de formulario oculto). Obtener el testigo de autenticacin en futuras solicitudes, validarlo y volver a enviarlo
Ms informacin
Si desea obtener ms informacin acerca de la implementacin de un mdulo HTTP personalizado, consulte el artculo Q307996, "HOW TO: Create an ASP.NET HTTP Module Using Visual C# .NET" (en ingls) de la Microsoft Knowledge Base.
Identidad del proceso para ASP.NET

Ejecute ASP.NET (en especial el proceso de trabajo Aspnet_wp.exe) mediante una cuenta con privilegios mnimos.
Utilizar una cuenta con privilegios mnimos

Utilice una cuenta con privilegios mnimos para mitigar la amenaza asociada con la exposicin de los procesos. Si un determinado intruso consigue poner en peligro el proceso de ASP.NET que ejecuta la aplicacin Web, podra heredar y explotar con
facilidad los privilegios y derechos de acceso concedidos a la cuenta de procesos. Una cuenta configurada con privilegios mnimos reduce los posibles daos.
Evitar la ejecucin como SISTEMA

No utilice la cuenta SISTEMA, que dispone de muchos privilegios, para ejecutar ASP.NET ni conceda a la cuenta de proceso de ASP.NET el privilegio Actuar como parte del sistema operativo. Es probable que caiga en la tentacin de utilizar dicha cuenta o conceder el privilegio para que el cdigo pueda llamar a la API LogonUser para obtener una identidad fija (lo que suele realizarse para el acceso a los recursos de red). Si desea conocer otros enfoques, consulte el apartado "Obtener acceso a recursos de red" que figura ms adelante en este captulo. Entre los motivos para no optar por una ejecucin con la cuenta SISTEMA ni para conceder el privilegio Actuar como parte del sistema operativo figuran: Aumenta considerablemente los daos que puede provocar un intruso cuando el sistema est en peligro, pero no afecta a la capacidad de hallarse en esta situacin. Convierte en inservible el principio de los privilegios mnimos. La cuenta ASPNET se ha configurado especficamente como una cuenta con privilegios mnimos diseada para ejecutar aplicaciones Web de ASP.NET.
Ms informacin
Para obtener ms informacin acerca del privilegio "Actuar como parte del sistema operativo", consulte la columna Security Briefs de agosto de 1999 de Microsoft Systems Journal (en ingls).
Controladores de dominio y la cuenta de proceso de ASP.NET

Por lo general, no es recomendable ejecutar el servidor Web en un controlador de dominios porque si el servidor se ve afectado, tambin se ve afectado todo el dominio. Si necesita ejecutar ASP.NET en un controlador de dominio, deber conceder a la cuenta de proceso de ASP.NET los privilegios adecuados, como se describe en el artculo Q315158, "BUG: ASP.NET Does Not Work with the Default ASPNET Account on a Domain Controller" (en ingls) de la Microsoft Knowledge Base.
Utilizar la cuenta predeterminada de ASPNET

La cuenta local de ASPNET se ha configurado especficamente para ejecutar aplicaciones Web de ASP.NET con el menor conjunto de privilegios posible. Utilice ASPNET siempre que sea posible. De manera predeterminada, las aplicaciones Web de ASP.NET ejecutan esta cuenta, tal como lo especifica el elemento <processModel> del archivo Machine.config.
<processModel userName="machine" password="AutoGenerate" />
Nota: el nombre de usuario machine se refiere a la cuenta ASPNET. La cuenta se crea con una contrasea segura criptogrficamente al instalar .NET Framework. Adems de configurarse en la base de datos SAM ( Security Account Manager), la contrasea se almacena en la autoridad local del sistema (LSA) del equipo local. El sistema recupera la contrasea de la LSA cada que vez que inicia el proceso de trabajo de ASP.NET. Si la aplicacin obtiene acceso a recursos de red, la cuenta ASPNET debe ser capaz de ser autenticada por el equipo remoto. Existen dos posibilidades:
Restablecer la contrasea de la cuenta ASPNET con un valor conocido y crear a continuacin una cuenta duplicada (con el mismo nombre y la misma contrasea) en el equipo remoto. Este enfoque es la nica opcin posible en circunstancias como las que se describen acto seguido: El servidor Web y el equipo remoto se hallan en dominios distintos y no existe ninguna relacin de confianza. El servidor Web y el equipo remoto se hallan separados por un servidor de seguridad y no se desea abrir los puertos necesarios para permitir la autenticacin de Windows.
Cuando se prima la facilidad de administracin, debe utilizarse una cuenta de dominio con privilegios mnimos. Para evitar tener que actualizar y sincronizar las contraseas manualmente, utilice una cuenta de dominio con privilegios mnimos para ejecutar ASP.NET. Resulta fundamental que la cuenta de dominio est totalmente bloqueada para mitigar la amenaza de exposicin del proceso. Si un intruso logra poner en peligro el proceso de trabajo de ASP.NET, tendr la posibilidad de obtener acceso a los recursos del dominio, salvo que la cuenta se haya bloqueado por completo.
Nota: si utiliza una cuenta local y sta queda expuesta, los nicos equipos sujetos al ataque sern aquellos en los que se hayan creado cuentas duplicadas. Si utiliza una cuenta de dominio, sta quedar visible para todos los equipos del dominio. No obstante, sigue siendo necesario que la cuenta disponga de permisos para obtener acceso a dichos equipos.
El elemento <processModel>
El elemento <processModel> del archivo Machine.config contiene los atributos de userName y password que especifican la cuenta que debera utilizarse para ejecutar el proceso de trabajo de ASP.NET (Aspnet_wp.exe). Existen una serie de opciones para configurar este parmetro. Por ejemplo: "machine". El proceso de trabajo se ejecuta como la cuenta ASPNET con privilegios mnimos. La cuenta dispone de acceso a la red pero no puede ser autenticada por ningn otro equipo de la red porque se trata de una cuenta local del equipo y no existe ninguna autoridad que pueda responder por la cuenta. En la red, esta cuenta se representa como "NombreEquipo\ASPNET". "system". El proceso de trabajo se ejecuta como la cuenta SISTEMA local. Esta cuenta dispone de numerosos privilegios en el equipo local, adems de la posibilidad de obtener acceso a la red mediante las credenciales del equipo. En la red, esta cuenta se representa como "NombreDominio\NombreEquipo$". Credenciales especficas. Cuando suministre las credenciales para userName y password, recuerde el principio de los privilegios mnimos. Si especifica una cuenta local, la aplicacin Web no podr autenticarse en la red salvo que se cree una cuenta duplicada en el equipo remoto. Si selecciona utilizar una cuenta de dominio con privilegios mnimos, asegrese de que no sea una cuenta con permisos para obtener acceso a ms equipos de la red de los necesarios. En .NET Framework versin 1.1 tendr la posibilidad de almacenar en el registro atributos userName y password cifrados.
Nota: a diferencia de cmo se ejecutan las aplicaciones ASP clsicas, el cdigo ASP.NET nunca se ejecuta en el proceso dllhost.exe o como la cuenta IWAM_MACHINENAME, incluso si el nivel de proteccin de la aplicacin se establece en Alto (Aislado) en IIS. Las solicitudes de ASP.NET que se envan a IIS se enrutan directamente al proceso de trabajo de ASP.NET (Aspnet_wp.exe). La extensin ISAPI de ASP.NET, Aspnet_isapi.dll, se ejecuta en el espacio de direcciones de proceso de IIS (Inetinfo.exe). (La entrada de la metabase InProcessIsapiApps controla este proceso, por lo que no debera modificarse). La extensin ISAPI es la responsable de enrutar las solicitudes al proceso de trabajo de ASP.NET. Las aplicaciones de ASP.NET se ejecutan entonces en el proceso de trabajo ASP.NET, en el que los dominios de la aplicacin ofrecen lmites de aislamiento. IIS 6 permitir aislar las aplicaciones de ASP.NET mediante la configuracin de grupos de aplicaciones, configuraciones en las que cada grupo tendr su propia instancia de aplicacin.
Ms informacin
Si desea obtener ms informacin acerca del acceso a los recursos de red de las aplicaciones Web de ASP.NET, consulte el apartado "Obtener acceso a recursos de red" que figura ms adelante en este captulo. Para obtener informacin detallada acerca de cmo crear una cuenta personalizada para la ejecucin de ASP.NET, consulte "Cmo crear una cuenta personalizada para ejecutar ASP.NET" en la seccin de referencia de este manual.
Suplantacin
Con la introduccin del mdulo FileAuthorizationModule, y con el empleo eficaz de los equipos selectores y los lmites de confianza, la suplantacin puede resultar una desventaja en lugar de una ventaja de ASP.NET.
Suplantacin y recursos locales

Si utiliza la suplantacin y obtiene acceso a los recursos locales desde el cdigo de la aplicacin Web, deber configurar las listas ACL adjuntas a cada recurso seguro para que contenga una ACE que conceda al usuario autenticado, como mnimo, acceso de lectura. Un enfoque todava mejor consiste en evitar la suplantacin, conceder permisos a la cuenta de proceso de ASP.NET y utilizar la autorizacin mediante direcciones URL, la autorizacin de archivos y una combinacin de comprobaciones declarativas e imperativas basadas en funciones.
Suplantacin y recursos remotos

Si se utiliza la suplantacin y se obtiene acceso a los recursos remotos desde el cdigo de la aplicacin Web, el acceso no resultar satisfactorio salvo que se utilice la autenticacin bsica, mediante Formularios o Kerberos. Si se utiliza la autenticacin Kerberos, las cuentas de usuario deben configurarse correctamente para la delegacin. Deben marcarse como Confidencial y no puede delegarse en Active Directory.
Ms informacin
Para obtener ms informacin acerca de cmo configurar la delegacin Kerberos, consulte:
"Transmitir el llamador original" en el captulo 5, "Seguridad de intranet". "Cmo implementar la delegacin Kerberos para Windows 2000" en la seccin de referencia de este manual.
Suplantacin y subprocesamiento
Si un subproceso que utiliza la suplantacin crea un nuevo subproceso, este nuevo subproceso heredar el contexto de seguridad de la cuenta de proceso de ASP.NET, no la cuenta suplantada.
Obtener acceso a recursos de sistema

De manera predeterminada, ASP.NET no lleva a cabo la suplantacin. Como consecuencia, si la aplicacin Web obtiene acceso a los recursos locales del sistema, lo har utilizando el contexto de seguridad asociado al proceso de trabajo Aspnet_wp.exe. El contexto de seguridad viene determinado por la cuenta utilizada para ejecutar el proceso de trabajo.
Obtener acceso al registro de eventos

Las cuentas con privilegios mnimos disponen de los permisos necesarios para escribir registros en el registro de eventos con ayuda de los orgenes de eventos existentes. Sin embargo, no cuentan con los permisos suficientes para crear nuevos orgenes de eventos. Para ello es necesaria una nueva entrada que debe ubicarse justo en el nivel inferior del subrbol del registro.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\<log>
Para evitar este problema, cree los orgenes de eventos que utiliza la aplicacin durante el proceso de instalacin, cuando estn disponibles los privilegios de administrador. Un buen enfoque consiste en utilizar una clase de instalador .NET de la que Windows Installer pueda crear una instancia (si se utiliza la implementacin .msi) o por la utilidad del sistema InstallUtil.exe si no se utiliza dicha implementacin. Si no puede crear orgenes de eventos durante la instalacin, deber agregar los permisos necesarios a la siguiente clave de registro y conceder acceso a la cuenta de proceso de ASP.NET (de cualquier cuenta suplantada si la aplicacin utiliza la suplantacin).
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog
Las cuentas deben tener los siguientes permisos mnimos: Consultar los valores de claves Establecer valores de claves Crear subclave Enumerar subclaves Notificar Lectura
Puede utilizar el siguiente cdigo para escribir en el registro de eventos Application de ASP.NET una vez que se hayan aplicado los permisos al registro:
string source = "Your Application Source"; string logToWriteTo = "Application"; string eventText = "Sample Event";
if (!EventLog.SourceExists(source)) { EventLog.CreateEventSource(source, logToWriteTo); } EventLog.WriteEntry(source, eventText, EventLogEntryType.Warning, 234);
Obtener acceso al registro

Cualquier clave de registro a la que obtenga acceso la aplicacin requiere una ACE (entrada de control de acceso) en la lista ACL que concede (como mnimo) acceso de lectura a la cuenta de proceso de ASP.NET.
Ms informacin
Para obtener ms informacin acerca de las clases del instalador y la utilidad InstallUtil.exey, consulte las herramientas de .NET Framework en MSDN.
Obtener acceso a los objetos COM

En ASP comn, las solicitudes se procesan mediante subprocesos del grupo de subprocesos STA (Single Threaded Apartment, subprocesamiento controlado nico). En ASP.NET, las solicitudes se procesan con subprocesos del grupo de subprocesos MTA (Multithreaded Apartment, subprocesamiento controlado mltiple). Esto puede tener implicaciones para las aplicaciones Web de ASP.NET que llaman a objetos del modelo de subprocesamiento controlado.
Objetos del modelo de subprocesamiento controlado

Cuando una aplicacin Web de ASP.NET llama un objeto de modelo de subprocesamiento controlado (como por ejemplo un objeto COM de Visual Basic 6), existen dos aspectos que deben tenerse en cuenta: Es preciso marcar la pgina de ASP.NET con la directiva AspCompat, como se muestra a continuacin.
<%@ Page Language="C#" AspCompat="True" %>
No cree los objetos COM fuera de controladores de eventos Page especficos. Crelos siempre en los controladores de eventos Page (como Page_Load y Page_Init). No cree los objetos COM en el constructor de la pgina.
Obligacin de utilizar la directiva AspCompat

De manera predeterminada, ASP.NET utiliza subprocesos MTA para procesar las solicitudes. El resultado se traduce en un cambio de subproceso cuando se llama el objeto de modelo de subprocesamiento controlado desde ASP.NET, puesto que no es posible obtener acceso a dicho objeto directamente desde los subprocesos MTA (COM utilizara un subproceso STA). La especificacin de AspCompat provoca que la pgina se procese mediante un subproceso STA. De este modo se evita que un subproceso cambie de MTA a STA. Este comportamiento resulta importante desde el punto de vista de la seguridad en casos en los que la aplicacin Web utiliza la suplantacin, puesto que un cambio de subproceso da lugar a una prdida del testigo de suplantacin. El nuevo subproceso no tendra el testigo de suplantacin asociado. La directiva AspCompat no es compatible con los servicios Web de ASP.NET. Esto significa que cuando se llaman objetos de modelo de subprocesamiento controlado
desde el cdigo de un servicio Web, se produce un cambio de subproceso y se pierde el testigo de suplantacin del subproceso. Como consecuencia suele generarse una excepcin de acceso denegado.
Ms informacin
Consulte los artculos de la Knowledge Base que se indican a continuacin para obtener ms informacin: Artculo Q303375, "INFO: XML Web Services and Apartment Objects" (en ingls) Artculo Q325791, "PRB: Access Denied Error Message Occurs When Impersonating in ASP.NET and Calling STA COM Components" (en ingls)
Si desea obtener ms informacin acerca de cmo determinar la identidad del cdigo que se est ejecutando actualmente, consulte la seccin "Quin soy?" del captulo 13, Resolucin de problemas."
No cree los objetos COM fuera de controladores de eventos Page especficos

No cree los objetos COM fuera de controladores de eventos Page especficos. El siguiente fragmento de cdigo muestra lo que no debera hacerse.
<%@ Page Language="C#" AspCompat="True" %> <script runat="server"> // COM object created outside of Page events YourComObject obj = new apartmentObject(); public void Page_Load() { obj.Foo() } </script>
Cuando se utilizan objetos del modelo de subprocesamiento controlado es importante crear el objeto en los eventos Page especficos como Page_Load, tal como se indica a continuacin.
<%@ Page Language="C#" AspCompat="True" %> <script runat="server"> public void Page_Load() { YourComObject obj = new apartmentObject(); obj.Foo() } </script>
Ms informacin
Para obtener ms informacin, consulte el artculo Q308095, "PRB: Creating STA Components in the Constructor in ASP.NET ASPCOMPAT Mode Negatively Impacts Performance" (en ingls) de la Microsoft Knowledge Base.
Objetos C# y VB .NET de COM+

La herramienta de desarrollo Microsoft C# y el sistema de desarrollo Microsoft Visual Basic .NET son compatibles con todos los modelos de subproceso (libre, neutral, ambos y subprocesamiento controlado). De manera predeterminada, cuando los objetos C# y Visual Basic .NET se alojan en COM+ se marcan como Ambos.
Como consecuencia, cuando se llaman desde ASP.NET, el acceso es directo y no se produce ningn cambio de subproceso.
Obtener acceso a recursos de red

Es posible que la aplicacin necesite obtener acceso a recursos de red. En este sentido, resulta importante identificar: Los recursos a los que necesita obtener acceso la aplicacin. Por ejemplo, archivos de recursos compartidos de archivos, bases de datos, servidores DCOM, objetos Active Directory, etc. La identidad utilizada para realizar el acceso al recurso. Si la aplicacin obtiene acceso a recursos remotos, los equipos remotos deben poder ser capaces de autenticar dicha identidad.
Nota: si desea obtener informacin especfica acerca de cmo obtener acceso a las bases de datos SQL Server, consulte el captulo 12, "Seguridad del acceso a datos."
El acceso a los recursos remotos desde una aplicacin ASP.NET puede realizarse mediante cualquiera de las tcnicas que se detalla acto seguido: Utilizar la identidad de proceso de ASP.NET Utilizar un componente revisado Utilizar una cuenta de usuario de Internet annimo (como, por ejemplo, IUSR_MACHINE) Utilizar la API LogonUser y la suplantacin para una identidad de Windows especfica Utilizar el llamador original
Utilizar la identidad del proceso ASP.NET

Cuando la aplicacin no est configurada para la suplantacin, la identidad del proceso ASP.NET proporciona la identidad predeterminada cuando la aplicacin intenta obtener acceso a los recursos remotos. Si desea utilizar la cuenta del proceso ASP.NET para el acceso a los recursos remotos, podr elegir entre tres opciones: Utilizar cuentas reflejadas Se trata del enfoque ms simple. Debe crearse una cuenta local con un nombre de usuario y contrasea coincidentes en el equipo remoto. Es necesario cambiar la contrasea de la cuenta ASP.NET del administrador de usuarios con un valor conocido (utilice siempre una contrasea segura). A continuacin, establzcala explcitamente en el elemento < processModel> del archivo Machine.config y sustituya el valor "AutoGenerate" existente. Importante: si cambia la contrasea ASPNET por un valor conocido, la contrasea de LSA dejar de coincidir con la contrasea de la cuenta SAM. Si necesita recuperar el valor predeterminado "AutoGenerate", siga uno de los siguientes pasos: Ejecute Aspnet_regiis.exe para restablecer la configuracin predeterminada de ASP.NET. Para obtener ms informacin, consulte el artculo Q306005, "HOWTO: Repair IIS Mapping After You Remove and Reinstall IIS" (en ingls) de la Microsoft Knowledge Base.
Cree una cuenta local personalizada con privilegios mnimos para ejecutar ASP.NET y cree una cuenta duplicada en el equipo remoto. Ejecute ASP.NET mediante una cuenta de dominio con privilegios mnimos. Este comportamiento asume que los equipos cliente y servidor se hallan en los mismos dominios de confianza.
Ms informacin
Para obtener ms informacin acerca de cmo configurar una cuenta de proceso ASP.NET, consulte "Cmo crear una cuenta personalizada para ejecutar ASP.NET" en la seccin de referencia de este manual.
Utilizar un componente revisado

Puede utilizar un componente revisado que no est funcionando, y que se haya configurado para ejecutarse como identidad fija, para obtener acceso a los recursos de red. Este enfoque queda reflejado en la ilustracin 8.6.
{Insert figure: Network Access with Serviced Components.gif} Ilustracin 8.6

Uso de un componente revisado que no est funcionando, y que se haya configurado para ejecutarse como identidad fija, para obtener acceso a los recursos de red.
El hecho de utilizar un componente revisado que no est en funcionamiento (en una aplicacin servidor de Servicios Empresariales) reporta los siguientes beneficios: Flexibilidad en trminos de la identidad utilizada. No se confa nicamente en la identidad ASP.NET. Posibilidad de aislar el cdigo de confianza o con mayores privilegios de la aplicacin Web principal. Un salto de proceso adicional aumenta el nivel desde el punto de vista de la seguridad. As resulta ms difcil que un intruso pueda cruzar el lmite del proceso y pasar a un proceso con privilegios aumentados. Si necesita combinar la suplantacin manual con llamadas a la API LogonUser, lo puede hacer en un proceso independiente de la aplicacin Web principal.
Nota: para llamar LogonUser es preciso que la cuenta de proceso de Servicios Empresariales tenga concedido el privilegio Actuar como parte del sistema operativo. Aumentar los privilegios de un proceso independiente de la aplicacin Web es un problema de seguridad menor.
Utilizar la cuenta annima de usuario de Internet

Puede utilizar la cuenta annima de usuario de Internet para obtener acceso a los recursos de red si IIS est configurado para la autenticacin annima. ste es el caso si se da alguna de estas dos condiciones: La aplicacin es compatible con el acceso annimo. La aplicacin utiliza la autenticacin mediante Formularios, de Passport o personalizada (cuando IIS est configurado para el acceso annimo).
Para utilizar la cuenta annima para el acceso a recursos remotos 1. Configure IIS para la autenticacin annima. Puede configurar el modo de autenticacin de ASP.NET en Windows, mediante Formularios, Passport o ninguna en funcin de los requisitos de autenticacin de la aplicacin. 2. Configure ASP.NET para la suplantacin. Utilice la siguiente configuracin del archivo Web.config:
<identity impersonate="true" />
3. Configure la cuenta annima como una cuenta de dominio con privilegios mnimos. - O bien Duplique la cuenta annima mediante el mismo nombre de usuario y contrasea del equipo remoto. Este enfoque resulta necesario cuando se realizan llamadas a travs de dominios que no son de confianza o de servidores de seguridad que no tienen abiertos los puertos necesarios para ofrecer compatibilidad con la autenticacin de Windows. Para garantizar la compatibilidad con este enfoque tambin es preciso: a. Utilizar el Administrador de servicios de Internet para desactivar la casilla de verificacin Permitir que IIS controle la contrasea para la cuenta annima. Si selecciona esta opcin, la sesin de inicio creada con la cuenta annima especificada terminar con las credenciales de red NULL (por lo que no podr utilizarse para obtener acceso a los recursos de red). Si no selecciona esta opcin, la sesin de inicio ser una sesin de inicio interactiva con las credenciales de red. b. Establecer las credenciales de la cuenta tanto en el administrador de usuarios como en el administrador de servicios de Internet. Importante: si utiliza la suplantacin para la cuenta annima (por ejemplo, IUSR_MACHINE), ser necesario proteger los recursos con esta cuenta (mediante las listas ACL configuradas correctamente). Los recursos a los que precisa obtener acceso la aplicacin deben disponer de acceso de lectura (como mnimo) a la cuenta annima. El resto de los recursos deberan denegar el acceso a la cuenta annima.
Alojar varias aplicaciones Web

Puede utilizar una cuenta annima de usuario de Internet para cada raz virtual del sitio Web. En un entorno alojado, este enfoque permite realizar por separado tareas como autorizar, realizar un seguimiento y efectuar auditoras de solicitudes que se originan en aplicaciones Web independientes. Este enfoque queda reflejado en la ilustracin 8.7.
{Insert figure: CH08 - ASPNET Impersonation - Multiple Anon Accounts.gif} Ilustracin 8.7
Suplantacin de cuentas annimas de usuario de Internet independientes para cada aplicacin (v-dir)
Para configurar la cuenta annima de usuario de Internet para un directorio virtual especfico 1. Inicie el Administrador de servicios de Internet desde el grupo de programas Herramientas administrativas. 2. Seleccione el directorio virtual que desee configurar, haga clic con el botn secundario del mouse (ratn) y haga clic en Propiedades. 3. Haga clic en la pestaa Seguridad de directorios. 4. Haga clic en la opcin Modificar del grupo Control de autenticacin y acceso annimo. 5. Seleccione Acceso annimo y, a continuacin, haga clic en Modificar. 6. Escriba el nombre de usuario y la contrasea de la cuenta que desee que utilice IIS cuando los usuarios annimos se conecten al sitio. 7. Asegrese de que la opcin Permitir que IIS controle la contrasea NO est seleccionada.
Utilizar la API LogonUser y la suplantacin para una identidad de Windows especfica

Se puede suplantar una identidad especfica mediante la configuracin de los atributos de nombre de usuario y contrasea del elemento < identity> del archivo Web.config, o bien llamando la API LogonUser de Win32 desde el cdigo de la aplicacin.
Importante: estos enfoques no son recomendables. Deberan evitarse en servidores Windows 2000, porque obligan a conceder a la cuenta del proceso ASP.NET el privilegio Actuar como parte del sistema operativo. Como consecuencia, se reduce notablemente la seguridad de la aplicacin Web. Esta restriccin dejar de existir en Windows Server 2003.
Utilizar el llamador original

Para utilizar la identidad del llamador original para el acceso a los recursos remotos es preciso delegar el contexto de seguridad del llamador desde el servidor Web al equipo remoto. Advertencia de escalabilidad: si obtiene acceso al nivel de servicios de datos de la aplicacin mediante la identidad suplantada del llamador original, se producir un efecto importante en la capacidad de escalabilidad de la aplicacin debido a que la agrupacin de conexiones de la base de datos dejar de ser efectiva. El contexto de seguridad de las conexiones de bases de datos es diferente para cada usuario. Los esquemas de autenticacin que se indican acto seguido son compatibles con la delegacin: Kerberos. Si desea obtener ms informacin, consulte "Cmo implementar la delegacin Kerberos para Windows 2000" en la seccin de referencia de este manual. Certificados de cliente asignados a cuentas de Windows . La asignacin debe llevarla a cabo IIS. Bsica. La autenticacin bsica es compatible con el acceso a los recursos remotos porque las credenciales del llamador original estn disponibles en formato de texto sin cifrar en el servidor Web. Adems, pueden utilizarse para responder a los desafos de autenticacin de los equipos remotos. Debe recurrirse a la autenticacin bsica cuando se utilice una sesin interactiva o de inicio de sesin por lotes. El tipo de sesin de inicio resultante de la autenticacin bsica puede configurarse en la metabase de IIS. Si desea obtener ms informacin, consulte el artculo Platform SDK: Internet Information Services 5.1 (en ingls) en MSDN. Importante: la autenticacin bsica constituye el enfoque menos seguro de todos los compatibles con la delegacin. El motivo es la transferencia del nombre de usuario y la contrasea en formato de texto sin cifrar del explorador al servidor a travs de la red y su almacenamiento en la cach del servidor Web. Puede utilizar SSL para proteger las credenciales durante su transferencia, pero debera evitarse en la medida de lo posible almacenar en la memoria cach del servidor Web las credenciales en formato de texto sin cifrar. Para utilizar el llamador original para el acceso a recursos remotos 1. Configure IIS para la autenticacin de Windows integrada (Kerberos), mediante certificados (con asignacin de certificados de IIS) o bsica. 2. Configure ASP.NET para la autenticacin de Windows y la suplantacin.
<authentication mode="Window" /> <identity impersonate="true" />
3. Si utiliza la delegacin Kerberos, configure las cuentas de Active Directory para la delegacin.
Ms informacin
Para obtener ms informacin acerca de la configuracin de la delegacin Kerberos, consulte "Cmo implementar la delegacin Kerberos para Windows 2000" en la seccin de referencia de este manual. Si desea obtener ms informacin acerca de la asignacin de certificados IIS, consulte http://www.microsoft.com/technet/treeview/default.asp? url=/technet/prodtechnol/ad/windows2000/howto/mapcerts.asp. (en ingls) Para obtener ms informacin acerca de la suplantacin de ASP.NET, consulte el artculo .NET Framework Developers Guide (en ingls) de MSDN.
Obtener acceso a archivos de un recurso compartido de archivos UNC

Si su aplicacin necesita obtener acceso a archivos de un recurso compartido de archivos UNC (Convencin de nomenclatura universal) mediante ASP.NET, es importante agregar permisos NTFS a la carpeta de recurso compartido. Tambin deber establecer los permisos del recurso compartido para conceder como mnimo acceso de lectura a la cuenta de proceso ASP.NET o a la identidad suplantada (si la aplicacin se ha configurado para la suplantacin).
Obtener acceso a recursos de red distintos de Windows

Si la aplicacin necesita obtener acceso a recursos que no sean de Windows, tales como bases de datos de plataformas distintas de Windows o aplicaciones de gran sistema, deber considerar los siguientes aspectos: Los equipos selectores y lmites de confianza asociados al recurso. Las credenciales necesarias para la autenticacin. Necesidad de que el recurso conozca la identidad del llamador original o si la aplicacin que efecta la llamada es de confianza (mediante un proceso o identidad de servicio fijos). Costo de rendimiento asociado a las conexiones que se establecen. Si el costo es importante quizs necesite implementar una agrupacin de conexiones; por ejemplo, mediante la funcin de agrupacin de objetos de Servicios Empresariales.
Si el recurso necesita poder autenticar el llamador original (y no existe la opcin de autenticacin de Windows), dispondr de las siguientes opciones: Pasar las credenciales mediante parmetros (llamada de mtodo). Pasar las credenciales de una cadena de conexin. Utilice SSL o IPSec para proteger las credenciales de texto sin cifrar que se transfieren a travs de la red. Almacene las credenciales de forma segura en la aplicacin, por ejemplo mediante DPAPI. Para obtener ms informacin acerca de cmo almacenar de forma segura cadenas de conexin a bases de datos, consulte "Almacenar cadenas de conexin a bases de datos de forma segura" en el captulo 12, "Seguridad del acceso a datos". Utilice un almacn de datos centralizado para la autenticacin al que puedan obtener acceso ambas plataformas; por ejemplo, un directorio LDAP.
Comunicacin segura
Utilice SSL para proteger el enlace de comunicacin entre el explorador y el servidor Web. SSL proporciona confidencialidad e integridad para los mensajes. Utilice SSL o IPSec para disponer de un canal seguro entre el servidor Web y el servidor de aplicaciones o bases de datos.
Ms informacin
Para obtener ms informacin acerca de la comunicacin segura, consulte el captulo 4, "Comunicacin segura".
Almacenar secretos
Es habitual que las aplicaciones Web necesiten almacenar secretos. Esta necesidad debe protegerse ante administradores que no son de confianza y usuarios Web malintencionados como, por ejemplo: Administradores que no son de confianza. Los administradores y otros usuarios sin escrpulos no deberan poder ver informacin privilegiada. Por ejemplo, el administrador del servidor Web no debera poder leer la contrasea de una cuenta de inicio de sesin SQL Server de un equipo SQL Server ubicado en la red. Usuarios Web malintencionados. Aunque existen componentes (como FileAuthorizationModule) que evitan que los usuarios obtengan acceso a los archivos con privilegios, para aquellos casos en los que un intruso pueda llegar a obtener acceso a un archivo de configuracin, el secreto del archivo no debera incluirse en texto sin cifrar.
A continuacin figuran algunos ejemplos habituales de secretos: Cadenas de conexin de SQL. Un error habitual consiste en almacenar el nombre de usuario y la contrasea en formato de texto sin cifrar. Por ello, es recomendable utilizar la autenticacin de Windows en vez de la autenticacin de SQL. Si no puede utilizar la autenticacin de Windows, consulte las siguientes secciones del captulo 12, "Seguridad del acceso a datos," que constituyen alternativas seguras: "Almacenar cadenas de conexin a bases de datos de forma segura" "Comunicacin segura"
Credenciales utilizadas para las funciones de aplicacin de SQL . Las funciones de aplicacin de SQL deben activarse con un procedimiento almacenado que precisa el nombre de la funcin y la contrasea asociada. Para obtener ms informacin, consulte la seccin "Autorizacin" del captulo 12, "Seguridad del acceso a datos". Identidades fijas de Web.config. Por ejemplo:
<identity impersonate=true userName="bob" password="inClearText"/>
En .NET Framework versin 1.1, ASP.NET ofrecer la posibilidad de cifrar el nombre de usuario y la contrasea y almacenarlos de forma segura en la clave del registro. Identidad del proceso de Machine.config. Por ejemplo:
<process userName="cUsTuMUzerName" password=kUsTumPazzWerD >
De forma predeterminada, ASP.NET administra el uso del nombre de usuario "Machine" y de la contrasea "AutoGenerate".
En .NET Framework versin 1.1, ASP.NET ofrecer la posibilidad de cifrar el nombre de usuario y la contrasea y almacenarlos de forma segura en la clave del registro. Claves utilizadas para almacenar datos de forma segura . Es imposible almacenar claves de forma segura en el software. No obstante, existen algunas tareas que permiten reducir este riesgo. Un ejemplo consiste en crear un controlador de seccin de configuracin personalizada que utilice un cifrado asimtrico para cifrar una clave de sesin. La clave de sesin puede almacenarse en un archivo de configuracin. Estado de sesin de SQL Server. Para utilizar SQL Server para administrar el estado de sesin de la aplicacin Web de ASP.NET, utilice la siguiente configuracin para el archivo Web.config.
<sessionState stateConnectionString=tcpip=127.0.0.1:42424 sqlConnectionString=data source=127.0.0.1; user id=UserName;password=MyPassword />
En .NET Framework 1.1, ASP.NET incluir la capacidad de cifrar esta informacin. Contraseas utilizadas para la autenticacin mediante Formularios con una base de datos. Si su aplicacin valida las credenciales de autenticacin con una base de datos, no almacene las contraseas en la base de datos. Utilice un algoritmo hash de la contrasea con un valor salt y compare los hash. Para obtener ms informacin, consulte "Autenticar usuarios en una base de datos" en el captulo 12, "Seguridad del acceso a datos".
Opciones para almacenar secretos en ASP.NET

Los desarrolladores de aplicaciones Web .NET tienen a su disposicin una serie de enfoques distintos para almacenar secretos. Entre dichos mdulos figuran: Clases de criptografa de .NET. .NET Framework incluye clases que pueden utilizarse para el cifrado y el descifrado. Estos enfoques precisan almacenar de forma segura la clave de cifrado. API de proteccin de datos (DPAPI). DPAPI est formada por un par de API de Win32 que cifran y descifran datos mediante una clave obtenida a partir de la contrasea del usuario. El uso de DPAPI permite poder despreocuparse de la administracin de claves. Es el sistema operativo el que administra la clave, que es la contrasea del usuario. Cadenas constructoras COM+. Si la aplicacin utiliza componentes revisados, puede almacenar el secreto en una cadena de construccin de objetos. La cadena se almacena en el catlogo COM+ en formato de texto sin cifrar. CAPICOM. Objeto de Microsoft COM que ofrece acceso basado en COM a la Crypto API subyacente. Crypto API. Conjunto de API de Win32 de nivel inferior que ejecutan cifrado y descifrado.
Ms informacin
Si desea obtener ms informacin, consulte la entrada de Cryptography, CryptoAPI and CAPICOM (en ingls) en la Platform SDK de MSDN.
Posibilidad de almacenar secretos en archivos de volmenes lgicos independientes

Plantese la posibilidad de instalar directorios de aplicaciones Web en volmenes lgicos independientes del sistema operativo (por ejemplo, E: en lugar de C:). Esto significa que Machine.config (ubicado en C:\WINNT\Microsoft.NET) y probablemente otros archivos que contienen secretos, como pueden ser los archivos UDL (Universal Data Link), se ubican en volmenes lgicos independientes de los directorios de la aplicacin Web. La lgica de este enfoque consiste en evitar la posible canonizacin y errores transversales de directorio debido a: Errores de canonizacin de archivos que pueden exponer los archivos de las carpetas de la aplicacin Web. Nota: las rutinas de canonizacin de archivos recuperan la forma cannica de la ruta de acceso de los archivos. Suele ser el nombre completo de la ruta de acceso en el que se han resuelto todas las referencias relativas y referencias al directorio actual. Errores transversales de directorio que pueden exponer los archivos de otras carpetas del mismo volumen lgico.
Todava no se han publicado errores de este tipo que hayan expuesto los archivos de otros volmenes lgicos.
Proteger los estados de sesin y vista

Las aplicaciones Web deben administrar varios tipos de estados, incluidos el estado de vista y el estado de sesin. En esta seccin se describe la administracin segura de estados para las aplicaciones Web de ASP.NET.
Proteger el estado de vista

Si la aplicacin Web de ASP.NET utiliza el estado de vista: Garantice la integridad del estado de vista (para garantizar que no se vea alterado de ningn modo durante la transferencia) estableciendo enableViewStateMac en el valor true, tal como se indica a continuacin. De este modo, ASP.NET genera un cdigo MAC ( Message Authentication Code) en el estado de vista de la pgina cuando sta se expone de nuevo desde el cliente.
<% @ Page enableViewStateMac=true >
Configure el atributo validation del elemento <machineKey> del archivo Machine.config para especificar el tipo de cifrado que debe utilizarse para la validacin de los datos. Tenga en cuenta las siguientes consideraciones: El algoritmo hash seguro 1 (SHA1) genera un tamao de hash superior al de Message Digest 5 (MD5), por lo que se considera ms seguro. Sin embargo, el estado de vista protegido mediante SHA1 o MD5 puede descodificarse durante la transferencia o bien en el cliente y puede llegar a visualizarse en formato de texto sin cifrar. Utilice 3 Data Encryption Standard (3DES) para detectar cambios en el estado de vista, as como para ejecutar el cifrado durante la transferencia. En este estado, incluso si se llega a descodificar el estado de vista, no puede visualizarse en formato de texto sin cifrar.
Proteger las cookies

Las cookies que contienen datos de autenticacin o autorizacin, o cualquier otro tipo de datos importantes, deberan protegerse mediante SSL para las transferencias. La autenticacin mediante Formularios permite utilizar el mtodo FormsAuthentication.Encrypt para cifrar el vale de autenticacin, que se transfiere del cliente al servidor por medio de una cookie.
Proteger el estado de sesin de SQL

El controlador de estado de sesin de ASP.NET predeterminado (en proceso) presenta algunas limitaciones. Por ejemplo, no puede funcionar entre varios equipos de bateras de servidores Web. Para superar esta limitacin, ASP.NET permite almacenar los estados de sesin en una base de datos SQL Server. El estado de sesin de SQl puede configurarse en los archivos Machine.config o Web.config. A continuacin se muestra la configuracin predeterminada del archivo Machine.config.
<sessionState mode="InProc" stateConnectionString="tcpip=127.0.0.1:42424" stateNetworkTimeout="10" sqlConnectionString="data source=127.0.0.1;user id=sa;password=" cookieless="false" timeout="20"/>
De forma predeterminada, la secuencia de comandos InstallSqlState.sql de SQL, utilizada para crear la base de datos para el estado de sesin de SQL se instala en:
C:\WINNT\Microsoft.NET\Framework\v1.0.3705
El uso del estado de sesin de SQL provoca dos problemas: Debe protegerse la cadena de conexin a la base de datos. Debe protegerse el estado de sesin durante su transferencia por la red.
Proteger la cadena de conexin a bases de datos

Si utiliza la autenticacin de SQL para conectarse al servidor, la informacin del Id. del usuario y la contrasea se almacena en el archivo Web.config en formato de texto sin cifrar, como se muestra a continuacin:
<sessionState cookieless="false" timeout="20" mode="InProc" stateConnectionString="tcpip=127.0.0.1:42424" sqlConnectionString= "data source=127.0.0.1;user id=UserName;password=ClearTxtPassword" />
De forma predeterminada, HttpForbiddenHandler evita que se descarguen los archivos de configuracin. Sin embargo, cualquier usuario que disponga de acceso directo a las carpetas que almacenan los archivos de configuracin puede ver el nombre de usuario y la contrasea. Por ello, resulta ms aconsejable utilizar la autenticacin de Windows en vez de la autenticacin de SQL. Para utilizar la autenticacin de Windows, puede utilizar la identidad del proceso ASP.NET (que suele ser ASPNET).
1. Cree una cuenta duplicada (con el mismo nombre de usuario y contrasea) en la base de datos del servidor. 2. Cree un inicio de sesin SQL para la cuenta. 3. Cree un usuario de base de datos nuevo en la base de datos ASPState y asgnele el inicio de sesin SQL. La base de datos ASPState se crea con la secuencia de comandos InstallSQLState.sql. 5. Cree una nueva funcin de base de datos definida por el usuario y agregue el usuario de base de datos a la funcin. 6. Configure permisos de la base de datos para la funcin de base de datos. Si lo desea, puede cambiar la cadena de conexin para utilizar una conexin de confianza, como se muestra acto seguido:
sqlConnectionString="server=127.0.0.1; database=StateDatabase; Integrated Security=SSPI;"
Proteger el estado de sesin en la red

Quizs necesite proteger el estado de sesin durante su transferencia a travs de la red hasta la base de datos SQL Server. Dicha necesidad depende del nivel de seguridad del alojamiento de red para el servidor Web y el servidor de datos. Si la base de datos est protegida fsicamente en un entorno de confianza, es posible que pueda prescindir de esta medida de seguridad adicional. Puede utilizar IPSec para proteger todo el trfico IP existente entre los servidores Web y SQL Server; asimismo, tambin puede utilizar SSL para proteger el enlace con SQL Server. Este enfoque ofrece la opcin de cifrar nicamente la conexin utilizada para el estado de sesin, no todo el trfico que fluye entre los equipos.
Ms informacin
Para obtener ms informacin acerca de cmo configurar el estado de sesin de SQL, consulte el artculo Q317604, "HOW TO: Configure SQL Server to Store ASP.NET Session State" (en ingls) en la Microsoft Knowledge Base. Para obtener ms informacin acerca de cmo utilizar SSL para SQL Server, consulte "Cmo utilizar SSL para proporcionar comunicaciones seguras con SQL Server 2000" en la seccin de referencia de este manual. Para obtener ms informacin acerca del uso de IPSec, consulte "Cmo utilizar IPSec para garantizar una comunicacin segura entre dos servidores" en la seccin de referencia de este manual.
Consideraciones acerca de las bateras de servidores Web

Los escenarios de bateras de servidores Web no ofrecen garanta de que solicitudes sucesivas de un mismo cliente reciban servicio del mismo servidor Web. Esto podra tener implicaciones para la administracin del estado y para cualquier cifrado que se base en los atributos del elemento <machineKey> del archivo Machine.config.
Estado de sesin
El control de estados de sesin en proceso predeterminado de ASP.NET (que refleja la funcionalidad anterior de ASP) da lugar a la afinidad de servidores y no puede utilizarse en escenarios de bateras de servidores Web. Las implementaciones de
bateras de servidores Web exigen un almacenamiento externo al proceso sea en el servicio de estado de ASP.NET sea en una base de datos SQL Server, como se ha descrito anteriormente. Nota: el estado de la aplicacin no es de confianza para almacenar los contadores globales o los valores exclusivos de escenarios de bateras de servidores Web (la aplicacin Web configurada para ejecutarse en varios servidores) o bosque Web (aplicacin Web configurada para ejecutarse en varios procesadores) porque el estado de la aplicacin no se puede compartir entre varios procesos o equipos.
DPAPI
DPAPI puede funcionar bien con el almacn del equipo o del usuario (que requiere un perfil de usuario cargado). Si utiliza DPAPI con el almacn del equipo, la cadena cifrada es especfica de un equipo determinado y, por lo tanto, es necesario generar los datos cifrados en cada equipo. No copie los datos cifrados de un equipo a otro de una batera de servidores Web o clster. Si se utiliza DPAPI con el almacn del usuario, puede descifrar los datos en cualquier equipo que disponga de un perfil de usuario itinerante.
Ms informacin
Para obtener ms informacin acerca de DPAPI, consulte el captulo 12, "Seguridad del acceso a datos."
Utilizar la autenticacin mediante Formularios en una batera de servidores Web

Si utiliza la autenticacin mediante Formularios, resulta fundamental que todos los servidores de la batera de servidores Web compartan una clave de equipo, que se utiliza para el cifrado, descifrado y la validacin del vale de autenticacin. La clave de equipo se almacena en el elemento < machineKey> del archivo Machine.config. Se muestra la configuracin predeterminada a continuacin.
<machineKey validationKey="AutoGenerate" decryptionKey="AutoGenerate" validation="SHA1"/>
Esta configuracin provoca que cada equipo genere una clave de validacin y descifrado distinta. Es necesario cambiar el elemento < machineKey> e incluir valores de clave comunes en todos los servidores de la batera de servidores Web.
El elemento <machineKey>
El elemento <machineKey> ubicado en el archivo Machine.config se utiliza para configurar las claves empleadas para el cifrado y el descifrado de los datos de la cookie de autenticacin mediante Formularios y del estado de vista. Cuando se llaman los mtodos FormsAuthentication.Encrypt o FormsAuthentication.Decrypt, y cuando se crea o recupera el estado de vista, se consultan los valores del elemento <machineKey>.
<machineKey validationKey="autogenerate|value" decryptionKey="autogenerate|value" validation="SHA1|MD5|3DES" />
El atributo validationKey
El valor del atributo validationKey se utiliza para crear y validar cdigos MAC del estado de vista y los vales de autenticacin mediante Formularios. El atributo de validacin determina el algoritmo que debe utilizarse para la creacin del cdigo MAC. Tenga en cuenta las siguientes consideraciones: Al utilizar la autenticacin mediante Formularios, esta clave funciona junto con el atributo <forms> protection. Si se establece el atributo de proteccin en Validation y se llama el mtodo FormsAuthentication.Encrypt, se utilizarn el valor del vale y validationKey para calcular el cdigo MAC que debe adjuntarse a la cookie. Cuando se llama el mtodo FormsAuthentication.Decrypt, el cdigo MAC se calcula y compara con el cdigo MAC que se adjunta al vale. Con el estado de vista se utilizan el valor del estado de vista de un control y validationKey para calcular el cdigo MAC, que se adjunta al estado de vista. Cuando se expone de nuevo el estado de vista desde el cliente, se vuelve a calcular el cdigo MAC y se compara con el MAC adjunto al estado de vista.
El atributo decryptionKey
El valor del atributo decryptionKey se utiliza para cifrar y descifrar vales de autenticacin mediante Formularios y estados de vista. En cuanto a algoritmos, se utilizan DES o Triple DES (3DES). El algoritmo exacto depende de si se ha instalado el pack de cifrado alto de Windows 2000. Si est instalado se utilizar 3DES; de lo contrario, DES. Tenga en cuenta las siguientes consideraciones: Al utilizar la autenticacin mediante Formularios, esta clave funciona junto con el atributo <forms> protection. Si se establece el atributo protection en el valor Encryption, y se llaman los mtodos FormsAuthentication.Encrypt o Decrypt, el valor del vale se cifra o descifra con el valor decryptionKey especificado. Al utilizar la vista de estado, el valor de un estado de vista de controles se cifra mediante el valor decryptionKey cuando se enva al cliente y se descifra cuando el cliente vuelve a exponer los datos en el servidor.
El atributo Validation
Este atributo determina el algoritmo que debe utilizarse para la validacin, el cifrado o el descifrado. Puede adoptar los valores SHA1, MD5 o 3DES. Dichos valores se describen a continuacin: SHA1. El algoritmo HMACSHA1 se utiliza cuando la configuracin es SHA1. Genera un algoritmo hash de 160 bits (20 bytes) o un compendio de la entrada. HMACSHA1 es un algoritmo hash de claves. La clave utilizada como entrada para este algoritmo se especifica mediante el atributo validationKey. SHA1 es un algoritmo de gran aceptacin por su mayor tamao de compendio en comparacin con otros algoritmos. MD5. Genera un algoritmo hash de 20 bytes mediante el algoritmo MD5. 3DES. Cifra los datos mediante el algoritmo Triple DES (3DES). Nota: cuando el atributo de validacin se establece en 3DES, no se utiliza para la autenticacin mediante Formularios. En ese caso se utiliza SHA1.
Ms informacin
Si desea obtener ms informacin acerca de cmo crear las claves adecuadas e incluirlas en el archivo Machine.config, consulte el artculo Q312906, "HOW TO: Create Keys w/ C# .NET for Use in Forms Authentication" (en ingls) de la Microsoft Knowledge Base.
Para obtener ms informacin acerca del paquete de cifrado alto de Windows 2000, consulte http://www.microsoft.com/windows2000/downloads/recommended/encryption/ (en ingls).
Resumen
En este captulo se describen una serie de tcnicas y enfoques para la proteccin de aplicaciones Web de ASP.NET. Muchos de los consejos y las recomendaciones de este captulo tambin pueden resultar tiles para desarrollar servicios Web ASP.NET y objetos NET Remoting alojados en ASP.NET. En resumen: Si su aplicacin utiliza la autenticacin mediante Formularios y el rendimiento es un aspecto que no se desea descuidar a la hora de autenticar los usuarios, recupere una lista de funciones y almacnela en el vale de autenticacin. Si utiliza la autenticacin mediante Formularios, cree siempre un objeto principal y gurdelo en el contexto de cada solicitud. Si existen demasiadas funciones para almacenar en la cookie de autenticacin, utilice la memoria cach global de la aplicacin para almacenar las funciones. No cree una cuenta con privilegios mnimos personalizada para ejecutar ASP.NET. En su lugar, cambie la contrasea de la cuenta de ASPNET y cree una cuenta duplicada en cualquier servidor Windows remoto al que deba obtener acceso la aplicacin. Si debe crear una cuenta personalizada para ejecutar ASP.NET, utilice el principio de los privilegios mnimos. Por ejemplo: Utilice una cuenta de dominio con privilegios mnimos si la administracin es un problema importante. Si utiliza una cuenta local, cree una cuenta duplicada en cualquier equipo remoto al que debe obtener acceso la aplicacin Web. Utilice cuentas locales cuando la aplicacin necesite obtener acceso a recursos ubicados en dominios que no son de confianza, o si un servidor de seguridad impide la autenticacin de Windows. No ejecute ASP.NET mediante la cuenta SISTEMA local. No conceda a la cuenta ASPNET el privilegio Actuar como parte del sistema operativo. Se transfiere informacin importante de seguridad entre el explorador y el servidor Web. Se utiliza la autenticacin bsica (para proteger las credenciales). Se utiliza la autenticacin mediante Formularios para la autenticacin (a diferencia de la personalizacin).
Utilice SSL si:
Evite almacenar secretos en formato de texto sin cifrar.

Capítulo 8 Seguridad de

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Capítulo 8 Seguridad de

Uploaded by

Copyright:

Available Formats

Crear aplicaciones ASP.

Captulo 8: Seguridad de ASP.NET

Arquitectura de seguridad de ASP.NET

{Insert figure: CH08 - ASP.NET Security Services.gif} Ilustracin 8.1

{Insert figure: CH08 ASP.NET and IIS Gatekeepers.gif} Ilustracin 8.2

Peticiones de permisos Principal y comprobaciones de funciones explcitas

Estrategias de autenticacin y autorizacin

Opciones de autorizacin disponibles

Requiere autenticacin de Windows

Ambas restricciones se eliminarn en la siguiente versin de .NET Framework.

Autenticacin de Windows con suplantacin

<authentication mode="Windows" /> <identity impersonate="true" />

Seguridad mediante programacin

Declarativas (atributos previos a las interfaces, clases y mtodos)

Autenticacin de Windows sin suplantacin

Seguridad mediante programacin

Autenticacin de Windows con identidad fija

Autenticacin mediante Formularios

Seguridad mediante programacin

{Insert figure: CH08 Configuring ASP.NET Security.gif} Ilustracin 8.3

Configurar los parmetros de IIS

Configurar los parmetros de ASP.NET

<deny users="*" /> </authorization>

Notas acerca de la autorizacin mediante direcciones URL

Ejemplos de la autorizacin mediante direcciones URL

Denegar el acceso a todos los usuarios.

Denegar el acceso a la funcin Manager.

Ejemplo de la autenticacin mediante Formularios

</authorization> </system.web> </configuration>

Bloquear los parmetros de configuracin

Impedir que se descarguen los archivos

Incluir usuarios en las funciones

Crear un objeto IPrincipal

Incluir el objeto IPrincipal en el contexto HTTP actual

Ejecutar la autorizacin en funcin de la identidad del usuario o la pertenencia a funciones

Crear una clase IPrincipal personalizada

{Insert figure: CH08 - IIS ASP.NET Relationship.gif} Ilustracin 8.4

Identificar al usuario autenticado

Autenticacin mediante Formularios

{Insert figure: CH08 - Forms auth sequence.gif} Ilustracin 8.5

Pasos de desarrollo para la autenticacin mediante Formularios

Configurar IIS para el acceso annimo

5. Seleccione Acceso annimo.

Configurar ASP.NET para la autenticacin mediante Formularios

Crear un formulario Web de inicio de sesin y validar las credenciales suministradas

Recuperar una lista de funciones del almacn de datos personalizado

Crear un vale de la autenticacin mediante Formularios

Crear un objeto IPrincipal

Incluir el objeto IPrincipal en el contexto HTTP actual

Autorizar a los usuarios en funcin del nombre de usuario o la pertenencia a funciones

Instrucciones para la implementacin de Formularios

Alojar varias aplicaciones mediante la autenticacin mediante Formularios

Autenticacin mediante Formularios sin cookies

Configurar ASP.NET para la autenticacin de Passport

Asignar una identidad Passport a las funciones de Global.asax

Probar la pertenencia a funciones

if (null == passportId) { Response.Write("Not a PassportIdentity<br>"); return; } Response.Write("IsInRole: Develeoper? " + Context.User.IsInRole("Developer"));

Identidad del proceso para ASP.NET

Utilizar una cuenta con privilegios mnimos

Evitar la ejecucin como SISTEMA

Controladores de dominio y la cuenta de proceso de ASP.NET

Utilizar la cuenta predeterminada de ASPNET

Suplantacin y recursos locales