capítulo 8 seguridad de asp.net

Crear aplicaciones ASP.NET segurasAutenticación, autorización y

comunicación segura

Capítulo 8: Seguridad de ASP.NET

J.D. Meier, Alex Mackman, Michael Dunner y Srinath Vasireddy

Microsoft Corporation

Octubre de 2002

Consulte la Página de entrada como punto de partida y para obtener una descripción completa del documento Crear aplicaciones ASP.NET seguras.

Resumen

Este capítulo se presenta a modo de guía e incluye recomendaciones que le ayudarán a crear aplicaciones Web ASP.NET seguras. Muchos de los consejos y las recomendaciones de este capítulo también pueden resultar útiles para desarrollar servicios Web ASP.NET y objetos .NET Remoting alojados en ASP.NET.

Contenido

Arquitectura de seguridad de ASP.NET

Autenticación y autorización

Configurar la seguridad

Programar la seguridad

Autenticación de Windows

Autenticación mediante Formularios

Autenticación de Passport

Autenticación personalizada

Identidad del proceso para ASP.NET

Suplantación

Obtener acceso a recursos de sistema

Obtener acceso a recursos de red

Comunicación segura

Almacenar secretos

Proteger los estados de sesión y vista

Consideraciones acerca de las baterías de servidores Web

Resumen

Arquitectura de seguridad de ASP.NETASP.NET actúa en combinación con IIS, .NET Framework y los servicios de seguridad subyacentes proporcionados por el sistema operativo para ofrecer una serie de mecanismos de autenticación y autorización. Dichos mecanismos se reflejan en la ilustración 8.1.

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

Ilustración 8.1Servicios de seguridad de ASP.NET

La ilustración 8.1 muestra los mecanismos de autenticación y autorización que ofrecen IIS y ASP.NET. Cuando un cliente envía una solicitud Web, se produce la siguiente secuencia de eventos de autenticación y autorización:

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 también 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 autenticación básica, implícita, integrada (NTLM o Kerberos) o mediante certificados. Si el sitio, parcial o totalmente, no requiere acceso autenticado, IIS puede configurarse para la autenticación anónima. IIS crea un testigo de acceso a Windows para cada uno de los

usuarios autenticados. Si selecciona la autenticación anónima, IIS creará un testigo de acceso para la cuenta de usuario anónima 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 también puede configurarse para que acepte solicitudes únicamente de los equipos cliente con unas direcciones IP específicas.

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 anónimo si se utiliza la autenticación anónima).

5. ASP.NET autentica al llamador. Si se configura ASP.NET para la autenticación de Windows, no se efectuará ningún otro tipo de autenticación adicional en esta fase. ASP.NET aceptará cualquier testigo que reciba de IIS.

Si se configura ASP.NET para la autenticación mediante Formularios, las credenciales que proporcione el llamador (mediante un formulario HTML) se autenticarán con un almacén 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 autenticación de Passport, el usuario será redirigido a un sitio Passport y será el servicio de autenticación de Passport el que se encargará de autenticar al usuario.

6. ASP.NET autoriza el acceso al recurso o la operación solicitados. UrlAuthorizationModule (un módulo HTTP proporcionado por el sistema) utiliza unas reglas de autorización 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 autenticación de Windows, FileAuthorizationModule (otro módulo 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 protección del recurso.

Las funciones .NET también pueden utilizarse (mediante declaraciones o programación) para garantizar que el llamador reciba autorización para obtener acceso al recurso solicitado o para llevar a cabo la operación solicitada.

7. El código de la aplicación obtiene acceso a los recursos locales o remotos mediante una determinada identidad. De forma predeterminada, ASP.NET no lleva a cabo ninguna suplantación, 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 suplantación) o una identidad de servicio configurada.

Equipos selectoresLos puntos de autorización (o equipos selectores) de una aplicación Web ASP.NET los proporcionan IIS y ASP.NET.

IIS

Con la autenticación anónima desactivada, IIS sólo 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 estáticos (como los archivos .jpg, .gif y .htm, archivos que no están asignados a ninguna extensión 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 módulos UrlAuthorizationModule, FileAuthorizationModule y peticiones de permisos Principal además de comprobaciones de funciones.

UrlAuthorizationModule

Puede configurar elementos <authorization> del archivo Web.config de la aplicación para controlar los usuarios y grupos de usuarios que deberían tener acceso a la aplicación. La autorización se basa en el objeto IPrincipal almacenado en HttpContext.User.

FileAuthorizationModule

En cuanto a los tipos de archivos que IIS asigna a la extensión ISAPI de ASP.NET (Aspnet_isapi.dll), se realizan comprobaciones de acceso automáticas 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 suplantación para que funcione la autorización de archivos.

La clase FileAuthorizationModule sólo realiza comprobaciones de acceso para el archivo solicitado, no para los archivos a los que el código obtiene acceso en la página 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 comprobación de acceso para Default.aspx y Usercontrol.ascx, porque IIS asigna estos tipos de archivo a la extensión ISAPI de ASP.NET.

FileAuthorizationModule no realiza ninguna comprobación para Image.gif porque se trata de un archivo estático que IIS controla internamente. No obstante, dado que IIS comprueba el acceso para los archivos estáticos, el usuario autenticado también necesita permisos de lectura para el archivo y una ACL configurada correctamente.

La ilustración 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 sólo necesita acceso de lectura para los tipos de archivo ASP.NET registrados.

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

Ilustración 8.2Interacción 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 código de Default.aspx no podrá enviar al cliente el control de usuario ni las imágenes incrustadas. Si el usuario solicita las imágenes directamente, IIS realizará las comprobaciones de acceso él mismo.

Peticiones de permisos Principal y comprobaciones de funciones explícitas

Además de los equipos selectores configurables de IIS y ASP.NET, también puede utilizar las peticiones de permisos Principal (mediante declaraciones o programación) como mecanismo adicional de control de acceso de mayor precisión. Las comprobaciones de permisos Principal (que ejecuta la clase PrincipalPermissionAttribute) permiten controlar el acceso a las clases, métodos o bloques de código individuales en función de la identidad y la pertenencia a grupos de los usuarios individuales, según 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 comprobación de la pertenencia a funciones; las primeras dan lugar a una excepción si el llamador no es miembro de la función especificada, mientras que las últimas se limitan a devolver un valor booleano para confirmar la pertenencia a las funciones.

Con la autenticación de Windows, ASP.NET adjunta de forma automática un objeto WindowsPrincipal que representa al usuario autenticado en la solicitud Web actual (mediante HttpContext.User). La autenticación mediante Formularios y de Passport crea un objeto GenericPrincipal con la identidad adecuada, pero sin funciones, y lo adjunta a HttpContext.User.

Más información

● Si desea obtener más información acerca de cómo configurar la seguridad, consulte "Configurar la seguridad" en este mismo capítulo.

● Si desea obtener más información acerca de cómo programar la seguridad (y los objetos IPrincipal), consulte "Programar la seguridad" en este mismo capítulo.

Estrategias de autenticación y autorizaciónASP.NET proporciona una serie de mecanismos de autorización mediante declaraciones y programación que pueden utilizarse junto con una gran variedad de esquemas de autenticación. De este modo puede desarrollar una estrategia de autorización exhaustiva y otra que pueda configurarse para ofrecer diferentes grados de granularidad: por ejemplo, por usuario o por grupo (basado en funciones).

Esta sección describe las opciones de autorización (tanto configurables como programáticas) disponibles para una serie de opciones de autenticación que se utilizan habitualmente.

A continuación se resumen las opciones de autenticación:

● Autenticación de Windows con suplantación

● Autenticación de Windows sin suplantación

● Autenticación de Windows con identidad fija

● Autenticación mediante Formularios

● Autenticación de Passport

Opciones de autorización disponiblesLa siguiente tabla refleja el conjunto de opciones de autorización disponibles. Se indica para cada opción si son necesarias la autenticación de Windows o la suplantación. En caso de no ser necesaria la autenticación de Windows, se indica la opción de autorización específica disponible para el resto de los tipos de autenticación. Esta tabla le permitirá ajustar el funcionamiento de su estrategia de autenticación/autorización.

Tabla 8.1: autenticación de Windows y requisitos de suplantación

Opción de autorización Requiere autenticación de Windows

Requiere suplantación

FileAuthorizationModule Sí No

UrlAuthorizationModule No No

Peticiones de permisos

Principal

No No

Funciones .NET No No

Funciones de Servicios

Empresariales

Sí Sí (en la aplicación Web

ASP.NET)

Permisos NTFS (para tipos

de archivos estáticos

solicitados directamente; no

asignados a extensiones

ISAPI)

N/D: estos archivos no los

controla ASP.NET.

Si se utiliza cualquier

mecanismo de

autenticación IIS (distinto

del anónimo), los permisos

deberían configurarse para

usuarios autenticados

individualmente.

No (IIS realiza la

comprobación de acceso.)

Si se utiliza la autenticación

anónima, deberían

configurarse los permisos

de IUSR_MACHINE.

Permisos NTFS (para

archivos a los que obtiene

acceso el código de la

aplicación Web)

No No

Si se ejecuta la

suplantación, configure las

listas ACL según 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 configuración se traduce en la suplantación del llamador original (según lo haya autenticado IIS), mientras que la segunda da lugar a la identidad Bob. La segunda configuración 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.

● También requiere incluir una contraseña de texto sin cifrar en el archivo Web.config.

Ambas restricciones se eliminarán en la siguiente versión de .NET Framework.

Autenticación de Windows con suplantaciónLos siguientes elementos de configuración muestran cómo habilitar la autenticación de Windows (IIS) y la suplantación mediante declaraciones en los archivos Web.config o Machine.config.

Nota: es recomendable configurar la autenticación en función de cada aplicación en el archivo Web.config de las aplicaciones.

<authentication mode="Windows" />


Con esta configuración, el código de la aplicación ASP.NET suplanta al llamador autenticado por IIS.

Seguridad configurable

El empleo de la autenticación de Windows junto con la funcionalidad de suplantación ofrece las siguientes opciones de autorización:

● 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 estáticos (no asignados a ninguna extensión 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 aplicación. Pueden configurarse las listas ACL de Windows de los recursos a los que obtenga acceso la aplicación (archivos, carpetas, claves de registro, objetos de Active Directory, etc.) en función del llamador original.

● Autorización mediante direcciones URL. La autorización mediante direcciones URL se configura en el archivo Web.config. Con la autenticación 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 catálogo COM+. Puede configurar estas funciones con ayuda de la herramienta de administración o la secuencia de comandos de Servicios de componentes.

Seguridad mediante programación

La seguridad mediante programación hace referencia a las comprobaciones de seguridad ubicadas en el código de la aplicación Web. Las siguientes opciones de seguridad mediante programación están disponibles cuando se utiliza la autenticación de Windows con la función de suplantación.

● Peticiones de permisos PrincipalPermission

● Imperativas (en las líneas del código del método)

PrincipalPermission permCheck = new PrincipalPermission(

null, @"DomainName\WindowsGroup");

permCheck.Demand();

● Declarativas (atributos previos a las interfaces, clases y métodos)

[PrincipalPermission(SecurityAction.Demand,

Role=@"DomainName\WindowsGroup)]

● Comprobaciones de funciones explícitas. Puede realizar la comprobación de funciones mediante la interfaz IPrincipal.

IPrincipal.IsInRole(@"DomainName\WindowsGroup");

● Funciones de Servicios Empresariales (COM+). Puede realizar la comprobación de funciones mediante programación con la clase ContextUtil.

ContextUtil.IsCallerInRole("Manager")

Escenarios de uso

Utilice la autenticación de Windows y la suplantación cuando se den las siguientes condiciones:

● Los usuarios de la aplicación 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 aplicación Web para admitir la autorización de granularidad fina (por usuario).

● Se requiere transferir el contexto de seguridad del llamador original a los niveles indirectos a fin de admitir la auditoría de nivel del sistema operativo.

Antes de utilizar la suplantación con la aplicación, asegúrese de que comprende las repercusiones de este enfoque en relación con el empleo del modelo de subsistema de confianza. Se ha llevado a cabo un compendio de dichas repercusiones, que se presentan en la sección "Seleccionar un modelo de acceso a los recursos" en el capítulo 3, "Autenticación y autorización."

Entre las desventajas de la suplantación figuran:

● Escalabilidad reducida de la aplicación debido a la imposibilidad de agrupar efectivamente conexiones de bases de datos.

● Mayor esfuerzo de administración porque las listas ACL de los recursos servidor deben configurarse para cada uno de los usuarios.

● La delegación exige la autenticación Kerberos y un entorno configurado correctamente.

Más información

● Si desea obtener más información acerca de la autenticación de Windows, consulte la sección "Autenticación de Windows" en este mismo capítulo.

● Si desea obtener más información acerca de la suplantación, consulte el apartado "Suplantación" que figura más adelante en este capítulo.

● Si desea obtener más información acerca de la autorización mediante direcciones URL, consulte "Notas acerca de la autorización mediante direcciones URL" en este mismo capítulo.

● Si desea obtener más información acerca de las funciones de Servicios Empresariales (COM+), consulte el capítulo 9, "Seguridad de la aplicación de Servicios Empresariales".

● Si desea obtener más información acerca de las peticiones PrincipalPermission, consulte el apartado "Identidades y principales" del capítulo 2, "Modelo de seguridad para aplicaciones ASP.NET".

Autenticación de Windows sin suplantaciónLos siguientes elementos de configuración muestran cómo habilitar la autenticación de Windows (IIS) sin suplantación de forma declarativa en el archivo Web.config.

<authentication mode="Windows" />



<identity impersonate="false" />


El empleo de la autenticación de Windows sin la suplantación ofrece las siguientes opciones de autorización:

● 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 suplantación.En el caso de los tipos de archivo estáticos (no asignados a ninguna extensión 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 aplicación. Puede configurar las listas ACL de Windows de los recursos a los que tenga acceso la aplicación (archivos, carpetas, claves de registro, objetos de Active Directory, etc.) con la identidad del proceso ASP.NET.

● Autorización mediante direcciones URL. La autorización mediante direcciones URL se configura en el archivo Web.config. Con la autenticación 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 disposición las siguientes opciones de seguridad mediante programación:

● Peticiones de permisos Principal

● Imperativas


null, @"DomainName\WindowsGroup");

permCheck.Demand();

● Declarativas


Role=@"DomainName\WindowsGroup")]


IPrincipal.IsInRole(@"DomainName\WindowsGroup");

Escenarios de uso

Utilice la autenticación de Windows sin suplantación cuando se den las siguientes condiciones:

● Los usuarios de la aplicación 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 agrupación de conexiones.

Más información

● Si desea obtener más información acerca de la autenticación de Windows, consulte la sección "Autenticación de Windows" en este mismo capítulo.

● Si desea obtener más información acerca de la autorización mediante direcciones URL, consulte “Notas acerca de la autorización mediante direcciones URL" que encontrará más adelante en este mismo capítulo.

● Si desea obtener más información acerca de las peticiones PrincipalPermission, consulte el apartado "Principals" de la sección “Introducción" de esta guía.

Autenticación de Windows con identidad fijaEl elemento <identity> del archivo Web.config es compatible con los atributos opcionales de nombre de usuario y contraseña, lo cual permite configurar una identidad fija específica para que la aplicación la suplante. El siguiente fragmento del archivo de configuración es una muestra de este enfoque.

<identity impersonate="true" userName="DomainName\UserName"

password="ClearTextPassword" />

Escenarios de uso

Este enfoque no es recomendable para la versión actual (versión 1) de .NET Framework en entornos seguros por dos motivos:

● Los nombres de usuario y las contraseñas no deberían almacenarse en formato de texto sin cifrar en los archivos de configuración, en especial en los archivos de configuración 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 concesión reduce la seguridad de la aplicación Web y aumenta el riesgo de la amenaza en caso de que un intruso pudiera llegar a exponer el proceso de la aplicación Web.

.NET Framework versión 1.1 incluirá una mejora para este escenario en Windows 2000:

● Se cifrarán las credenciales.

● El inicio de sesión lo llevará a cabo el proceso IIS, de manera que ASP.NET no requiera el privilegio “Actuar como parte del sistema operativo”.

Autenticación mediante FormulariosLos siguientes elementos de configuración muestran cómo habilitar la autenticación 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 autenticación mediante Formularios pone a su disposición las siguientes opciones de autorización:


● Recursos solicitados por los clientes. Los recursos solicitados exigen que las listas ACL permitan el acceso de lectura a la cuenta anónima de usuario de Internet. (IIS debería configurarse para permitir el acceso anónimo cuando se utiliza la autenticación mediante Formularios.)La autorización de archivos de ASP.NET no está disponible porque requiere la autenticación de Windows.

● Recursos a los que obtiene acceso la aplicación. Pueden configurarse las listas ACL de Windows de los recursos a los que obtenga acceso la aplicación (archivos, carpetas, claves de registro, objetos de Active Directory, etc.) con la identidad del proceso ASP.NET.

● Autorización mediante direcciones URLConfigure la autorización mediante direcciones URL en el archivo Web.config. Al utilizar la autenticación mediante Formularios, el formato de los nombres de usuario viene determinado por el almacén de datos personalizado: una base de datos de SQL Server o Active Directory.

● Si utiliza un almacén de datos de SQL Server:

<authorization>

<deny users="?" />

<allow users="Mary,Bob,Joe" roles="Manager,Sales" />

</authorization>

● Si utiliza Active Directory como almacén de datos, los nombres de usuario y de los grupos adoptarán el formato X.500:

<authorization>

<deny users="[email protected]" />

<allow roles ="CN=Smith James,CN=FTE_northamerica,CN=Users,

DC=domain,DC=corp,DC=yourCompany,DC=com" />

</authorization>


Tiene a su disposición las siguientes opciones de seguridad mediante programación:

● Peticiones de permisos Principal

● Imperativas


null, "Manager");

permCheck.Demand();

● Declarativas


Role="Manager")]


IPrincipal.IsInRole("Manager");

Escenarios de uso

La autenticación mediante Formularios resulta específicamente idónea para las aplicaciones de Internet. Utilice la autenticación mediante Formularios si:

● Los usuarios de la aplicación no tienen cuentas de Windows.

● Desea que los usuarios inicien sesión en la aplicación escribiendo las credenciales en un formulario HTML.

Más información

● Si desea obtener más información acerca de la autenticación mediante Formularios, consulte la sección "Autenticación mediante Formularios" que figura más adelante en este mismo capítulo.

● Si desea obtener más información acerca de la autorización mediante direcciones URL, consulte "Notas acerca de la autorización mediante direcciones URL" en este mismo capítulo.

Autenticación de PassportLos siguientes elementos de configuración muestran cómo habilitar la autenticación de Passport de forma declarativa en el archivo Web.config.

<authentication mode="Passport" />

Escenarios de uso

La autenticación de Passport se utiliza en Internet cuando los usuarios de la aplicación no tienen cuentas de Windows y se desea implementar una solución de inicio de sesión único. Los usuarios que hayan iniciado una sesión previamente con una cuenta Passport en un sitio de Passport no tendrán que volver a iniciar sesión en su sitio si éste se ha configurado para la autenticación de Passport.

Configurar la seguridadEn esta sección se presentan los pasos que deben realizarse para configurar la seguridad de una aplicación Web de ASP.NET. La ilustración 8.3 resume estos pasos.

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

Ilustración 8.3Configurar la seguridad de una aplicación ASP.NET

Configurar los parámetros de IISPara 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 más información, consulte "Cómo configurar SSL en un servidor Web" en la sección de referencia de este manual.

2. Configure la autenticación de IIS

3. Si lo desea, configure la asignación de certificados de cliente (si utiliza la autenticación mediante certificados).Si desea obtener más información acerca de la asignación de certificados de cliente, consulte el artículo Q313070, “How to Configure Client Certificate Mappings in Internet Information Services (IIS) 5.0" (en inglés) 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 anónima de usuario de Internet) disponga de los derechos de acceso necesarios (según la configuración ACL) para obtener acceso al archivo solicitado.

Configurar los parámetros de ASP.NETLos parámetros de configuración del nivel de aplicación se almacenan en los archivos Web.config, ubicados en el directorio raíz virtual de la aplicación y, en ocasiones, también en subcarpetas adicionales (esta configuración puede suplantar algunas veces la configuración de la carpeta principal).

1. Configurar la autenticación. Debería configurarse en todos y cada uno de los archivos Web.config de las aplicaciones que se encuentran en el directorio raíz virtual de la aplicación (no en el archivo Machine.config).

<authentication mode="Windows|Forms|Passport|None" />

2. Configurar la suplantación. De manera predeterminada, las aplicaciones ASP.NET no aplican la suplantación. 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 suplantación sólo 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 autenticación anónima y se desea utilizar la cuenta anónima de usuario de Internet para obtener acceso a los recursos. Si desea obtener más información acerca de este enfoque, consulte el apartado "Obtener acceso a recursos de red" que figura más adelante en este capítulo.

● Es necesario transmitir el contexto de seguridad del usuario autenticado al siguiente nivel (la base de datos, por ejemplo).

● Ha expuesto una aplicación ASP clásica en ASP.NET y desea el mismo comportamiento de suplantación. Las aplicaciones ASP clásicas suplantan al llamador de forma predeterminada.

Para configurar la suplantación de ASP.NET, utilice el siguiente elemento <identity> del archivo Web.config de la aplicación.


3. Configurar la autorización. La autorización mediante direcciones URL determina si un usuario o función pueden emitir un verbo HTTP (por ejemplo, GET, HEAD y POST) para un archivo específico. Para implementar la autorización mediante direcciones URL es preciso que lleve cabo las siguientes tareas.

a. Agregue un elemento <authorization> al archivo Web.config ubicado en el directorio raíz virtual de la aplicación.

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 autenticación 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 autorización mediante direcciones URL

Tenga en cuenta los siguientes aspectos cuando configure la autorización mediante direcciones URL:

● "*" hace referencia a todas las identidades.

● "?" hace referencia a las identidades no autenticadas (es decir, la identidad anónima).

● No es necesario aplicar la suplantación para que funcione la autorización mediante direcciones URL.

● La configuración de la autorización 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 configuración del subdirectorio sustituye la del directorio principal).

Nota: la autorización mediante direcciones URL sólo se aplica a los tipos de archivos a los que IIS asigna la extensión ISAPI de ASP.NET, aspnet_isapi.dll.

Puede utilizar la etiqueta <location> para que la configuración de la autorización se aplique a un archivo o directorio específicos. El siguiente ejemplo muestra cómo aplicar la autorización a un archivo específico (Page.aspx).

<location path="page.aspx" />

<authorization>

<allow users="DomainName\Bob, DomainName\Mary" />

<deny users="*" />

</authorization>

</location>

● Los usuarios y las funciones de la autorización mediante direcciones URL se determinan mediante la configuración de la autenticación:

● 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 autenticación 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 autorización según las funciones obtenidas de la base de datos.

● Cuando el elemento del modo de autenticación se establece en Passport (<authentication mode=”Passport” />), la autorización se efectúa con relación al identificador del usuario de Passport (PUID) o las funciones obtenidas de un almacén. 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 función se integrará en el sistema operativo Microsoft Windows Server 2003.

● Cuando se establece el modo de autenticación en ninguno (<authentication mode=”None” />), no se realiza ninguna autorización. "None" indica que no se desea realizar ninguna autenticación o que no se desea utilizar ninguno de los módulos de autenticación .NET sino un mecanismo personalizado propio. No obstante, si utiliza la autenticación personalizada, debería crear un objeto IPrincipal con funciones y almacenarlo en HttpContext.User. Cuando, posteriormente, lleve a cabo la autorización mediante direcciones URL, ésta se ejecutará con el usuario y las funciones (independientemente de cómo se obtengan) almacenadas en el objeto IPrincipal.

Ejemplos de la autorización mediante direcciones URL

La siguiente lista muestra la sintaxis de algunos ejemplos habituales de la autorización mediante direcciones URL.

● Denegar el acceso a la cuenta anónima.

<deny users="?" />

● Denegar el acceso a todos los usuarios.

<deny users="*" />

● Denegar el acceso a la función Manager.

<deny roles="Manager"/>

● Ejemplo de la autenticación mediante Formularios

<configuration>

<system.web>


<forms name=".ASPXUSERDEMO"

loginUrl="login.aspx"

protection="All" timeout="60" />

</authentication>

<authorization>

<deny users="[email protected]" />

<deny users="?" />

</authorization>

</system.web>

</configuration>

Más información

El elemento <authorization> funciona con el objeto IPrincipal actual almacenado en HttpContext.User y HttpContext.Request.RequestType.

Proteger recursos1. Utilice listas ACL de Windows para proteger recursos, incluidos archivos,

carpetas y claves de registro. Si no utiliza la suplantación, cualquier recurso al que necesite obtener acceso la aplicación deberá disponer de una lista ACL que conceda, como mínimo, el acceso de lectura a la cuenta de proceso de ASP.NET.

Si utiliza la suplantación, los archivos y las claves de registro deben contar con listas ACL que concedan, como mínimo, acceso de lectura al usuario autenticado (o a la cuenta anónima de usuario de Internet, en caso de ser efectiva la autenticación anónima).

2. Proteja los archivos Web.config y Machine.config:

● Utilice las listas ACL correctas. Si ASP.NET utiliza la suplantación, 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 suplantación para la cuenta anónima de usuario de Internet (IUSR_MACHINE), debería denegar el acceso a esta cuenta.

Nota: si su aplicación se asigna a un recurso compartido UNC, la identidad UNC requerirá el acceso de lectura también para los archivos de configuración.

● Elimine los módulos HTTP no deseados. Machine.config contiene una serie de módulos HTTP predeterminados (incluidos en el elemento <httpModules>). Estos módulos son:

● WindowsAuthenticationModule

● FormsAuthenticationModule

● PassportAuthenticationModule

● UrlAuthorizationModule

● FileAuthorizationModule

● OutputCacheModule

● SessionStateModule

Si su aplicación no utiliza ningún módulo en especial, elimínelo para evitar en el futuro cualquier posible problema de seguridad asociado con un determinado módulo debido a su explotación por la aplicación.

3. Si lo desea, bloquee la configuración mediante el elemento <location> y el atributo allowOverride="false", tal como se describe más abajo.

Bloquear los parámetros de configuración

Los parámetros de configuración son jerárquicos. La configuración del archivo Web.config de los subdirectorios sustituye la configuración del archivo Web.config de los directorios principales. Además, la configuración de Web.config también sustituye a la de Machine.config.

Puede bloquear la configuración 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 configuración de niveles inferiores reemplacen la configuración especificada en el elemento <location>. La capacidad de bloquear la configuración puede aplicarse a todos los tipos de configuración, no sólo a la configuración de seguridad de los modos de autenticación.

Impedir que se descarguen los archivos

Puede utilizar la clase HttpForbiddenHandler para evitar que se descarguen algunos tipos de archivos a través del Web. Esta clase la utiliza internamente ASP.NET para evitar la descarga de algunos archivos de sistema (como por ejemplo los archivos de configuración, incluido el archivo Web.config). Si desea obtener una lista completa de los tipos de archivos que presentan este tipo de restricciones, consulte la sección <httpHandlers> del archivo Machine.config.

Considere la posibilidad de utilizar HttpForbiddenHandler para los archivos que la aplicación utiliza internamente pero que no se han concebido para la descarga.

Nota: también debería proteger los archivos mediante listas ACL de Windows a fin de poder controlar los usuarios que obtienen acceso a los archivos cuando inician una sesión en el servidor Web.

Para utilizar HttpForbiddenHandler con el fin de evitar la descarga de un determinado tipo de archivo

1. Cree una asignación de aplicación en IIS para el tipo de archivo en cuestión y asígnela a Aspnet_isapi.dll.

a. En la barra de tareas, haga clic en el botón Inicio, seleccione Programas, Herramientas administrativas y, finalmente, seleccione Servicios de Internet Information Server.

b. Seleccione el directorio virtual de la aplicación, haga clic con el botón secundario del mouse (ratón) y haga clic en Propiedades.

c. Seleccione Configuración de la aplicación y haga clic en Configuración.

d. Haga clic en Agregar para crear una nueva asignación de aplicaciones.

e. Haga clic en Examinar y seleccione c:\winnt\Microsoft.NET\Framework\v1.0.3705\aspnet_isapi.dll.

f. Escriba la extensión de archivo correspondiente al tipo de archivo cuya descarga desee evitar (por ejemplo, .abc) en el campo Extensión.

g. Compruebe que estén seleccionadas las opciones Todos los verbos y Motor de secuencias de comandos y que la opción Comprobar que existe el archivo esté seleccionada.

h. Haga clic en Aceptar para cerrar el cuadro de diálogo Agregar/Modificar asignación de extensión de aplicación.

i. Haga clic en Aceptar para cerrar el cuadro de diálogo Configuración de la aplicación y, a continuación, haga clic en Aceptar para cerrar el cuadro de diálogo Propiedades.

2. Agregue una asignación <HttpHandler> al archivo Web.config para el tipo de archivo especificado.A continuación encontrará un ejemplo para el tipo de archivo .abc.

<httpHandlers>

<add verb="*" path="*.abc"

type="System.Web.HttpForbiddenHandler"/>

</httpHandlers>

Comunicación seguraUtilice una combinación de SSL y la Seguridad del protocolo de Internet (IPSec) para proteger la seguridad de los vínculos de comunicación.

Más información● Para obtener más información acerca de cómo utilizar SSL para proteger el

vínculo con el servidor de bases de datos, consulte "Cómo utilizar SSL para proporcionar comunicaciones seguras con SQL Server 2000."

● Para obtener información acerca de cómo utilizar IPSec entre dos equipos, consulte "Cómo utilizar IPSec para garantizar una comunicación segura entre dos servidores."

Programar la seguridadUna vez establecida la configuración de seguridad configurable de la aplicación Web, deberá mejorar y ajustar la directiva de autorización de la aplicación Web mediante programación. Este proceso incluye atributos .NET declarativos de los ensamblados y la ejecución de comprobaciones de autorización imperativas del código.

Esta sección describe los pasos básicos de programación necesarios para llevar a cabo la autorización en una aplicación Web ASP.NET.

Un modelo de autorizaciónA continuación se describe brevemente el modelo básico para la autorización de usuarios en la aplicación 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 autorización en función de la identidad del usuario o la pertenencia a funciones

Importante: los pasos 1 a 5 los ejecuta automáticamente ASP.NET si se ha configurado la autenticación de Windows. En el caso de utilizar otros mecanismos de autenticación (mediante Formularios, de Passport o personalizado) es preciso escribir el código pertinente para llevar a cabo estos pasos, tal como se describe a continuación.

Recuperar credenciales

Debe empezarse por recuperar un conjunto de credenciales (nombre de usuario y contraseña) del usuario. Si la aplicación no utiliza la autenticación de Windows, deberá comprobar que se garantice correctamente la seguridad de las credenciales de texto no cifrado en la red a través de SSL.

Validar credenciales

En caso de haber configurado la autenticación de Windows, las credenciales se validarán automáticamente mediante los servicios subyacentes.

Si utiliza un mecanismo de autenticación distinto, deberá escribir el código pertinente para validar las credenciales con un almacén de datos tal como una base de datos SQL Server o Active Directory.

Si desea obtener más información acerca de cómo 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 capítulo 12, "Seguridad del acceso a datos".

Incluir usuarios en las funciones

El almacén de datos de usuario también debería incluir una lista de las funciones de cada usuario. Es preciso escribir el código adecuado para recuperar la lista de funciones del usuario validado.

Crear un objeto IPrincipal

La autorización 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 autenticación de Windows, ASP.NET creará automáticamente un objeto WindowsPrincipal. Dicho objeto contiene la identidad del usuario autenticado además de una lista de funciones, que equivale a la lista de grupos de Windows a los que pertenece el usuario.

Si utiliza la autenticación mediante Formularios, de Passport o un mecanismo personalizado, deberá escribir el código necesario en el controlador de eventos Application_AuthenticateRequest de Global.asax para crear un objeto IPrincipal. .NET Framework proporciona la clase GenericPrincipal, que debería utilizarse en la mayoría 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 automáticamente cuando se utiliza la autenticación de Windows. De lo contrario, deberá adjuntar el objeto de forma manual.

Ejecutar la autorización en función de la identidad del usuario o la pertenencia a funciones

Utilice las funciones de .NET de forma declarativa (para obtener la autorización de clases o métodos) o imperativa en el código si la aplicación requiere una lógica de autorización de mayor granularidad.

Puede utilizar las peticiones de permisos principales declarativas o imperativas (mediante la clase PrincipalPermission), o bien ejecutar las comprobaciones de funciones explícitas llamando al método IPrincipal.IsInRole().

El siguiente ejemplo presupone que se utiliza la autenticación de Windows y esboza una petición declarativa de permisos principales. El método que transfiere el atributo sólo 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 excepción SecurityException.


Role=@"DomainName\Manager")]

public void SomeMethod()

{

}

El siguiente ejemplo muestra una comprobación de función del código explícita. El ejemplo asume que se utiliza la autenticación de Windows. En caso de utilizarse un mecanismo de autenticación distinto de Windows, el código sigue siendo similar. En vez de convertir el objeto User a un objeto WindowsPrincipal, debería 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

}

Más información

Si desea conocer un caso práctico de implementación del modelo descrito para la autenticación mediante Formularios, consulte la sección "Autenticación mediante Formularios" que figura más adelante en este mismo capítulo.

Crear una clase IPrincipal personalizada.NET Framework proporciona la clase GenericPrincipal que debería utilizarse en la mayoría de los escenarios que recurren a un mecanismo de autenticación distinto de Windows. Esta clase permite ejecutar comprobaciones de funciones a través del método IPrincipal.IsInRole.

En algunas ocasiones quizás resulte necesario implementar una clase IPrincipal propia. Algunos de los motivos para implementar una clase IPrincipal propia:

● Se desean ampliar las funciones para la comprobación de funciones. Quizás desee utilizar métodos que permitan comprobar si un determinado usuario es miembro de varias funciones. Por ejemplo:

CustomPrincipal.IsInAllRoles( "Role", "Role2", "Role3" )

CustomPrincipal.IsInAnyRole( "Role1", "Role2", "Role3" )

● Quizás desea implementar un método o propiedad adicional que devuelva una lista de funciones en una matriz. Por ejemplo:

string[] roles = CustomPrincipal.Roles;

● Desea que la aplicación fuerce la lógica jerárquica de funciones. Por ejemplo, un director general se sitúa en un lugar de la jerarquía superior al que ocupa un director ejecutivo. Esta diferencia puede comprobarse con ayuda de métodos como los que se indican a continuación.

CustomPrincipal.IsInHigherRole("Manager");

CustomPrincipal.IsInLowerRole("Manager");

● Desea implementar una inicialización lenta de las listas de funciones. Por ejemplo, quizás desee cargar de forma dinámica la lista de funciones sólo cuando se solicite una comprobación de función.

● 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;

Más información

Para obtener más información acerca de cómo crear una clase IPrincipal propia, consulte "Cómo implementar una clase IPrincipal personalizada" en la sección de referencia de este manual.

Autenticación de WindowsUtilice la autenticación de Windows cuando los usuarios de la aplicación dispongan de cuentas de Windows que pueda autenticar el servidor (por ejemplo, en escenarios de intranets).

Si configura ASP.NET para la autenticación de Windows, IIS realizará la autenticación de los usuarios mediante el mecanismo de autenticación configurado de IIS. La ilustración 8.4 refleja este escenario.

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

Ilustración 8.4La autenticación de Windows en ASP.NET utiliza IIS para autenticar a los llamadores

El testigo de acceso del llamador autenticado (que puede ser la cuenta anónima de usuario de Internet si se ha configurado IIS para la autenticación anónima) se pone a disposición de la aplicación 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 autorización de archivos de ASP.NET realiza comprobaciones de acceso con los tipos de archivo que se hayan asignado a la extensión Aspnet_isapi.dll.

● La autorización de archivos no exige suplantación. Cuando esté habilitada la suplantación, cualquier acceso que efectúe la aplicación 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 mínimo, 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 además de una lista de funciones de las que es miembro el usuario. En el caso de la autenticación de Windows, la lista de funciones consta de un conjunto de grupos de Windows a los que pertenece el usuario.

El siguiente fragmento de código muestra cómo obtener la identidad del usuario de Windows autenticado y cómo llevar a cabo una comprobación de funciones simple para la autorización.

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

}

Autenticación mediante FormulariosLa ilustración 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 autenticación mediante Formularios (contexto en el que la autorización mediante direcciones URL deniega el acceso de usuario).

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

Ilustración 8.5Secuencia de eventos de la autenticación mediante Formularios

A continuación se describe la secuencia de eventos esbozada en la ilustración 8.5.

1. El usuario envía una solicitud Web para Default.aspx.IIS permite la solicitud porque está activado el acceso anónimo. ASP.NET comprueba los elementos <authorization> y busca un elemento <deny users=?” />.

2. El usuario se redirige a la página de inicio de sesión (Login.aspx), tal como se especifica en el atributo LoginUrl del elemento <forms>.

3. El usuario proporciona las credenciales y envía el formulario de inicio de sesión.

4. Se validan las credenciales con un almacén (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 autorización basada en funciones.

5. Se crea una cookie mediante FormsAuthenticationTicket y se envía 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 redirección del cliente a la página 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 autenticación mediante FormulariosLa lista que figura a continuación destaca los pasos básicos que deben efectuarse para implementar la autenticación mediante Formularios:

1. Configurar IIS para el acceso anónimo

2. Configurar ASP.NET para la autenticación mediante Formularios

3. Crear un formulario Web de inicio de sesión y validar las credenciales suministradas

4. Recuperar una lista de funciones del almacén de datos personalizado

5. Crear un vale de autenticación 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 función del nombre de usuario o la pertenencia a funciones

Configurar IIS para el acceso anónimo

El directorio virtual de la aplicación debe configurarse en IIS para el acceso anónimo.

Para configurar IIS para el acceso anónimo

1. Inicie la herramienta de administración Servicios de Internet Information Server.

2. Seleccione el directorio virtual de la aplicación, haga clic con el botón secundario del mouse (ratón) y haga clic en Propiedades.

3. Haga clic en Seguridad de directorios.

4. En el grupo Control de autenticación y acceso anónimo, haga clic en Modificar.

5. Seleccione Acceso anónimo.

Configurar ASP.NET para la autenticación mediante Formularios

A continuación se incluye un fragmento de código de muestra.


<forms name="MyAppFormsAuth"

loginUrl="login.aspx"

protection="Encryption"

timeout="20"

path="/" >

</forms>

</authentication>

Crear un formulario Web de inicio de sesión y validar las credenciales suministradas

La validación de las credenciales debe efectuarse con una base de datos SQL Server o Active Directory.

Más información

● Consulte "Cómo utilizar la autenticación mediante Formularios con SQL Server 2000" en la sección de referencia de este manual.

● Consulte "Cómo utilizar la autenticación mediante Formularios con Active Directory" en la sección de referencia de este manual.

Recuperar una lista de funciones del almacén de datos personalizado

Las funciones deben obtenerse de una tabla de base de datos SQL Server, o bien grupos/listas de distribución configuradas en Active Directory. Consulte los recursos anteriores para obtener información más detallada.

Crear un vale de la autenticación mediante Formularios

Las funciones recuperadas se almacenan en el vale. El siguiente fragmento de código 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, // version

txtUserName.Text, // user name

DateTime.Now, // creation

DateTime.Now.AddMinutes(20),// Expiration

false, // Persistent

roles ); // User data

// 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 ));

}

}

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 continuación se incluye el código 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 función del nombre de usuario o la pertenencia a funciones

Utilice peticiones de permisos principales declarativas para restringir el acceso a los métodos. Utilice peticiones de permisos principales imperativas y/o comprobaciones de funciones explícitas (IPrincipal.IsInRole) para llevar a cabo la autorización de granularidad precisa desde los métodos.

Instrucciones para la implementación de Formularios● Utilice SSL para la captura de credenciales mediante un formulario HTML.

Además de utilizar SSL para la página de inicio de sesión, también debería utilizar SSL para otras páginas siempre que las credenciales o la cookie de autenticación se envíen a través de la red. De este modo se reduce la amenaza asociada a los ataques de reproducción de la cookie.

● Autentique a los usuarios con un almacén de datos personalizado. Utilice SQL Server o Active Directory.

● Recupere una lista de funciones del almacén 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 almacén de datos para cada solicitud Web y se evita tener que almacenar las credenciales del usuario en la cookie de autenticación.

● Si la lista de funciones es muy amplia y existe el peligro de sobrepasar el tamaño límite de la cookie, almacene la información 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 efectúe.

● Para cada solicitud y después de realizar la autenticación inicial:

● Recupere las funciones del vale del controlador de eventos Application_AuthenticateRequest.

● Cree un objeto IPrincipal y almacénelo en el contexto HTTP (HttpContext.User). .NET Framework también asocia el objeto al proceso .NET actual (Thread.CurrentPrincipal).

● Utilice la clase GenericPrincipal salvo si precisa crear una implementación IPrincipal personalizada: por ejemplo, para ofrecer compatibilidad con operaciones de funciones mejoradas.

● Utilice dos cookies: una para la personalización y otra para la autenticación y autorización seguras. Establezca el carácter persistente de la cookie de personalización (asegúrese de que no contiene información que pudiese permitir a una solicitud ejecutar una operación restringida como, por ejemplo, incluir una orden en una ubicación segura de un sitio).

● Utilice un nombre de cookie (mediante el atributo Forms del elemento <forms>) y una ruta de acceso independientes para cada aplicación Web. Este enfoque permite garantizar que los usuarios que obtienen la autenticación de una aplicación no reciban el trato de usuarios autenticados cuando utilizan una segunda aplicación ubicada en el mismo servidor Web.

● Asegúrese de que las cookies estén habilitadas en los exploradores cliente. Podrá obtener información relativa al enfoque de autenticación mediante Formularios que no precisa cookies en la sección "Autenticación mediante Formularios sin cookies" que figura más adelante en este mismo capítulo.

Más información

● Consulte "Cómo utilizar la autenticación mediante Formularios con SQL Server 2000" en la sección de referencia de este manual.

● Consulte "Cómo utilizar la autenticación mediante Formularios con Active Directory" en la sección de referencia de este manual.

● Consulte "Cómo utilizar la autenticación mediante Formularios con objetos GenericPrincipal" en la sección Referencia de esta guía.

Alojar varias aplicaciones mediante la autenticación mediante FormulariosSi aloja varias aplicaciones Web que utilizan la autenticación mediante Formularios en el mismo servidor Web, los usuarios autenticados por una aplicación podrán enviar una solicitud a otra aplicación sin ser redirigidos a la página de inicio de sesión de dicha aplicación. Las reglas de la autorización mediante direcciones URL de la segunda aplicación pueden denegar el acceso al usuario, sin brindarle la oportunidad de proporcionar las credenciales de inicio de sesión a través del formulario de inicio de sesión.

Estos casos sólo pueden ocurrir si los atributos del nombre y la ruta de acceso del elemento <forms> son idénticos en diversas aplicaciones y si cada aplicación utiliza un elemento <machineKey> común en el archivo Web.config.

Más información

Para obtener más información acerca de este enfoque, y conocer las técnicas de resolución, consulte los siguientes artículos de la Knowledge Base:

● Q313116, "PRB: Forms Authentication Requests Are Not Directed to loginUrl Page" (en inglés).

● Q310415, "PRB: Mobile Forms Authentication and Different Web Applications" (en inglés).

Autenticación mediante Formularios sin cookiesSi necesita una solución de autenticación 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 autenticación mediante Formularios móvil se basa en la autenticación 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 autenticación.

Más información

Para obtener más información acerca de la autenticación mediante Formularios, consulte el artículo Q311568, "INFO: How To Use Mobile Forms Authentication with Microsoft Mobile Internet Toolkit" (en inglés) de la Microsoft Knowledge Base.

Autenticación de PassportUtilice la autenticación de Passport cuando los usuarios de la aplicación dispongan de cuentas de Passport y desee implementar una solución de inicio de sesión único con otros sitios habilitados para Passport.

Cuando ASP.NET se configura para la autenticación de Passport, el sistema solicita al usuario que inicie la sesión y lo redirige al sitio Passport. Después de una validación de credenciales satisfactoria, el usuario se redirige de nuevo al sitio.

Configurar ASP.NET para la autenticación de Passport

Para configurar ASP.NET para la autenticación de Passport, utilice la configuración del archivo Web.config que se indica a continuación.

<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 continuación.

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 código que figura a continuación muestra cómo recuperar la identidad Passport autenticada y cómo comprobar la pertenencia a funciones en una página 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"));

Autenticación personalizadaSi ninguno de los módulos de autenticación suministrados por .NET Framework satisface sus necesidades específicas de autenticación, puede utilizar la autenticación personalizada e implementar un mecanismo de autenticación propio. Por ejemplo, en casos en los que su empresa ya cuenta con una estrategia de autenticación personalizada que utilizan masivamente otras aplicaciones.

Para implementar una autenticación personalizada en ASP.NET:

● Configure el modo de autenticación en el archivo Web.config tal como se muestra a continuación. Este comando notifica a ASP.NET que no invoque ninguno de los módulos de autenticación integrados.

<authentication mode="None" />

● Cree una clase que implemente la interfaz System.Web.IHttpModule para crear un módulo HTTP personalizado. Este módulo debería crear un enlace en el evento HttpApplication.AuthenticateRequest y proporcionar un delegado al que llamar con cada solicitud de la aplicación cuando se precise la autenticación.Un módulo de autenticación debe:

● Obtener las credenciales del llamador

● Validar las credenciales con relación a un almacén

● Cree un objeto IPrincipal y almacenarlo en HttpContext.User

● Crear y proteger un testigo de autenticación y enviarlo de nuevo al usuario (normalmente mediante una cadena de consulta, una cookie o un campo de formulario oculto).

● Obtener el testigo de autenticación en futuras solicitudes, validarlo y volver a enviarlo

Más información

Si desea obtener más información acerca de la implementación de un módulo HTTP personalizado, consulte el artículo Q307996, "HOW TO: Create an ASP.NET HTTP Module Using Visual C# .NET" (en inglés) de la Microsoft Knowledge Base.

Identidad del proceso para ASP.NETEjecute ASP.NET (en especial el proceso de trabajo Aspnet_wp.exe) mediante una cuenta con privilegios mínimos.

Utilizar una cuenta con privilegios mínimosUtilice una cuenta con privilegios mínimos para mitigar la amenaza asociada con la exposición de los procesos. Si un determinado intruso consigue poner en peligro el proceso de ASP.NET que ejecuta la aplicación Web, podría heredar y explotar con

facilidad los privilegios y derechos de acceso concedidos a la cuenta de procesos. Una cuenta configurada con privilegios mínimos reduce los posibles daños.

Evitar la ejecución como SISTEMANo 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 tentación de utilizar dicha cuenta o conceder el privilegio para que el código 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 más adelante en este capítulo.

Entre los motivos para no optar por una ejecución con la cuenta SISTEMA ni para conceder el privilegio “Actuar como parte del sistema operativo” figuran:

● Aumenta considerablemente los daños que puede provocar un intruso cuando el sistema está en peligro, pero no afecta a la capacidad de hallarse en esta situación.

● Convierte en inservible el principio de los privilegios mínimos. La cuenta ASPNET se ha configurado específicamente como una cuenta con privilegios mínimos diseñada para ejecutar aplicaciones Web de ASP.NET.

Más información

Para obtener más información acerca del privilegio "Actuar como parte del sistema operativo", consulte la columna Security Briefs de agosto de 1999 de Microsoft Systems Journal (en inglés).

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, también 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 artículo Q315158, "BUG: ASP.NET Does Not Work with the Default ASPNET Account on a Domain Controller" (en inglés) de la Microsoft Knowledge Base.

Utilizar la cuenta predeterminada de ASPNETLa cuenta local de ASPNET se ha configurado específicamente 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 contraseña segura criptográficamente al instalar .NET Framework. Además de configurarse en la base de datos SAM (Security Account Manager), la contraseña se almacena en la autoridad local del sistema (LSA) del equipo local. El sistema recupera la contraseña de la LSA cada que vez que inicia el proceso de trabajo de ASP.NET.

Si la aplicación obtiene acceso a recursos de red, la cuenta ASPNET debe ser capaz de ser autenticada por el equipo remoto. Existen dos posibilidades:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnmsj99/html/security0899.asp

● Restablecer la contraseña de la cuenta ASPNET con un valor conocido y crear a continuación una cuenta duplicada (con el mismo nombre y la misma contraseña) en el equipo remoto. Este enfoque es la única opción 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 relación 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 autenticación de Windows.

● Cuando se prima la facilidad de administración, debe utilizarse una cuenta de dominio con privilegios mínimos.Para evitar tener que actualizar y sincronizar las contraseñas manualmente, utilice una cuenta de dominio con privilegios mínimos para ejecutar ASP.NET. Resulta fundamental que la cuenta de dominio esté totalmente bloqueada para mitigar la amenaza de exposición 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 serán 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 debería utilizarse para ejecutar el proceso de trabajo de ASP.NET (Aspnet_wp.exe). Existen una serie de opciones para configurar este parámetro. Por ejemplo:

● "machine". El proceso de trabajo se ejecuta como la cuenta ASPNET con privilegios mínimos. La cuenta dispone de acceso a la red pero no puede ser autenticada por ningún 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, además 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 específicas. Cuando suministre las credenciales para userName y password, recuerde el principio de los privilegios mínimos. Si especifica una cuenta local, la aplicación 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 mínimos, asegúrese de que no sea una cuenta con permisos para obtener acceso a más equipos de la red de los necesarios.En .NET Framework versión 1.1 tendrá la posibilidad de almacenar en el registro atributos userName y password cifrados.

Nota: a diferencia de cómo se ejecutan las aplicaciones ASP clásicas, el código ASP.NET nunca se ejecuta en el proceso dllhost.exe o como la cuenta IWAM_MACHINENAME, incluso si el nivel de protección de la aplicación se establece en Alto (Aislado) en IIS.

Las solicitudes de ASP.NET que se envían a IIS se enrutan directamente al proceso de trabajo de ASP.NET (Aspnet_wp.exe). La extensión 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 debería modificarse). La extensión 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 aplicación ofrecen límites de aislamiento.

IIS 6 permitirá aislar las aplicaciones de ASP.NET mediante la configuración de grupos de aplicaciones, configuraciones en las que cada grupo tendrá su propia instancia de aplicación.

Más información

● Si desea obtener más información 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 más adelante en este capítulo.

● Para obtener información detallada acerca de cómo crear una cuenta personalizada para la ejecución de ASP.NET, consulte "Cómo crear una cuenta personalizada para ejecutar ASP.NET" en la sección de referencia de este manual.

SuplantaciónCon la introducción del módulo FileAuthorizationModule, y con el empleo eficaz de los equipos selectores y los límites de confianza, la suplantación puede resultar una desventaja en lugar de una ventaja de ASP.NET.

Suplantación y recursos localesSi utiliza la suplantación y obtiene acceso a los recursos locales desde el código de la aplicación Web, deberá configurar las listas ACL adjuntas a cada recurso seguro para que contenga una ACE que conceda al usuario autenticado, como mínimo, acceso de lectura.

Un enfoque todavía mejor consiste en evitar la suplantación, conceder permisos a la cuenta de proceso de ASP.NET y utilizar la autorización mediante direcciones URL, la autorización de archivos y una combinación de comprobaciones declarativas e imperativas basadas en funciones.

Suplantación y recursos remotosSi se utiliza la suplantación y se obtiene acceso a los recursos remotos desde el código de la aplicación Web, el acceso no resultará satisfactorio salvo que se utilice la autenticación básica, mediante Formularios o Kerberos. Si se utiliza la autenticación Kerberos, las cuentas de usuario deben configurarse correctamente para la delegación. Deben marcarse como “Confidencial y no puede delegarse” en Active Directory.

Más información

Para obtener más información acerca de cómo configurar la delegación Kerberos, consulte:

● "Transmitir el llamador original" en el capítulo 5, "Seguridad de intranet".

● "Cómo implementar la delegación Kerberos para Windows 2000" en la sección de referencia de este manual.

Suplantación y subprocesamientoSi un subproceso que utiliza la suplantación 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 sistemaDe manera predeterminada, ASP.NET no lleva a cabo la suplantación. Como consecuencia, si la aplicación 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 eventosLas cuentas con privilegios mínimos disponen de los permisos necesarios para escribir registros en el registro de eventos con ayuda de los orígenes de eventos existentes. Sin embargo, no cuentan con los permisos suficientes para crear nuevos orígenes de eventos. Para ello es necesaria una nueva entrada que debe ubicarse justo en el nivel inferior del subárbol del registro.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\<log>

Para evitar este problema, cree los orígenes de eventos que utiliza la aplicación durante el proceso de instalación, cuando están 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 implementación .msi) o por la utilidad del sistema InstallUtil.exe si no se utiliza dicha implementación.

Si no puede crear orígenes de eventos durante la instalación, 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 aplicación utiliza la suplantación).

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog

Las cuentas deben tener los siguientes permisos mínimos:

● Consultar los valores de claves

● Establecer valores de claves

● Crear subclave

● Enumerar subclaves

● Notificar

● Lectura

Puede utilizar el siguiente código 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 registroCualquier clave de registro a la que obtenga acceso la aplicación requiere una ACE (entrada de control de acceso) en la lista ACL que concede (como mínimo) acceso de lectura a la cuenta de proceso de ASP.NET.

Más información

Para obtener más información acerca de las clases del instalador y la utilidad InstallUtil.exey, consulte las herramientas de .NET Framework en MSDN.

Obtener acceso a los objetos COMEn ASP común, 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 múltiple). 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 controladoCuando una aplicación 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 página de ASP.NET con la directiva AspCompat, como se muestra a continuación.

<%@ Page Language="C#" AspCompat="True" %>

● No cree los objetos COM fuera de controladores de eventos Page específicos. Créelos siempre en los controladores de eventos Page (como Page_Load y Page_Init). No cree los objetos COM en el constructor de la página.

Obligación 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 utilizaría un subproceso STA).

La especificación de AspCompat provoca que la página 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 aplicación Web utiliza la suplantación, puesto que un cambio de subproceso da lugar a una pérdida del testigo de suplantación. El nuevo subproceso no tendría el testigo de suplantación asociado.

http://msdn.microsoft.com/library/en-us/cptools/html/cpconinstallerutilityinstallutilexe.asp

http://msdn.microsoft.com/library/en-us/cptools/html/cpconinstallerutilityinstallutilexe.asp

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 código de un servicio Web, se produce un cambio de subproceso y se pierde el testigo de suplantación del subproceso. Como consecuencia suele generarse una excepción de acceso denegado.

Más información

● Consulte los artículos de la Knowledge Base que se indican a continuación para obtener más información:

● Artículo Q303375, "INFO: XML Web Services and Apartment Objects" (en inglés)

● Artículo Q325791, "PRB: Access Denied Error Message Occurs When Impersonating in ASP.NET and Calling STA COM Components" (en inglés)

● Si desea obtener más información acerca de cómo determinar la identidad del código que se esté ejecutando actualmente, consulte la sección "¿Quién soy?" del capítulo 13, “Resolución de problemas."

No cree los objetos COM fuera de controladores de eventos Page específicos

No cree los objetos COM fuera de controladores de eventos Page específicos. El siguiente fragmento de código muestra lo que no debería hacerse.


<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 específicos como Page_Load, tal como se indica a continuación.


<script runat="server">

public void Page_Load()

{

YourComObject obj = new apartmentObject();

obj.Foo()

}

</script>

Más información

Para obtener más información, consulte el artículo Q308095, "PRB: Creating STA Components in the Constructor in ASP.NET ASPCOMPAT Mode Negatively Impacts Performance" (en inglés) 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 ningún cambio de subproceso.

Obtener acceso a recursos de redEs posible que la aplicación necesite obtener acceso a recursos de red. En este sentido, resulta importante identificar:

● Los recursos a los que necesita obtener acceso la aplicación.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 aplicación obtiene acceso a recursos remotos, los equipos remotos deben poder ser capaces de autenticar dicha identidad.

Nota: si desea obtener información específica acerca de cómo obtener acceso a las bases de datos SQL Server, consulte el capítulo 12, "Seguridad del acceso a datos."

El acceso a los recursos remotos desde una aplicación ASP.NET puede realizarse mediante cualquiera de las técnicas que se detalla acto seguido:

● Utilizar la identidad de proceso de ASP.NET

● Utilizar un componente revisado

● Utilizar una cuenta de usuario de Internet anónimo (como, por ejemplo, IUSR_MACHINE)

● Utilizar la API LogonUser y la suplantación para una identidad de Windows específica

● Utilizar el llamador original

Utilizar la identidad del proceso ASP.NETCuando la aplicación no está configurada para la suplantación, la identidad del proceso ASP.NET proporciona la identidad predeterminada cuando la aplicación 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 más simple. Debe crearse una cuenta local con un nombre de usuario y contraseña coincidentes en el equipo remoto. Es necesario cambiar la contraseña de la cuenta ASP.NET del administrador de usuarios con un valor conocido (utilice siempre una contraseña segura). A continuación, establézcala explícitamente en el elemento <processModel> del archivo Machine.config y sustituya el valor "AutoGenerate" existente.

Importante: si cambia la contraseña ASPNET por un valor conocido, la contraseña de LSA dejará de coincidir con la contraseña de la cuenta SAM. Si necesita recuperar el valor predeterminado "AutoGenerate", siga uno de los siguientes pasos:

Ejecute Aspnet_regiis.exe para restablecer la configuración predeterminada de ASP.NET. Para obtener más información, consulte el artículo Q306005, "HOWTO: Repair IIS Mapping After You Remove and Reinstall IIS" (en inglés) de la Microsoft Knowledge Base.

● Cree una cuenta local personalizada con privilegios mínimos para ejecutar ASP.NET y cree una cuenta duplicada en el equipo remoto.

● Ejecute ASP.NET mediante una cuenta de dominio con privilegios mínimos. Este comportamiento asume que los equipos cliente y servidor se hallan en los mismos dominios de confianza.

Más información

Para obtener más información acerca de cómo configurar una cuenta de proceso ASP.NET, consulte "Cómo crear una cuenta personalizada para ejecutar ASP.NET" en la sección de referencia de este manual.

Utilizar un componente revisadoPuede 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 ilustración 8.6.

{Insert figure: Network Access with Serviced Components.gif}

Ilustración 8.6Uso 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 aplicación servidor de Servicios Empresariales) reporta los siguientes beneficios:

http://support.microsoft.com/default.aspx?scid=kb;en-us;Q306005

● Flexibilidad en términos de la identidad utilizada. No se confía únicamente en la identidad ASP.NET.

● Posibilidad de aislar el código de confianza o con mayores privilegios de la aplicación Web principal.

● Un salto de proceso adicional aumenta el nivel desde el punto de vista de la seguridad. Así resulta más difícil que un intruso pueda cruzar el límite del proceso y pasar a un proceso con privilegios aumentados.

● Si necesita combinar la suplantación manual con llamadas a la API LogonUser, lo puede hacer en un proceso independiente de la aplicación 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 aplicación Web es un problema de seguridad menor.

Utilizar la cuenta anónima de usuario de InternetPuede utilizar la cuenta anónima de usuario de Internet para obtener acceso a los recursos de red si IIS está configurado para la autenticación anónima. Éste es el caso si se da alguna de estas dos condiciones:

● La aplicación es compatible con el acceso anónimo.

● La aplicación utiliza la autenticación mediante Formularios, de Passport o personalizada (cuando IIS está configurado para el acceso anónimo).

Para utilizar la cuenta anónima para el acceso a recursos remotos

1. Configure IIS para la autenticación anónima. Puede configurar el modo de autenticación de ASP.NET en Windows, mediante Formularios, Passport o ninguna en función de los requisitos de autenticación de la aplicación.

2. Configure ASP.NET para la suplantación. Utilice la siguiente configuración del archivo Web.config:


3. Configure la cuenta anónima como una cuenta de dominio con privilegios mínimos.- O bien -

Duplique la cuenta anónima mediante el mismo nombre de usuario y contraseña del equipo remoto. Este enfoque resulta necesario cuando se realizan llamadas a través de dominios que no son de confianza o de servidores de seguridad que no tienen abiertos los puertos necesarios para ofrecer compatibilidad con la autenticación de Windows.

Para garantizar la compatibilidad con este enfoque también es preciso:

a. Utilizar el Administrador de servicios de Internet para desactivar la casilla de verificación Permitir que IIS controle la contraseña para la cuenta anónima.Si selecciona esta opción, la sesión de inicio creada con la cuenta anónima 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 opción, la sesión de inicio será una sesión 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 suplantación para la cuenta anónima (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 aplicación deben disponer de acceso de lectura (como mínimo) a la cuenta anónima. El resto de los recursos deberían denegar el acceso a la cuenta anónima.

Alojar varias aplicaciones Web

Puede utilizar una cuenta anónima de usuario de Internet para cada raíz virtual del sitio Web. En un entorno alojado, este enfoque permite realizar por separado tareas como autorizar, realizar un seguimiento y efectuar auditorías de solicitudes que se originan en aplicaciones Web independientes. Este enfoque queda reflejado en la ilustración 8.7.

{Insert figure: CH08 - ASPNET Impersonation - Multiple Anon Accounts.gif}

Ilustración 8.7Suplantación de cuentas anónimas de usuario de Internet independientes para cada aplicación (v-dir)

Para configurar la cuenta anónima de usuario de Internet para un directorio virtual específico

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 botón secundario del mouse (ratón) y haga clic en Propiedades.

3. Haga clic en la pestaña Seguridad de directorios.

4. Haga clic en la opción Modificar del grupo Control de autenticación y acceso anónimo.

5. Seleccione Acceso anónimo y, a continuación, haga clic en Modificar.

6. Escriba el nombre de usuario y la contraseña de la cuenta que desee que utilice IIS cuando los usuarios anónimos se conecten al sitio.

7. Asegúrese de que la opción Permitir que IIS controle la contraseña NO esté seleccionada.

Utilizar la API LogonUser y la suplantación para una identidad de Windows específicaSe puede suplantar una identidad específica mediante la configuración de los atributos de nombre de usuario y contraseña del elemento <identity> del archivo Web.config, o bien llamando la API LogonUser de Win32® desde el código de la aplicación.

Importante: estos enfoques no son recomendables. Deberían 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 aplicación Web.

Esta restricción dejará de existir en Windows Server 2003.

Utilizar el llamador originalPara 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 aplicación mediante la identidad suplantada del llamador original, se producirá un efecto importante en la capacidad de escalabilidad de la aplicación debido a que la agrupación 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 autenticación que se indican acto seguido son compatibles con la delegación:

● Kerberos. Si desea obtener más información, consulte "Cómo implementar la delegación Kerberos para Windows 2000" en la sección de referencia de este manual.

● Certificados de cliente asignados a cuentas de Windows. La asignación debe llevarla a cabo IIS.

● Básica. La autenticación básica es compatible con el acceso a los recursos remotos porque las credenciales del llamador original están disponibles en formato de texto sin cifrar en el servidor Web. Además, pueden utilizarse para responder a los desafíos de autenticación de los equipos remotos.Debe recurrirse a la autenticación básica cuando se utilice una sesión interactiva o de inicio de sesión por lotes. El tipo de sesión de inicio resultante de la autenticación básica puede configurarse en la metabase de IIS. Si desea obtener más información, consulte el artículo Platform SDK: Internet Information Services 5.1 (en inglés) en MSDN.

Importante: la autenticación básica constituye el enfoque menos seguro de todos los compatibles con la delegación. El motivo es la transferencia del nombre de usuario y la contraseña en formato de texto sin cifrar del explorador al servidor a través de la red y su almacenamiento en la caché del servidor Web. Puede utilizar SSL para proteger las credenciales durante su transferencia, pero debería 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

http://msdn.microsoft.com/library/en-us/iisref/html/psdk/asp/apro1zms.asp?frame=true

http://msdn.microsoft.com/library/en-us/iisref/html/psdk/asp/apro1zms.asp?frame=true

1. Configure IIS para la autenticación de Windows integrada (Kerberos), mediante certificados (con asignación de certificados de IIS) o básica.

2. Configure ASP.NET para la autenticación de Windows y la suplantación.

<authentication mode="Window" />


3. Si utiliza la delegación Kerberos, configure las cuentas de Active Directory para la delegación.

Más información

● Para obtener más información acerca de la configuración de la delegación Kerberos, consulte "Cómo implementar la delegación Kerberos para Windows 2000" en la sección de referencia de este manual.

● Si desea obtener más información acerca de la asignación de certificados IIS, consulte http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/ad/windows2000/howto/mapcerts.asp. (en inglés)

● Para obtener más información acerca de la suplantación de ASP.NET, consulte el artículo .NET Framework Developers Guide (en inglés) de MSDN.

Obtener acceso a archivos de un recurso compartido de archivos UNCSi su aplicación necesita obtener acceso a archivos de un recurso compartido de archivos UNC (Convención de nomenclatura universal) mediante ASP.NET, es importante agregar permisos NTFS a la carpeta de recurso compartido. También deberá establecer los permisos del recurso compartido para conceder como mínimo acceso de lectura a la cuenta de proceso ASP.NET o a la identidad suplantada (si la aplicación se ha configurado para la suplantación).

Obtener acceso a recursos de red distintos de WindowsSi la aplicación 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 límites de confianza asociados al recurso.

● Las credenciales necesarias para la autenticación.

● Necesidad de que el recurso conozca la identidad del llamador original o si la aplicación que efectúa 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 quizás necesite implementar una agrupación de conexiones; por ejemplo, mediante la función de agrupación de objetos de Servicios Empresariales.

Si el recurso necesita poder autenticar el llamador original (y no existe la opción de autenticación de Windows), dispondrá de las siguientes opciones:

● Pasar las credenciales mediante parámetros (llamada de método).

● Pasar las credenciales de una cadena de conexión. Utilice SSL o IPSec para proteger las credenciales de texto sin cifrar que se transfieren a través de la red.Almacene las credenciales de forma segura en la aplicación, por ejemplo mediante DPAPI. Para obtener más información acerca de cómo almacenar de forma segura cadenas de conexión a bases de datos, consulte "Almacenar

http://msdn.microsoft.com/library/en-us/cpguide/html/cpconaspnetimpersonation.asp

cadenas de conexión a bases de datos de forma segura" en el capítulo 12, "Seguridad del acceso a datos".

● Utilice un almacén de datos centralizado para la autenticación al que puedan obtener acceso ambas plataformas; por ejemplo, un directorio LDAP.

Comunicación seguraUtilice SSL para proteger el enlace de comunicación 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.

Más información

Para obtener más información acerca de la comunicación segura, consulte el capítulo 4, "Comunicación segura".

Almacenar secretosEs 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 escrúpulos no deberían poder ver información privilegiada. Por ejemplo, el administrador del servidor Web no debería poder leer la contraseña de una cuenta de inicio de sesión 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 configuración, el secreto del archivo no debería incluirse en texto sin cifrar.

A continuación figuran algunos ejemplos habituales de secretos:

● Cadenas de conexión de SQL. Un error habitual consiste en almacenar el nombre de usuario y la contraseña en formato de texto sin cifrar. Por ello, es recomendable utilizar la autenticación de Windows en vez de la autenticación de SQL. Si no puede utilizar la autenticación de Windows, consulte las siguientes secciones del capítulo 12, "Seguridad del acceso a datos," que constituyen alternativas seguras:

● "Almacenar cadenas de conexión a bases de datos de forma segura"

● "Comunicación segura"

● Credenciales utilizadas para las funciones de aplicación de SQL. Las funciones de aplicación de SQL deben activarse con un procedimiento almacenado que precisa el nombre de la función y la contraseña asociada. Para obtener más información, consulte la sección "Autorización" del capítulo 12, "Seguridad del acceso a datos".

● Identidades fijas de Web.config. Por ejemplo:

<identity impersonate=”true” userName="bob" password="inClearText"/>

En .NET Framework versión 1.1, ASP.NET ofrecerá la posibilidad de cifrar el nombre de usuario y la contraseña 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 contraseña "AutoGenerate".

En .NET Framework versión 1.1, ASP.NET ofrecerá la posibilidad de cifrar el nombre de usuario y la contraseña 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 sección de configuración personalizada que utilice un cifrado asimétrico para cifrar una clave de sesión. La clave de sesión puede almacenarse en un archivo de configuración.

● Estado de sesión de SQL Server. Para utilizar SQL Server para administrar el estado de sesión de la aplicación Web de ASP.NET, utilice la siguiente configuración 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 información.

● Contraseñas utilizadas para la autenticación mediante Formularios con una base de datos. Si su aplicación valida las credenciales de autenticación con una base de datos, no almacene las contraseñas en la base de datos. Utilice un algoritmo hash de la contraseña con un valor salt y compare los hash.

Para obtener más información, consulte "Autenticar usuarios en una base de datos" en el capítulo 12, "Seguridad del acceso a datos".

Opciones para almacenar secretos en ASP.NETLos desarrolladores de aplicaciones Web .NET tienen a su disposición una serie de enfoques distintos para almacenar secretos. Entre dichos módulos figuran:

● Clases de criptografía 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 protección 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 contraseña del usuario. El uso de DPAPI permite poder despreocuparse de la administración de claves. Es el sistema operativo el que administra la clave, que es la contraseña del usuario.

● Cadenas constructoras COM+. Si la aplicación utiliza componentes revisados, puede almacenar el secreto en una cadena de construcción de objetos. La cadena se almacena en el catálogo 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.

Más información

Si desea obtener más información, consulte la entrada de Cryptography, CryptoAPI and CAPICOM (en inglés) en la Platform SDK de MSDN.

Posibilidad de almacenar secretos en archivos de volúmenes lógicos independientesPlantéese la posibilidad de instalar directorios de aplicaciones Web en volúmenes lógicos 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 volúmenes lógicos independientes de los directorios de la aplicación Web.

La lógica de este enfoque consiste en evitar la posible canonización y errores transversales de directorio debido a:

● Errores de canonización de archivos que pueden exponer los archivos de las carpetas de la aplicación Web.

Nota: las rutinas de canonización de archivos recuperan la forma canónica 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 lógico.

Todavía no se han publicado errores de este tipo que hayan expuesto los archivos de otros volúmenes lógicos.

Proteger los estados de sesión y vistaLas aplicaciones Web deben administrar varios tipos de estados, incluidos el estado de vista y el estado de sesión. En esta sección se describe la administración segura de estados para las aplicaciones Web de ASP.NET.

Proteger el estado de vistaSi la aplicación Web de ASP.NET utiliza el estado de vista:

● Garantice la integridad del estado de vista (para garantizar que no se vea alterado de ningún modo durante la transferencia) estableciendo enableViewStateMac en el valor true, tal como se indica a continuación. De este modo, ASP.NET genera un código MAC (Message Authentication Code) en el estado de vista de la página 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 validación de los datos. Tenga en cuenta las siguientes consideraciones:

● El algoritmo hash seguro 1 (SHA1) genera un tamaño de hash superior al de Message Digest 5 (MD5), por lo que se considera más seguro. Sin embargo, el estado de vista protegido mediante SHA1 o MD5 puede

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/security/Security/cryptography_cryptoapi_and_capicom.asp

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/security/Security/cryptography_cryptoapi_and_capicom.asp

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 cookiesLas cookies que contienen datos de autenticación o autorización, o cualquier otro tipo de datos importantes, deberían protegerse mediante SSL para las transferencias. La autenticación mediante Formularios permite utilizar el método FormsAuthentication.Encrypt para cifrar el vale de autenticación, que se transfiere del cliente al servidor por medio de una cookie.

Proteger el estado de sesión de SQLEl controlador de estado de sesión de ASP.NET predeterminado (en proceso) presenta algunas limitaciones. Por ejemplo, no puede funcionar entre varios equipos de baterías de servidores Web. Para superar esta limitación, ASP.NET permite almacenar los estados de sesión en una base de datos SQL Server.

El estado de sesión de SQl puede configurarse en los archivos Machine.config o Web.config. A continuación se muestra la configuración 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 sesión de SQL se instala en:

C:\WINNT\Microsoft.NET\Framework\v1.0.3705

El uso del estado de sesión de SQL provoca dos problemas:

● Debe protegerse la cadena de conexión a la base de datos.

● Debe protegerse el estado de sesión durante su transferencia por la red.

Proteger la cadena de conexión a bases de datos

Si utiliza la autenticación de SQL para conectarse al servidor, la información del Id. del usuario y la contraseña se almacena en el archivo Web.config en formato de texto sin cifrar, como se muestra a continuación:

<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 configuración. Sin embargo, cualquier usuario que disponga de acceso directo a las carpetas que almacenan los archivos de configuración puede ver el nombre de usuario y la contraseña. Por ello, resulta más aconsejable utilizar la autenticación de Windows en vez de la autenticación de SQL.

Para utilizar la autenticación 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 contraseña) en la base de datos del servidor.

2. Cree un inicio de sesión SQL para la cuenta.

3. Cree un usuario de base de datos nuevo en la base de datos ASPState y asígnele el inicio de sesión SQL.La base de datos ASPState se crea con la secuencia de comandos InstallSQLState.sql.

5. Cree una nueva función de base de datos definida por el usuario y agregue el usuario de base de datos a la función.

6. Configure permisos de la base de datos para la función de base de datos.

Si lo desea, puede cambiar la cadena de conexión para utilizar una conexión de confianza, como se muestra acto seguido:

sqlConnectionString="server=127.0.0.1;

database=StateDatabase;

Integrated Security=SSPI;"

Proteger el estado de sesión en la red

Quizás necesite proteger el estado de sesión durante su transferencia a través 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 físicamente en un entorno de confianza, es posible que pueda prescindir de esta medida de seguridad adicional.

Puede utilizar IPSec para proteger todo el tráfico IP existente entre los servidores Web y SQL Server; asimismo, también puede utilizar SSL para proteger el enlace con SQL Server. Este enfoque ofrece la opción de cifrar únicamente la conexión utilizada para el estado de sesión, no todo el tráfico que fluye entre los equipos.

Más información

● Para obtener más información acerca de cómo configurar el estado de sesión de SQL, consulte el artículo Q317604, "HOW TO: Configure SQL Server to Store ASP.NET Session State" (en inglés) en la Microsoft Knowledge Base.

● Para obtener más información acerca de cómo utilizar SSL para SQL Server, consulte "Cómo utilizar SSL para proporcionar comunicaciones seguras con SQL Server 2000" en la sección de referencia de este manual.

● Para obtener más información acerca del uso de IPSec, consulte "Cómo utilizar IPSec para garantizar una comunicación segura entre dos servidores" en la sección de referencia de este manual.

Consideraciones acerca de las baterías de servidores Web

Los escenarios de baterías de servidores Web no ofrecen garantía de que solicitudes sucesivas de un mismo cliente reciban servicio del mismo servidor Web. Esto podría

tener implicaciones para la administración del estado y para cualquier cifrado que se base en los atributos del elemento <machineKey> del archivo Machine.config.

Estado de sesiónEl control de estados de sesión 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 baterías de servidores Web. Las implementaciones de baterías 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 aplicación no es de confianza para almacenar los contadores globales o los valores exclusivos de escenarios de baterías de servidores Web (la aplicación Web configurada para ejecutarse en varios servidores) o bosque Web (aplicación Web configurada para ejecutarse en varios procesadores) porque el estado de la aplicación no se puede compartir entre varios procesos o equipos.

DPAPIDPAPI puede funcionar bien con el almacén del equipo o del usuario (que requiere un perfil de usuario cargado). Si utiliza DPAPI con el almacén del equipo, la cadena cifrada es específica 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 batería de servidores Web o clúster.

Si se utiliza DPAPI con el almacén del usuario, puede descifrar los datos en cualquier equipo que disponga de un perfil de usuario itinerante.

Más información

Para obtener más información acerca de DPAPI, consulte el capítulo 12, "Seguridad del acceso a datos."

Utilizar la autenticación mediante Formularios en una batería de servidores WebSi utiliza la autenticación mediante Formularios, resulta fundamental que todos los servidores de la batería de servidores Web compartan una clave de equipo, que se utiliza para el cifrado, descifrado y la validación del vale de autenticación.

La clave de equipo se almacena en el elemento <machineKey> del archivo Machine.config. Se muestra la configuración predeterminada a continuación.

<machineKey validationKey="AutoGenerate"

decryptionKey="AutoGenerate"

validation="SHA1"/>

Esta configuración provoca que cada equipo genere una clave de validación y descifrado distinta. Es necesario cambiar el elemento <machineKey> e incluir valores de clave comunes en todos los servidores de la batería 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 autenticación mediante Formularios y del estado de vista.

Cuando se llaman los métodos 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 códigos MAC del estado de vista y los vales de autenticación mediante Formularios. El atributo de validación determina el algoritmo que debe utilizarse para la creación del código MAC. Tenga en cuenta las siguientes consideraciones:

● Al utilizar la autenticación mediante Formularios, esta clave funciona junto con el atributo <forms> protection. Si se establece el atributo de protección en Validation y se llama el método FormsAuthentication.Encrypt, se utilizarán el valor del vale y validationKey para calcular el código MAC que debe adjuntarse a la cookie. Cuando se llama el método FormsAuthentication.Decrypt, el código MAC se calcula y compara con el código 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 código 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 código 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 autenticación 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 autenticación 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 métodos 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 envía 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 validación, el cifrado o el descifrado. Puede adoptar los valores SHA1, MD5 o 3DES. Dichos valores se describen a continuación:

● SHA1. El algoritmo HMACSHA1 se utiliza cuando la configuración 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 aceptación por su mayor tamaño de compendio en comparación 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 validación se establece en 3DES, no se utiliza para la autenticación mediante Formularios. En ese caso se utiliza SHA1.

Más información

● Si desea obtener más información acerca de cómo crear las claves adecuadas e incluirlas en el archivo Machine.config, consulte el artículo Q312906, "HOW TO: Create Keys w/ C# .NET for Use in Forms Authentication" (en inglés) de la Microsoft Knowledge Base.

● Para obtener más información acerca del paquete de cifrado alto de Windows 2000, consulte http://www.microsoft.com/windows2000/downloads/recommended/encryption/ (en inglés).

ResumenEn este capítulo se describen una serie de técnicas y enfoques para la protección de aplicaciones Web de ASP.NET. Muchos de los consejos y las recomendaciones de este capítulo también pueden resultar útiles para desarrollar servicios Web ASP.NET y objetos NET Remoting alojados en ASP.NET. En resumen:

Si su aplicación utiliza la autenticación 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 almacénela en el vale de autenticación.

● Si utiliza la autenticación mediante Formularios, cree siempre un objeto principal y guárdelo en el contexto de cada solicitud.

● Si existen demasiadas funciones para almacenar en la cookie de autenticación, utilice la memoria caché global de la aplicación para almacenar las funciones.

● No cree una cuenta con privilegios mínimos personalizada para ejecutar ASP.NET. En su lugar, cambie la contraseña de la cuenta de ASPNET y cree una cuenta duplicada en cualquier servidor Windows remoto al que deba obtener acceso la aplicación.

● Si debe crear una cuenta personalizada para ejecutar ASP.NET, utilice el principio de los privilegios mínimos. Por ejemplo:

● Utilice una cuenta de dominio con privilegios mínimos si la administración es un problema importante.

● Si utiliza una cuenta local, cree una cuenta duplicada en cualquier equipo remoto al que debe obtener acceso la aplicación Web. Utilice cuentas locales cuando la aplicación necesite obtener acceso a recursos ubicados en dominios que no son de confianza, o si un servidor de seguridad impide la autenticación 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”.

● Utilice SSL si:

● Se transfiere información importante de seguridad entre el explorador y el servidor Web.

● Se utiliza la autenticación básica (para proteger las credenciales).

● Se utiliza la autenticación mediante Formularios para la autenticación (a diferencia de la personalización).

● Evite almacenar secretos en formato de texto sin cifrar.

http://www.microsoft.com/windows2000/downloads/recommended/encryption/

capítulo 8 seguridad de asp.net

Documents

aspnet autenticacin

autenticacin annima

mecanismos de autenticacin

aspnet security

aspnet suplantacin

autenticacin bsica

testigo de acceso

servicios web aspnet