Una página Web mal escrita puede comprometer la integridad y la seguridad de todo el servidor y, potencialmente, de toda la red. Por lo tanto, debe revisar las consideraciones de seguridad que hay que tener en cuenta al diseñar la aplicación Web.ASP.NET Security Architecture

Proporciona información general sobre las relaciones entre los subsistemas y la infraestructura ASP.NET, con respecto a la seguridad.

ASP.NET Web Application SecurityExplica cómo solucionar problemas de autorización y autenticación en ASP.NET.

Security Considerations for JScriptDescribe algunos problemas relacionados con la seguridad que pueden encontrar los programadores de JScript.

How to: Use Transport SecurityDescribe cómo usar la seguridad de transporte para la autenticación cuando se establece conexión con un servicio WCF.

Arquitectura de seguridad de ASP.NETEn esta sección se proporciona información general sobre la infraestructura de seguridad de ASP.NET. En la siguiente ilustración se muestran las relaciones entre los sistemas de seguridad de ASP.NET.Arquitectura ASP.NET

Como se muestra en la ilustración, todos los clientes Web se comunican con las aplicaciones ASP.NET a través de Microsoft Internet Information Services (IIS). IIS autentica la solicitud si fuera necesario y, a continuación, busca el recurso solicitado (como una aplicación ASP.NET). Si el cliente está autorizado, el recurso estará disponible.

Cuando se está ejecutando una aplicación ASP.NET, puede utilizar las características de seguridad de ASP.NET integradas. Además, una aplicación ASP.NET puede utilizar las características de seguridad de .NET Framework. Para obtener más información, vea Conceptos clave de seguridad.

Integrar autenticación de ASP.NET con IISAdemás de basarse en las funciones de autenticación de IIS, puede realizar la autenticación en ASP.NET. Al considerar la autenticación de ASP.NET, deberá comprender la interacción con los servicios de autenticación de IIS.Internet Information Services (IIS) supone que se asigna un conjunto de credenciales a una cuenta de Microsoft Windows NT y que se utilizan las credenciales para autenticar a los usuarios. Los métodos de autenticación que se usan en IIS 7 son: anónima, suplantación de ASP.NET, básica, asignación de certificados de clientes, implícita, mediante formularios y Seguridad integrada de Windows (NTLM o Kerberos). Se puede seleccionar el tipo de autenticación mediante los servicios de administración de IIS. Para obtener más información, vea Configurar la autenticación en IIS 7.Si los usuarios solicitan una dirección URL que asigna una aplicación ASP.NET, la información sobre la autenticación y la solicitud se entrega a la aplicación. ASP.NET proporciona la autenticación de formularios. La autenticación de formularios es un sistema que redirige las solicitudes no autenticadas a una página web ASP.NET que usted crea. El usuario proporciona las credenciales y envía la página. Si la aplicación autentica la solicitud, el sistema emite un vale de autenticación en una cookie que contiene las credenciales o una clave para readquirir la identidad. Las solicitudes subsiguientes incluyen un vale de autenticación con la solicitud.

En esta sección se proporciona información general sobre la infraestructura de seguridad de ASP.NET. En la siguiente ilustración se muestran las relaciones entre los sistemas de seguridad de ASP.NET.Arquitectura ASP.NET

Como se muestra en la ilustración, todos los clientes Web se comunican con las aplicaciones ASP.NET a través de Microsoft Internet Information Services (IIS). IIS autentica la solicitud si fuera necesario y, a continuación, busca el recurso solicitado

(como una aplicación ASP.NET). Si el cliente está autorizado, el recurso estará disponible.Cuando se está ejecutando una aplicación ASP.NET, puede utilizar las características de seguridad de ASP.NET integradas. Además, una aplicación ASP.NET puede utilizar las características de seguridad de .NET Framework. Para obtener más información, vea Conceptos clave de seguridad.

Integrar autenticación de ASP.NET con IISAdemás de basarse en las funciones de autenticación de IIS, puede realizar la autenticación en ASP.NET. Al considerar la autenticación de ASP.NET, deberá comprender la interacción con los servicios de autenticación de IIS.Internet Information Services (IIS) supone que se asigna un conjunto de credenciales a una cuenta de Microsoft Windows NT y que se utilizan las credenciales para autenticar a los usuarios. Los métodos de autenticación que se usan en IIS 7 son: anónima, suplantación de ASP.NET, básica, asignación de certificados de clientes, implícita, mediante formularios y Seguridad integrada de Windows (NTLM o Kerberos). Se puede seleccionar el tipo de autenticación mediante los servicios de administración de IIS. Para obtener más información, vea Configurar la autenticación en IIS 7.Si los usuarios solicitan una dirección URL que asigna una aplicación ASP.NET, la información sobre la autenticación y la solicitud se entrega a la aplicación. ASP.NET proporciona la autenticación de formularios. La autenticación de formularios es un sistema que redirige las solicitudes no autenticadas a una página web ASP.NET que usted crea. El usuario proporciona las credenciales y envía la página. Si la aplicación autentica la solicitud, el sistema emite un vale de autenticación en una cookie que contiene las credenciales o una clave para readquirir la identidad. Las solicitudes subsiguientes incluyen un vale de autenticación con la solicitud.

Configuración de seguridad del archivo de configuración de ASP.NET

La configuración de seguridad de ASP.NET se configura en los archivos Machine.config y Web.config. Como con la demás información de configuración, la configuración base y la predeterminada se establecen en el archivo Machine.config en el subdirectorio Config de la instalación .NET Framework actual. Puede establecer una configuración específica del sitio y otra específica de la aplicación (incluidos los valores de reemplazo del archivo Machine.config) en los archivos Web.config en los directorios raíz del sitio Web y de la aplicación. Los subdirectorios heredan las configuraciones del directorio, a no ser que se reemplacen por un archivo Web.config del subdirectorio. Para ver un ejemplo del funcionamiento de la seguridad en un sistema de configuración jerárquica, vea Elemento configSections (Esquema de configuración general).Hay tres subsecciones principales en un archivo Web.config: las secciones autenticación, autorización e identidad. Los valores para cada elemento de seguridad normalmente se establecen en el archivo Machine.config y se reemplazan según sea necesario en el archivo Web.config en la aplicación. Todos los subdirectorios heredan automáticamente estos valores. No obstante, los subdirectorios pueden tener sus propios archivos de configuración que reemplazan valores heredados.

Nota

La configuración de ASP.NET sólo se aplica a recursos ASP.NET, en concreto a aquéllos que se registraron para que los controlara la extensión Aspnet_isapi.dll en IIS.La configuración de ASP.NET no puede proporcionar autorización para recursos que no haya procesado ASP.NET.tanto, .txt, .htm, .html, .gif, .jpg, .jpeg, .asp y otros tipos de archivo son accesibles para todos los usuarios (sujetos a los permisos de IIS).ejemplo, aunque los recursos de un directorio de ASP.NET estén incluidos en un archivo Web.config con acceso restringido, los usuarios pueden ver los archivos de ese directorio, siempre que el explorador de directorios esté activado y no haya otro tipo de restricciones.pueden estar bajo la seguridad de ASP.NET si se asigna explícitamente dichas extensiones de nombre de archivo a la extensión Aspnet_isapi.dll mediante la herramienta de administración de IIS. Sin embargo, el procesamiento de estos tipos de archivos a través de ASP.NET puede afectar al rendimiento del sitio Web. Para obtener más información sobre cómo proteger los archivos de una carpeta, veaconcretos mediante la configuración de la ubicación.

Se puede utilizar el elemento de configuración ubicación para especificar el archivo o directorio a los que se deben aplicar las opciones predeterminadas. Para obtener más información, vea Elemento configSections (Esquema de configuración general) y Configurar archivos y subdirectorios específicos. Para obtener más información general sobre la configuración de ASP.NET, vea Información general sobre la configuración de ASP.NET.El ejemplo siguiente muestra la sintaxis de las secciones de seguridad de un archivo de configuración:<authentication mode="[Windows|Forms|None]"> <forms name="name" loginUrl="url" protection="[All|None|Encryption|Validation]" timeout="minutes" path="path" requireSSL="[true|false]" slidingExpiration="[true|false]"> defaultUrl="string" cookieless="[UseCookies|UseUri|AutoDetect|UseDeviceProfile]" domain="string" <credentials passwordFormat="[Clear|MD5|SHA1]"> <user name="********" password="********"/> </credentials> </forms></authentication>

<authorization> <allow users="comma-separated list of users" roles="comma-separated list of roles" verbs="comma-separated list of verbs" /> <deny users="comma-separated list of users" roles="comma-separated list of roles" verbs="comma-separated list of verbs" /></authorization>

<identity impersonate ="[true|false]" userName="domain\username" password="password" />

<trust level="[Full|High|Medium|Low|Minimal]" originUrl=""/>

<securityPolicy> <trustLevel name="Full" policyFile="internal"/> <trustLevel name="High" policyFile="web_hightrust.config"/> <trustLevel name="Medium" policyFile="web_mediumtrust.config"/> <trustLevel name="Low" policyFile="web_lowtrust.config"/> <trustLevel name="Minimal" policyFile="web_minimaltrust.config"/></securityPolicy>

Los valores predeterminados de estos elementos se incluyen en la tabla siguiente.

Valor predeterminado Descripción

<allow roles="" /> Una cadena vacía que indica que se permiten todas las funciones de forma predeterminada.

<allow users="*" /> Una cadena vacía que indica que todos los usuarios tienen acceso (no se requiere ninguna autenticación).

<allow verbs="" /> Una cadena vacía que indica que no se asignan verbos de forma predeterminada.

<authentication mode="Windows" /> El tipo de autenticación que determina el origen del valorpredeterminado es Windows.

<credentials passwordFormat="SHA1" /> El algoritmo hash que se utiliza en las contraseñas.

<deny roles="" /> Una cadena vacía que indica que no se deniega ninguna función de forma predeterminada.

<deny users="" /> Una cadena vacía que indica que no se deniega ningún usuario de forma predeterminada.

<deny verbs="" /> Una cadena vacía que indica que no se asignan verbos de forma predeterminada.

<forms cookieless="UseDeviceProfile" />

Método que se usa para almacenar el vale de autenticación de formularios en el cliente. Los valores válidos sonUseCookies, UseUri, AutoDetect, UseDeviceProfile

<forms defaultUrl="default.aspx" /> Cadena que indica la dirección URL de la página a la que se redirecciona después del inicio de sesión.

<forms domain="" /> Cadena vacía que indica que no se ha especificado ningún dominio para la cookie.

<forms loginUrl="logon.aspx" /> Dirección URL a la que se dirige la solicitud si establece la autenticación mode como Forms y si la solicitud no tiene un vale de autenticación válido.

<forms name=".ASPXAUTH" /> El nombre bajo el que la cookie de autenticación de formularios se almacena en el equipo del usuario.

<forms path="/" /> La ruta de acceso a la que se aplica la autenticación de formularios.predeterminado es todas las rutas de acceso desde la raíz de la aplicación hacia abajo.

<forms protection="All" /> La seguridad que se ha aplicado al vale de autenticación de formularios.incluyen All, None,Encryption y Validation

<forms timeout="30" /> El tiempo de espera en minutos antes de que el vale de autenticación de formularios expire y los usuarios tengan que volver a autenticarse.

<forms requireSSL="false" /> Un valor booleano que indica si se requiere una conexión SSL para transmitir la cookie de autenticación.

<forms slidingExpiration="true" /> Un valor booleano que indica si está habilitado el plazo de expiración.más información, vea la propiedad SlidingExpiration

<identity impersonate="false" /> Un valor booleano que indica si la suplantación está deshabilitada.información, veaSuplantación de ASP.NET.

<identity userName="" /> Una cadena vacía que indica que no se especifica ninguna identidad de usuario de forma predeterminada.

<identity password="" /> Una cadena vacía que indica que no se especifica ninguna contraseña para la identidad de usuario de forma predeterminada.

<trust level="Full" originUrl="" /> La directiva de seguridad que se aplicará a la aplicación.

<trustLevel name="Full" policyFile="internal"/>

El archivo de directivas predeterminado para el nivel de confianza Full.

<trustLevel name="High" policyFile="web_hightrust.config"/>

El archivo de directivas predeterminado para el nivel de confianza High.

<trustLevel name="Medium" policyFile="web_mediumtrust.config"/>

El archivo de directivas predeterminado para el nivel de confianza Medium.

<trustLevel name="Low" policyFile="web_lowtrust.config"/>

El archivo de directivas predeterminado para el nivel de confianza Low.

<trustLevel name="Minimal" policyFile="web_minimaltrust.config"/>

El archivo de directivas predeterminado para el nivel de confianza Minimal.

Funcionamiento de la seguridad en ASP.NETLa seguridad de los sitios Web es una cuestión de importancia fundamental, además de compleja, para los desarrolladores de sitios Web. La protección de un sitio requiere la elaboración cuidadosa de un plan; por consiguiente, los programadores y administradores de sitios Web deben comprender perfectamente las opciones para proteger los sitios.ASP.NET funciona junto con Microsoft .NET Framework e Internet Information Services (IIS) para ayudar a proporcionar aplicaciones Web seguras. Para ayudar a proteger la seguridad de una aplicación ASP.NET, se deben llevar a cabo las dos funciones principales que se describen en la siguiente tabla.

Función de seguridad

Descripción

Autenticación Ayuda a comprobar que el usuario es precisamente quien dice ser. La aplicación obtiene las credenciales (diversas formas de identificación, como nombre y contraseña) de un usuario, y las valida consultando a una autoridad determinada.credenciales son válidas, se considera a la entidad que ha enviado las credenciales como una entidad autenticada.

Autorización Limita los derechos de acceso mediante la concesión o negación de permisos específicos a una identidad autenticada.

Además, Internet Information Services (IIS) puede conceder o negar el acceso en función de la dirección IP o del nombre de host del usuario. Cualquier autorización de acceso posterior se realiza mediante la autorización de la dirección URL del permiso de acceso al sistema de archivos NTFS.Es importante entender cómo interactúan todos los diversos subsistemas de seguridad. Puesto que ASP.NET se basa en Microsoft .NET Framework, el desarrollador de aplicaciones ASP.NET también tiene acceso a todas las características de seguridad integradas de .NET Framework, como la seguridad de acceso a código y la seguridad de acceso basada en funciones. Para obtener información detallada sobre las funciones de seguridad de ASP.NET, vea Seguridad de acceso del código de ASP.NET.

Información general sobre las amenazas para la seguridad de las aplicaciones webSi a su aplicación Web tienen acceso usuarios desconocidos, existen muchas probabilidades de que algún usuario malintencionado intente también obtener acceso.Normalmente, los servidores de Internet accesibles al público se sondean constantemente para descartar vulnerabilidades. Por consiguiente, se recomienda que tome precauciones y adopte medidas de seguridad en todas sus aplicaciones Web.Puede encontrar información más detallada sobre los procedimientos recomendados para escribir código seguro y garantizar la seguridad de las aplicaciones en el libro "Writing Secure Code", de Michael Howard y David LeBlanc, o a través de la especificación Microsoft Patterns and Practices.

La tecnología de seguridad es sólo parte de la soluciónImplementar tecnología de seguridad es sólo parte de la solución. Otra parte consiste en la vigilancia. Aunque el sistema cuente con numerosos elementos de seguridad, es preciso vigilarlo de cerca de los modos siguientes:

Supervisando los registros de eventos del sistema. Observe si se producen intentos repetidos de iniciar sesión en su sistema o si el servidor web recibe un número excesivo de solicitudes.

Mantenga continuamente actualizado el servidor de la aplicación con las últimas revisiones de seguridad de Microsoft Windows y de Internet Information Services (IIS), así como cualquier revisión de Microsoft SQL Server o de otros orígenes de datos que pueda utilizar su aplicación.

Modelo de amenazasUna fase importante en el proceso de programación de aplicaciones más seguras consiste en ser capaz de anticipar las amenazas que se puede sufrir. Microsoft ha elaborado un sistema de clasificación de las amenazas en distintas categorías: suplantación, manipulación, repudio, revelación de información, denegación de servicio y concesión de privilegio. En las secciones siguientes se describen brevemente estas amenazas y cómo afectan a las aplicaciones Web.SuplantaciónSuplantar (spoof) es utilizar los datos de identificación de otro usuario o proceso de forma no autorizada. En su versión más simple, la suplantación consistiría en introducir las credenciales de un usuario diferente. Un usuario malintencionado podría también cambiar el contenido de una cookie para fingir que es otra persona o que la cookie proviene de un servidor diferente.

En general, es posible contribuir a evitar la suplantación mediante una autenticación estricta. Siempre que alguien solicita acceso a información privada, es preciso asegurarse de que es quien dice ser. También se puede contribuir a la defensa contra la suplantación manteniendo la información de credenciales a salvo. Por ejemplo, no se debe guardar nunca una contraseña ni otro tipo de datos confidenciales o privados en una cookie, donde un usuario malintencionado podría encontrarlos y modificarlos fácilmente.ManipulaciónManipular significa cambiar o eliminar un recurso sin autorización. El ejemplo típico consiste en desfigurar una página Web, para lo cuál, el usuario malintencionado logra acceso al sitio y cambia algunos archivos. Un modo indirecto de manipulación son los ataques mediante scripts. Un usuario malintencionado consigue que se ejecute código (script) enmascarándolo como la entrada de datos de un usuario en una página o como un vínculo.Una defensa fundamental contra la manipulación consiste en usar la seguridad de Windows para bloquear los archivos, directorios y otros recursos de Windows. La aplicación también debería ejecutarse con privilegios mínimos. Para reforzar la protección contra los ataques al sistema que aprovechan el script, desconfíe ante cualquier información que proceda de un usuario o, incluso, de una base de datos. Siempre que se obtenga información de una fuente que no sea de confianza, es preciso asegurarse de que no contiene código ejecutable.RepudioUna amenaza de repudio implica llevar a cabo una transacción de manera que no haya pruebas fehacientes de los actores de las entidades de seguridad de la transacción. En una aplicación Web, esto puede significar que se está suplantando a un usuario inocente usando sus credenciales. Contribuir a la protección contra el repudio es posible, de nuevo, aplicando una autenticación estricta. Además, se deben usar las funciones de inicio de sesión de Windows para mantener un registro de auditoría de cualquier actividad en el servidor.Revelación de informaciónRevelación de información significa simplemente robar o desvelar información que se supone que es confidencial. Un ejemplo típico es el robo de contraseñas, pero la revelación de información también incluye el acceso a cualquier archivo o recurso del servidor.La mejor protección contra la revelación de información es no tener información que revelar. Por ejemplo, si se evita el almacenamiento de contraseñas, ningún usuario malintencionado podrá robarlas. Una alternativa al almacenamiento de las contraseñas consiste en guardar sólo un valor hash de éstas. De este modo, cuando un usuario presenta sus credenciales, se puede extraer el valor hash de su contraseña y compararlo con el almacenado. Si, aun así, se almacena información confidencial, se debe utilizar la seguridad de Windows para ayudar a protegerla. Como en todos los casos anteriores, se debería utilizar la autenticación para contribuir a garantizar que sólo los usuarios autorizados pueden tener acceso a la información restringida. Si tiene que exponer información confidencial, es recomendable que la cifre cuando la almacene y que utilice SSL (Secure Sockets Layer) para cifrar la información cuando se envía al explorador o se recibe de éste.

Denegación de servicioUn ataque de denegación de servicio consiste en hacer deliberadamente que una aplicación esté menos disponible de lo que debería. Un ejemplo típico es sobrecargar una aplicación Web de forma que no pueda servir a los usuarios normales. Como alternativa, los usuarios malintencionados pueden intentar simplemente bloquear el servidor.Los servicios IIS permiten limitar  las aplicaciones de forma que sólo sirvan un número determinado de solicitudes, lo que podría resultar útil para denegar el acceso a los usuarios o direcciones IP que se sabe que tienen malas intenciones. Para mantener sus aplicaciones en línea, es esencial ejecutar código sólido. Debe probar exhaustivamente su aplicación y responder apropiadamente a los errores siempre que sea posible.Concesión de privilegioUn ataque de elevación de privilegios consiste en usar medios malintencionados para obtener más permisos de los asignados normalmente. Por ejemplo, en un ataque de elevación de privilegios que se realice correctamente, un usuario malintencionado consigue obtener privilegios administrativos para el servidor Web, lo que le proporciona acceso a todos los datos del servidor, así como el control de las funciones de éste.Como ayuda para protegerse contra ataques de elevación de privilegios, se debe ejecutar la aplicación en un contexto con los permisos mínimos, si resulta factible. Por ejemplo, se recomienda no ejecutar las aplicaciones de ASP.NET con la cuenta de usuario SYSTEM (administrador).

Procedimientos de seguridad básicos para aplicaciones webEl tema de la creación de una aplicación Web segura es muy amplio ya que requiere realizar un estudio para comprender los puntos vulnerables de la seguridad.También necesita familiarizarse con las funciones de seguridad de Windows, .NET Framework y ASP.NET. Por último, es esencial entender cómo usar estas características de seguridad para enfrentarse a las amenazas.Aunque no se tenga mucha experiencia en seguridad, existen unas medidas básicas que se deberían adoptar para proteger cualquier aplicación Web. La lista siguiente proporciona pautas de seguridad mínima que se aplican a todas las aplicaciones Web y que se deberían seguir:

Recomendaciones generales de seguridad para aplicaciones Web Ejecutar aplicaciones con privilegios mínimos Conocer a los usuarios Protegerse contra entradas malintencionadas Tener acceso seguro a bases de datos Crear mensajes de error seguros Mantener segura la información confidencial

Usar cookies de forma segura Protegerse contra amenazas de denegación de servicio

Recomendaciones generales de seguridad para aplicaciones Web

No obstante, incluso los métodos de seguridad de aplicaciones más elaborados pueden verse comprometidos si un usuario malintencionado logra obtener acceso a los equipos usando medios simples. Siga estas instrucciones:

Realice copias de seguridad con asiduidad y guárdelas en lugar seguro. Mantenga el equipo del servidor en un lugar físico seguro, de forma que los

usuarios no autorizados no puedan tener acceso a él, apagarlo o llevárselo. Utilice el sistema de archivos NTFS de Windows, no el FAT32. NTFS ofrece

mucha más seguridad que el FAT32. Para obtener información detallada, vea la documentación de Windows.

Proteja el equipo del servidor web y todos los demás equipos de la misma red con contraseñas rigurosas.

Proteja los servicios IIS. Para obtener una información más detallada, visite el sitio Web de Microsoft TechNet Security Center.

Cierre los puertos que no se utilicen y desactive los servicios no usados. Ejecute un programa antivirus que supervise el tráfico entrante y saliente. Establezca y haga respetar una política que prohíba a los usuarios tener sus

contraseñas escritas en una ubicación fácil de localizar. Use un firewall. Para conocer las recomendaciones, vea el artículo en

inglés Microsoft Firewall Guidelines en el sitio Web sobre seguridad de Microsoft. Instale las últimas revisiones de seguridad de Microsoft y otros proveedores. Por

ejemplo, para obtener una lista con los últimos boletines de seguridad para todos los productos Microsoft, consulte Microsoft TechNet Security Center. Otros fabricantes tienen sitios parecidos.

Use las funciones de registro de eventos de Windows y examine los registros con frecuencia para detectar actividades sospechosas. Esto incluye los intentos repetidos de iniciar una sesión en el sistema o la existencia de un número extremadamente alto de solicitudes en el servidor web.

Ejecutar aplicaciones con privilegios mínimosCuando la aplicación se ejecuta, lo hace en un contexto que tiene privilegios específicos en el equipo local y posiblemente en equipos remotos. Para obtener información sobre cómo configurar identidad de aplicaciones, vea Configurar la identidad de procesos en ASP.NET. Para ejecutar con privilegios mínimos, siga estas instrucciones:

No ejecute la aplicación con la identidad de un usuario de sistema (administrador).

Ejecute la aplicación en el contexto de un usuario con los mínimos privilegios factibles.

Establezca permisos (Listas de control de acceso, o ACL) en todos los recursos requeridos por la aplicación y utilice la configuración menos permisiva

posible.Por ejemplo, si resulta viable en la aplicación, establezca que los archivos sean de sólo lectura. Para obtener una lista de los permisos ACL mínimos requeridos para la identidad de su aplicación ASP.NET, vea Listas de control de acceso (ACL) necesarias para ASP.NET.

Mantenga los archivos de la aplicación Web en una carpeta ubicada debajo de la raíz de la aplicación. No dé a los usuarios la opción de especificar una ruta que permita tener acceso a ningún archivo de la aplicación. Esto ayudará a evitar que los usuarios obtengan acceso a la raíz del servidor.

Conocer a los usuariosEn muchas aplicaciones, los usuarios tienen acceso al sitio de forma anónima (sin tener que proporcionar las credenciales). Si es el caso, la aplicación obtiene acceso a recursos al ejecutarse en el contexto de un usuario predefinido. De forma predeterminada, este contexto es el usuario ASPNET local (en Windows 2000 o Windows XP) o el usuario NETWORK SERVICE (en Windows Server 2003) del equipo del servidor web. Para restringir el acceso únicamente a los usuarios que se hayan autenticado, siga estas instrucciones:

Si la aplicación pertenece a una intranet, configúrela para usar la seguridad integrada de Windows. De este modo, las credenciales de inicio de sesión de los usuarios se pueden usar para obtener acceso a los recursos. Para obtener más información, vea Suplantación de ASP.NET.

Si precisa recabar credenciales del usuario, utilice una de las estrategias de autenticación de ASP.NET. Para obtener un ejemplo, vea Administrar usuarios mediante pertenencia.

Protegerse contra entradas malintencionadasComo regla general, nunca se debe dar por sentado que la entrada proveniente de los usuarios es segura. A los usuarios malintencionados les resulta fácil enviar información potencialmente peligrosa desde el cliente a la aplicación. Para protegerse contra las entradas malintencionadas, siga estas instrucciones:

En las páginas Web ASP.NET, filtre la entrada de los usuarios para comprobar si existen etiquetas HTML, que pueden contener un script. Para obtener información detallada, vea Cómo: Proteger una aplicación web frente a ataques mediante scripts aplicando codificación HTML a las cadenas.

Nunca repita (muestre) entrada de los usuarios sin filtrar. Antes de mostrar información que no sea de confianza, codifique los elementos HTML para convertir cualquier script potencialmente peligroso en cadenas visibles, pero no ejecutables.

No almacene nunca información proporcionada por el usuario sin filtrar en una base de datos.

Si desea aceptar algún elemento de código HTML de un usuario, fíltrelo manualmente. En el filtro, defina explícitamente lo que aceptará. No cree un filtro que intente eliminar cualquier entrada malintencionada, ya que es muy difícil anticipar todas las posibilidades.

No dé por sentado que la información obtenida del encabezado de solicitud HTTP (en el objeto HttpRequest) es segura. Proteja las cadenas de consulta, cookies, etc. Tenga en cuenta que la información que el explorador envía al

servidor (información del agente de usuario) puede ser suplantada, en caso de que resulte importante para la aplicación en cuestión.

Si es posible, no almacene información confidencial en un lugar accesible desde el explorador, como campos ocultos o cookies. Por ejemplo, no almacene una contraseña en una cookie.

Nota

El estado de vista se almacena en un campo oculto en un formato codificado. que, de forma predeterminada, incluye un código de autenticación de mensajes (MAC) para que la página pueda determinar si se ha manipulado el estado de vista.se almacena en estado de vista, cifre estableciendo la propiedad ViewStateEncryptionMode de la página en

Tener acceso seguro a bases de datosNormalmente, las bases de datos tienen sus propios sistemas de seguridad. Un aspecto importante de una aplicación Web protegida es diseñar un modo de que ésta pueda tener acceso a la base de datos de forma segura. Siga estas instrucciones:

Use el sistema de seguridad inherente de la base de datos para limitar quién puede tener acceso a los recursos de dicha base. La estrategia exacta dependerá de la base de datos y de la aplicación:

o Si resulta viable en la aplicación, use la seguridad integrada de forma que sólo los usuarios autenticados mediante Windows puedan tener acceso a la base de datos. La seguridad integrada es más segura que pasar las credenciales explícitas a la base de datos.

o Si la aplicación utiliza el acceso anónimo, cree un único usuario con permisos muy limitados, y haga que las consultas se ejecuten conectándose como dicho usuario.

No cree instrucciones SQL concatenando cadenas que contengan información aportada por los usuarios. En su lugar, cree una consulta parametrizada y use la entrada del usuario para establecer los valores de los parámetros.

Si debe almacenar un nombre de usuario y su contraseña en algún lugar para utilizarlos como las credenciales de inicio de sesión de la base de datos, almacénelos en el archivo Web.config y asegure el archivo con configuración protegida. Para obtener información detallada, vea Cifrar la información de configuración mediante una configuración protegida.

Para obtener más información sobre cómo tener acceso a los datos de forma segura, vea Proteger el acceso a datos y Proteger aplicaciones de ADO.NET.

Crear mensajes de error segurosSi no se es cuidadoso, un usuario malintencionado puede deducir información importante sobre la aplicación a partir de los mensajes de error que ésta muestra. Siga estas instrucciones:

No escriba mensajes de error que presenten información que pudiera resultar útil a los usuarios malintencionados, como un nombre de usuario.

Configure la aplicación para que no muestre errores detallados a los usuarios. Si desea mostrar mensajes de error detallados para la depuración, determine primero si quien los recibirá es un usuario local con respecto al servidor

web. Para obtener información detallada, vea Cómo: Mostrar mensajes de error seguros.

Utilice el elemento de configuración customErrors para controlar quién ve las excepciones desde el servidor.

Cree un sistema de administración de errores personalizado para las situaciones que sean propensas a los errores, como el acceso a las bases de datos. Para obtener más información, vea Control de errores en aplicaciones y páginas ASP.NET.

Mantener segura la información confidencialInformación confidencial es toda aquella información que se desea conservar privada. Un ejemplo de información confidencial es una contraseña o una clave cifrada. Si un usuario malintencionado consigue llegar a la información confidencial, los datos protegidos se verán expuestos. Siga estas instrucciones:

Si la aplicación transmite información confidencial entre el explorador y el servidor, plantéese utilizar el protocolo SSL (Secure Sockets Layer). Para obtener detalles sobre cómo asegurar un sitio con SSL, vea el artículo Q307267 en inglés, "HOW TO: Secure XML Web Services with Secure Socket Layer in Windows 2000" en Microsoft Knowledge Base en el sitio http://support.microsoft.com.

Utilice configuración protegida para proteger la información confidencial en archivos de configuración como los archivos Web.config o Machine.config. Para obtener más información, vea Cifrar la información de configuración mediante una configuración protegida.

Si debe almacenar información confidencial, no lo haga en una página Web, ni siquiera en un formato que piense que la gente no podrá verlo (por ejemplo, código del servidor).

Utilice los algoritmos de cifrado de alta seguridad proporcionados en el espacio de nombres System.Security.Cryptography.

Usar cookies de forma seguraLas cookies constituyen un modo útil de almacenar la información específica disponible sobre los usuarios. Sin embargo, como se envían al explorador del equipo, son vulnerables a la suplantación u otros usos malintencionados. Siga estas instrucciones:

No almacene información vital en cookies. Por ejemplo, no almacene, ni siquiera temporalmente, la contraseña de un usuario en una cookie. Como norma, no guarde nada en una cookie que, si se produce una suplantación, pueda comprometer el funcionamiento de su aplicación. En lugar de eso, guarde en la cookie una referencia a la ubicación del servidor en la que se encuentra la información.

Establezca el período de tiempo mínimo posible para la fecha de expiración de las cookies. Si es posible, evite las cookies permanentes.

Plantéese cifrar la información que contienen las cookies. Considere establecer las propiedades Secure y HttpOnly de las cookies

como true.

Protegerse contra amenazas de denegación de servicioUn modo indirecto en el que un usuario malintencionado puede comprometer una aplicación es haciendo que ésta no esté disponible. El usuario malintencionado puede mantener la aplicación demasiado ocupada como para que pueda servir a otros usuarios, o si puede simplemente bloquearla. Siga estas instrucciones:

Use un control de errores (por ejemplo, try-catch). Incluya un bloque final en el que se liberen los recursos si se produce un error.

Configure los servicios IIS para utilizar la regulación de procesos, que evita que una aplicación use una cantidad desproporcionada del tiempo de la CPU.

Compruebe los límites de tamaño de la entrada del usuario antes de usarla o almacenarla.

Incluya límites de tamaño para las consultas a las bases de datos. Por ejemplo, antes de mostrar los resultados de las consultas en una página Web ASP.NET, asegúrese de que no hay un número excesivo de registros.

Establezca un límite de tamaño para las cargas de archivos, si éstas forman parte de la aplicación. Puede establecer un límite en el archivo Web.config usando sintaxis como la siguiente, donde el valor maxRequestLength está en kilobytes:

<configuration> <system.web> <httpRuntime maxRequestLength="4096" /> </system.web> </configuration>

Asimismo puede utilizar la propiedad RequestLengthDiskThreshold para reducir la sobrecarga de memoria de grandes cargas y devoluciones de formularios.

Acceso a SQL Server desde una aplicación webCuando una aplicación Web implica el acceso a bases de datos, debe proporcionar credenciales a SQL Server (es decir, debe iniciar una sesión en SQL Server), exactamente igual que cualquier otro usuario o proceso. En una aplicación Web, esto puede introducir complicaciones. Por ejemplo, si la aplicación Web se ejecuta de forma anónima, puede que no haya credenciales que pasar a SQL Server.Existen diferentes formas de diseñar el acceso a SQL Server para las aplicaciones Web. La estrategia elegida dependerá de cómo estén configurados los equipos y de si éstos pertenecen a una intranet. Las opciones más sencillas son las siguientes:

Usar la seguridad integrada de Windows. Esta opción pasa las credenciales del usuario a SQL Server. Debido a los problemas de delegación, es frecuente que esto sólo funcione de forma predeterminada si SQL Server está en el mismo equipo que IIS.

Asignar la identidad de la aplicación ASP.NET a un usuario de dominio Windows y, a continuación, iniciar una sesión en la base de datos como dicho

usuario. Esta opción funciona bien para el acceso anónimo si SQL Server y el servidor Web se encuentran en equipos distintos.

Obtenga acceso al servidor SQL Server como identidad local de una aplicación ASP.NET (por ejemplo, la cuenta ASPNET local en un servidor Windows 2000 o la cuenta NETWORK SERVICE local en un servidor Windows Server 2003). Esta opción resulta adecuada para el acceso anónimo.

Pasar un nombre de usuario y contraseña explícitos en una cadena de conexión. Esta opción puede resultar menos segura que otras opciones, por lo que debería utilizar siempre la configuración protegida para las cadenas de conexión. Puede pasar un nombre de usuario y una contraseña predeterminados.

En esta secciónTérmino Definición

Cómo: Obtener acceso a SQL Server mediante la seguridad integrada de Windows

Proporciona un ejemplo de cómo utilizar la seguridad integrada de Windows para el acceso a bases de datos.

Cómo: Obtener acceso a SQL Server mediante un usuario de dominio Windows asignado

Proporciona un ejemplo de cómo utilizar un usuario del dominio de Windows asignado para el acceso a bases de datos.

Cómo: Obtener acceso a SQL Server como usuario local Proporciona un ejemplo de cómo utilizar una cuenta de usuario local para el acceso a bases de datos.

Cómo: Obtener acceso a SQL Server mediante las credenciales predeterminadas

Proporciona un ejemplo de cómo utilizar la información de inicio de sesión predeterminada para el acceso a bases de datos.

Seguridad de aplicaciones Web en tiempo de ejecuciónEl desarrollo de una aplicación exige trabajar con un conjunto de cuestiones de seguridad. El otro conjunto de cuestiones (que suelen ser las más destacadas en cualquier comentario acerca de la seguridad Web) se refieren a la seguridad de la aplicación una vez implementada y en ejecución.

Las aplicaciones Web, por definición, permiten el acceso de usuarios a recursos centrales, el servidor web y, a través de éste, a otros como los servidores de bases de datos. Comprender e implementar las medidas de seguridad adecuadas permite:

Proteger los recursos propios contra accesos no autorizados. Restringir los niveles de acceso por usuario o por función. Establecer integridad de datos y confidencialidad, proporcionando un entorno

relativamente seguro en el que los usuarios se encuentren cómodos al trabajar con su aplicación.

Establecer control sobre cómo la aplicación obtiene acceso a recursos restringidos.

Garantizar que el código de la aplicación se ejecuta de la forma esperada.Este tema proporciona un comentario general sobre cómo llevar a cabo estos objetivos, e incluye vínculos con temas adicionales en los que se pueden obtener más detalles acerca de las tecnologías implicadas.Puede ayudar a proteger su aplicación de acceso no autorizado aprovechando estos tipos de características de seguridad:

Características de seguridad que ofrece Internet Information Services (IIS) como parte de su funcionalidad general de servidor web. Esto es, seguridad de nivel de usuario, equipo y archivo de Windows.

La seguridad que se puede incorporar a la aplicación ASP.NET para proporcionar acceso específico para la aplicación.

Proceso de seguridad en ASP.NETIIS proporciona muchas opciones de seguridad para los sitios Web. Sin embrago, los mecanismos de seguridad de IIS son muy genéricos, ya que se utilizan los mismos mecanismos para todas las aplicaciones. Además, es posible que las opciones de seguridad de IIS, por ejemplo, la seguridad integrada de Windows, no siempre sean adecuadas para su aplicación. (Por otro lado, para las aplicaciones de intranet, tal vez prefiera utilizar la seguridad integrada de Windows que es más sencilla.)Por lo tanto, para proporcionar acceso a partes específicas de su aplicación, puede utilizar seguridad de ASP.NET. La seguridad de ASP.NET funciona junto con la seguridad IIS pero la amplía para que pueda personalizar características, como por ejemplo, la obtención de credenciales de usuario.IIS recibe en primer lugar solicitudes de los clientes, y efectúa las comprobaciones de seguridad establecidas para la aplicación mediante las herramientas de administración de IIS. Por ejemplo, si la aplicación se ha configurado en IIS de forma que permita el acceso anónimo, IIS no efectúa comprobación de credenciales. Una vez efectuada la comprobación inicial de autenticación, IIS envía una solicitud a ASP.NET, que puede llevar a cabo un segundo nivel de comprobación. ASP.NET permite especificar restricciones de acceso a la aplicación mediante diversos criterios: se puede restringir el acceso a páginas específicas, a usuarios específicos, etc.AutenticaciónEn la siguiente tabla, se describen los métodos de autenticación compatibles con ASP.NET. Algunos de ellos solapan la autenticación de IIS. Para obtener información detallada, vea Autenticación de ASP.NET.

Tipo de autenticación Descripción

Acceso anónimo Para aplicaciones en las que usuarios anónimos efectúen solicitudes (generalmente, aplicaciones Web públicas). Se superpone con IIS.

Autenticación básica y de texto implícita

(Opción de seguridad de IIS) En este escenario, a los usuarios sin credenciales se les solicita que proporcionen un nombre de usuario y una contraseña.

Seguridad integrada de Windows (también denominada Seguridad NTLM)

(Opción de seguridad de IIS) Si el usuario que hace la solicitud ya ha sido autenticado en una red basada en Windows, IIS puede pasar las credenciales del usuario cuando solicite acceso a un recurso.

Autenticación de certificados (Opción de seguridad de IIS) En este escenario, el cliente tiene un certificado (una identificación digital) que ha obtenido de un recurso de terceros.La identidad asignada al certificado del cliente pasa a ASP.NET.

Kerberos (Opción de seguridad de IIS) El protocolo de autenticación Kerberos define las interacciones entre un cliente y un Servicio de autenticación de red denominado Centro de distribución de claves (KDC).implementan un KDC como servicio de autenticación en cada controlador de dominio.

Autenticación de Windows (Opción de seguridad de ASP.NET) Se integra con las opciones de seguridad de IIS mostradas previamente . ASP.NET adopta el símbolo de seguridad creado por IIS y hace que esté disponible como un objeto WindowsPrincipal establecido como el valor de la propiedad User

Autenticación mediante formularios

(Opción de seguridad de ASP.NET) Si un usuario necesita autenticarse, ASP.NET redirige la solicitud a la página que especifique. Esta página suele contener un formulario en el que se obtiene la información del nombre de usuario. Para mayor seguridad, el formulario puede intercambiarse mediante el protocolo HTTPS. Cuando la aplicación obtiene la información del formulario, puede llevar a cabo una comprobación de las credenciales del usuario específicas de la aplicación. Una cuestión importante es que el proceso de autenticación está bajo su control (a diferencia de IIS), lo que permite especificar el aspecto del formulario y la forma de almacenar la información de usuario.Si un usuario se autentica satisfactoriamente, ASP.NET emite una cookie cifrada que contiene un símbolo que identifica al usuario para su acceso subsiguiente.

La autenticación mediante formularios es la elección más fácil para las aplicaciones ASP.NET en Internet ya que ofrece un control considerable sobre la forma de autenticación de los usuarios y permite almacenar una autenticación en un símbolo del explorador.Para obtener información detallada sobre la seguridad de IIS, vea los temas relativos al control de accesos en Windows Server TechCenter for IIS en el sitio Web Microsoft TechNet. Para obtener información detallada sobre la autenticación de ASP.NET, vea Autenticación de ASP.NET.Para obtener información detallada sobre la utilización de la autenticación mediante formularios con transición de protocolos y delegación restringida en un entorno de dominios Windows Server 2003, vea Kerberos Protocol Transition and Constrained Delegation.

AutorizaciónCuando se ejecuta, la aplicación Web solicita recursos del servidor web y, con frecuencia, también de otros procesos, como una base de datos. El proceso de ASP.NET se ejecuta en un contexto de usuario que determina cómo solicitará esos recursos la aplicación. El proceso ASP.NET se ejecuta como un usuario local especial denominado ASPNET (de forma predeterminada) en Windows 2000 y Windows XP Professional Edition, o se ejecuta como la identidad de la agrupación de aplicaciones para la aplicación ASP.NET en Windows 2003 (de forma predeterminada, la cuenta local NETWORK SERVICE). Estas cuentas se ejecutan con permisos limitados. Puede especificar un contexto de usuario diferente para el proceso ASP.NET, incluida la cuenta local SYSTEM (que ejecuta la aplicación en un contexto administrador) o un usuario cuyas credenciales proporcione explícitamente, aunque no se recomienda.En la aplicación ASP.NET se puede especificar que distintos usuarios tengan acceso autorizado a distintos recursos. Si su aplicación utiliza autenticación de Windows, se pueden utilizar permisos de Windows para determinar la autorización para obtener acceso a archivos o carpetas específicos del servidor.Otra posibilidad es utilizar autorización basada en URL, en la que la autorización se puede conceder o denegar según distintos criterios:

Usuarios específicos, o identidades, basados en las credenciales proporcionadas por el usuario.

Roles, que son entidades definidas para permitir que varios usuarios compartan privilegios según un rol o función común.

Verbos, que son los procesos HTTP (como GET y POST) para obtener acceso a partes de la aplicación.

Por ejemplo, se puede especificar que todos los usuarios puedan obtener páginas (llevar a cabo el verbo GET) de la aplicación, pero que únicamente usuarios específicos puedan enviar páginas a la misma. De forma similar, se puede especificar que todos los usuarios puedan obtener (GET) páginas, pero que se deniegue el derecho a enviar a roles específicos.Se puede conceder autorización de URL para la aplicación en su conjunto, o directorio por directorio. Un uso típico es permitir a los usuarios ver páginas en un directorio público, pero conservar las páginas restringidas en un directorio distinto, autorizado únicamente para usuarios o roles específicos.

Nota

De forma predeterminada, los archivos estáticos, como imágenes y hojas de estilos, no están sujetos a la autorización de ASP.NET cuando se proporcionan a través de IIS. Las características de seguridad de IIS se pueden utilizar para restringir el acceso a archivos estáticos si no desea que todos los usuarios tengan acceso a los archivos. Si utiliza el servidor de desarrollo de ASP.NET para probar la aplicación ASP.NET, notará un comportamiento diferente debido a que los archivos estáticos están sujetos a la autorización de ASP.NET y no se proporcionarán a un usuario anónimo cuando el acceso anónimo a esos archivos esté deshabilitado. También puede asignar extensiones estáticas de nombre de archivo en IIS a la extensión ISAPI de ASP.NET, en cuyo caso se aplicarán las reglas de autorización de ASP.NET.

Para obtener más información, vea Autorización de ASP.NET y Procedimientos de seguridad básicos para aplicaciones web.

Archivos de configuración de ASP.NETLas opciones de seguridad de ASP.NET se establecen con los valores de un archivo Web.config. El archivo permite incluir elementos predefinidos para diversas opciones de seguridad, incluidas secciones para autenticación y autorización. Las secciones importantes del archivo Web.config pueden tener el siguiente aspecto.

Limitar el acceso a los sitios web ASP.NETLa limitación del acceso a una aplicación suele dividirse en dos temas: autenticación, que es la forma en que una aplicación identifica quién es el usuario, y autorización, que es la forma en que una aplicación identifica cuáles son los permisos de este. Este tema ofrece información general sobre la autenticación y la autorización en las aplicaciones web ASP.NET. Para obtener información más detallada, vea Seguridad ASP.NET de aplicaciones Web.

Autenticar a usuariosLas aplicaciones ASP.NET ofrecen varias opciones diferentes para autenticar a los usuarios. En el caso de las aplicaciones de sólo lectura que puede ver cualquiera, utilice la autenticación anónima. Para tener un acceso más restringido a una aplicación, debe utilizar algún tipo de autenticación para identificar a los usuarios. Hay dos identidades que debe tener en cuenta a la hora de autenticar a los usuarios de su aplicación ASP.NET: la identidad de la aplicación que se utiliza para tener acceso a los recursos de Windows y la identidad de usuario de ASP.NET que se utiliza para identificar a un usuario ante ASP.NET.Su aplicación puede ejecutarse sin una identidad de usuario de ASP.NET, pero siempre tendrá una identidad de aplicación para Windows. Para ayudar a proteger su aplicación, debe restringir la identidad de Windows para la aplicación a los recursos necesarios, como el acceso a archivos y a bases de datos.Identidad de aplicación ASP.NETCuando una página ASP.NET está en ejecución, el servidor debe tener un contexto de seguridad, o identidad, para el proceso que está ejecutando el código ASP.NET.Esta identidad se utiliza al proteger recursos mediante la seguridad integrada de Windows, como los archivos protegidos mediante el sistema de archivos NTFS o recursos de red.Por ejemplo, sólo la identidad de aplicación ASP.NET tiene que leer los archivos que contienen el código de aplicación almacenado en el subdirectorio App_Code de una aplicación. Por tanto, se puede restringir la configuración de seguridad de los archivos del directorio App_Code de manera que la identidad de aplicación ASP.NET sólo tenga acceso de lectura. Otro uso frecuente de la identidad de Windows de la aplicación ASP.NET es como identidad de una conexión a SQL Server mediante seguridad integrada. Para obtener más información, vea Listas de control de acceso (ACL) necesarias para ASP.NET y Cómo: Obtener acceso a SQL Server mediante la seguridad integrada de Windows.Hay varios factores que determinan la identidad de una aplicación ASP.NET. De forma predeterminada, las páginas ASP.NET se ejecutan con la identidad de Windows del

servicio que procesa las páginas ASP.NET en el servidor web. En un equipo que ejecuta Windows Server 2003, esa identidad es la identidad del grupo de aplicaciones del que forma parte la aplicación ASP.NET (de manera predeterminada, la cuenta NETWORK SERVICE). En los equipos que ejecutan Windows 2000 y Windows XP Professional, la identidad es la cuenta local ASPNET que se crea cuando se instala .NET Framework. Esta identidad se puede configurar a una identidad diferente, si se desea. Para obtener más información, vea Configurar la identidad de procesos en ASP.NET.Puede modificar la identidad de Windows con la que se ejecuta su página ASP.NET mediante el elemento identity de la sección system.web del archivo de configuración. El elemento identity se puede usar para indicar a ASP.NET que suplante un identificador de usuario de Windows. La suplantación de una identidad de Windows significa que las páginas ASP.NET para la aplicación se ejecutarán como esa identidad de Windows. Puede especificar un nombre de usuario y una contraseña para suplantar. Como alternativa, puede habilitar la suplantación y ASP.NET se ejecutará de una de dos maneras posibles: una identidad anónima especificada por IIS, o la identidad del explorador autenticada determinada por IIS (por ejemplo, autenticación anónima, autenticación de Windows integrada (NTLM), etc.). Para obtener más información, vea Suplantación de ASP.NET.Si va a suplantar una identidad de Windows, puede ejecutar código que revierta a la identidad original del proceso en lugar del identificador de usuario suplantado.Por eso, en aquellos entornos en los que tenga que mantener separadas las aplicaciones unas de otras, debe aislarlas en grupos de aplicaciones diferentes en equipos que ejecuten Windows Server 2003. Cada grupo de aplicaciones debe configurarse con una identidad de Windows única.Puede determinar fácilmente la identidad de Windows del subproceso del sistema operativo que está ejecutando su página ASP.NET mediante la propiedad Name delWindowsIdentity devuelto por el método GetCurrent, como se muestra en el ejemplo de código siguiente.<%=System.Security.Principal.WindowsIdentity.GetCurrent().Name%>

Usuario de ASP.NETLa identidad de usuario de ASP.NET se utiliza para tener acceso a recursos específicos de ASP.NET. Por ejemplo, puede identificar una parte de una aplicación para que sólo esté disponible para determinados usuarios, mientras que otras partes de la aplicación estarán disponibles para todos los usuarios.El elemento authentication de la sección system.web del archivo Web.config de la aplicación determina el usuario de ASP.NET. Tiene varias opciones para autenticar la identidad de ASP.NET para su aplicación. Puede utilizar el nombre de usuario de Windows determinado por IIS, autenticación de formularios de ASP.NET, autenticación Passport o un esquema de autenticación personalizado. Se puede tener acceso a la identidad de ASP.NET utilizando la propiedad User del HttpContext actual. Para obtener información detallada, vea Autenticación de ASP.NET.Si está utilizando autenticación de formularios de ASP.NET o una solución de autenticación personalizada para proporcionar la identidad de ASP.NET, puede utilizar la pertenencia a ASP.NET para ofrecer funcionalidad de almacén de datos de usuarios y administración de usuarios. Para obtener más información, vea Administrar usuarios mediante pertenencia.

Autorizar a usuariosLa autorización implica restringir el acceso de los usuarios sólo a los recursos necesarios. Esto incluye restringir el acceso sólo a los archivos, las bases de datos y las partes de su aplicación que sean necesarios. Además, esto incluye el uso de Seguridad de acceso a código para restringir el acceso al código.Puede restringir el acceso a archivos utilizando listas de control de acceso de NTFS y FileAuthorizationModule. Para obtener más información, vea Autorización de ASP.NET y Listas de control de acceso (ACL) necesarias para ASP.NET.Puede restringir el acceso a determinadas partes de su aplicación utilizando UrlAuthorizationModule y Administración de funciones de ASP.NET. Para obtener más información, vea Autorización de ASP.NET y Administrar autorizaciones con roles.

aplicaciones Web

ASP.NET, conjuntamente con Microsoft Internet Information Services (IIS), puede autenticar las credenciales del usuario como nombres y contraseñas mediante los métodos de autenticación siguientes:

Windows: básica, implícita, y Autenticación de Windows integrada (NTLM o Kerberos).

Autenticación mediante formularios, con la que crea una página de inicio de sesión y se administra la autenticación en la aplicación.

Autenticación mediante certificados de clienteASP.NET controla el acceso a la información de los sitios comparando las credenciales autenticadas, o representaciones de las mismas, con los permisos del sistema de archivos de Microsoft Windows NT o con un archivo XML que contiene la lista de usuarios autorizados, funciones autorizadas (grupos) o verbos HTTP autorizados.Esta sección contiene temas en los que se describen las características de seguridad específicas de ASP.NET.

Escribir código seguro es un desafío en cualquier lenguaje. JScript incluye algunas áreas en las que los desarrolladores podrían usar el lenguaje de manera insegura inadvertidamente porque el lenguaje no les obliga a usar los procedimientos más eficaces. A pesar de que uno de los objetivos que se plantearon al diseñar JScript fue la seguridad, su principal finalidad es promover el desarrollo rápido de aplicaciones útiles. En algunos casos, estos dos objetivos se contraponen.Puede evitar los temas de seguridad si conoce los posibles problemas que existen en las distintas áreas que se enumeran a continuación. Estas consideraciones en materia

de seguridad, excepto el método eval, son consecuencia de la nueva funcionalidad que ofrece .NET Framework.

El método evalLa característica de JScript que peor se usa es el método eval, que permite la ejecución dinámica del código fuente de JScript. Dado que las aplicaciones de JScript que usan el método eval pueden ejecutar cualquier tipo de código que les pase un programa, todas las llamadas al método eval suponen un riesgo para la seguridad. A menos que la aplicación requiera flexibilidad para ejecutar cualquier tipo de código, considere escribir sólo el código que la aplicación pasa al método eval.

Atributos de seguridadSe pueden usar los atributos de seguridad de .NET Framework para reemplazar explícitamente la configuración de seguridad predeterminada de JScript. No obstante, no se deben modificar los valores predeterminados de seguridad a menos que se sepa exactamente qué se está haciendo. Concretamente, algo que no se debe aplicar es el atributo APTCA (AllowPartiallyTrustedCallersAttribute) personalizado ya que, en general, los llamadores que no son de confianza no pueden llamar a código JScript de forma segura. Si crea un ensamblado de confianza con APTCA que, más tarde, cargue la aplicación, un llamador de confianza parcial podría obtener acceso a los ensamblados de plena confianza de dicha aplicación. Para obtener más información, vea Instrucciones de codificación segura.

Código de confianza parcial y código hospedado de JScriptEl motor que hospeda JScript permite a cualquier código al que se llame modificar partes del motor, como variables globales, variables locales y cadenas de prototipo de cualquier objeto. Asimismo, todas las funciones pueden modificar las propiedades o los métodos expando de cualquier objeto expando que se les pase. Por consiguiente, si una aplicación de JScript llama a código de confianza parcial o si se ejecuta en una aplicación con otro tipo de código (como en un host de Visual Studio para Aplicaciones [VSA]), se podría modificar el comportamiento de la aplicación.Como consecuencia, cualquier código JScript de una aplicación (o de una instancia de una clase AppDomain) debe ejecutarse en un nivel de confianza que no sea superior al resto del código de la aplicación. De lo contrario, el otro código podría manipular el motor para la clase de JScript, lo que, a su vez, podría modificar los datos y afectar al código restante de la aplicación. Para obtener más información, vea _AppDomain.

Acceso al ensambladoJScript puede hacer referencia a los ensamblados mediante nombres seguros y nombres de texto simple. Una referencia a un nombre seguro incluye la información de versión del ensamblado, así como una firma criptográfica que confirma la integridad y la identidad de dicho ensamblado. Si bien resulta más fácil utilizar un nombre simple al hacer referencia a un ensamblado, un nombre seguro ayuda a proteger el código en caso de que otro ensamblado del sistema tenga el mismo nombre simple, pero distinta funcionalidad. Para obtener más información, vea Cómo: Hacer referencia a un ensamblado con nombre seguro.

SubprocesamientoEl runtime de JScript no es seguro para subprocesos. Por consiguiente, el código JScript multiproceso puede tener un comportamiento impredecible. Si desarrolla un ensamblado en JScript, tenga en cuenta que es posible que se use en un contexto multiproceso. Debe usar clases del espacio de nombres System.Threading, como la clase Mutex, para garantizar que el código JScript del ensamblado se ejecute con la sincronización adecuada.Dado que resulta difícil escribir código de sincronización apropiado en cualquier lenguaje, no debe intentar escribir ensamblados de propósito general en JScript, a menos que sepa exactamente cómo implementar el código de sincronización necesario. Para obtener más información, vea System.Threading.

Nota

No es necesario escribir código de sincronización para las aplicaciones ASP.NET escritas en JScript, ya que ASP.NET administra la sincronización de todos los subprocesos que genera. No obstante, los controles web escritos en JScript deben contener código de sincronización porque se comportan como los ensamblados.

Errores en tiempo de ejecuciónDado que JScript es un lenguaje en el que no es necesario declarar los tipos de datos, tolera mejor las posibles divergencias entre los tipos que otros lenguajes, como Visual Basic y Visual C#. Debido a que la divergencia entre los tipos puede producir errores en tiempo de ejecución en las aplicaciones, es importante detectarlas al desarrollar el código. Se puede usar la marca /warnaserror con el compilador de la línea de comandos o el atributo warninglevel de la directiva @ Page en las páginas ASP.NET. Para obtener más información, vea /warnaserror y @ Page.

Modo de compatibilidadLos ensamblados compilados en modo de compatibilidad (con la opción /fast-) son menos seguros que los compilados en modo rápido (el modo predeterminado).La opción /fast- habilita características del lenguaje que no están disponibles de manera predeterminada, pero que son necesarias para la compatibilidad con los scripts escritos para la versión 5.6 y versiones anteriores de JScript. Por ejemplo, las propiedades expando se pueden agregar dinámicamente a los objetos intrínsecos, como el objeto String, en modo de compatibilidad.El modo de compatibilidad sirve para ayudar a los desarrolladores a crear ejecutables independientes a partir de código JScript heredado. Cuando desarrolle nuevos ejecutables o bibliotecas, utilice el modo predeterminado. Así, no sólo ayudará a proteger las aplicaciones, sino que también ayudará a garantizar un mayor rendimiento y una mejor interacción con otros ensamblados. Para obtener más información, vea /fast.