Esta documentación está archivada y no tiene mantenimiento.

Proteger la configuración de ASP.NET

Actualización: noviembre 2007

La configuración de ASP.NET proporciona la funcionalidad para configurar un servidor completo, una aplicación ASP.NET o páginas individuales en los subdirectorios de la aplicación. Puede configurar características, como modos de autenticación, almacenamiento en caché de páginas, opciones del compilador, errores personalizados, depuración y opciones de seguimiento, y mucho más. En este tema se describe cómo optimizar la seguridad de las características de configuración mediante los procedimientos recomendados al configurar las aplicaciones ASP.NET locales o remotas. Para obtener más información sobre cómo proteger otras características de ASP.NET, vea la información en la sección Vea también.

Aunque seguir los procedimientos recomendados de configuración y programación puede ayudarle a mejorar la seguridad de las aplicaciones, es importante mantener siempre actualizado el servidor de aplicaciones con las actualizaciones de seguridad más recientes de Microsoft Windows e Internet Information Services (IIS), así como con cualquier actualización de Microsoft SQL Server u otros orígenes de datos de la suscripción.

Para obtener información detallada sobre los procedimientos recomendados para escribir código seguro y proteger las aplicaciones, vea el libro "Writing Secure Code" de Michael Howard y David LeBlanc, así como las instrucciones proporcionadas en Microsoft Patterns and Practices.

ms178699.alert_caution(es-es,VS.90).gifNota importante:

El sistema de configuración de ASP.NET sólo configura recursos y características de ASP.NET. Utilice las características de configuración de IIS para configurar recursos que no son de ASP.NET. Para obtener más información sobre cómo configurar IIS, vea Working with the Metabase (IIS 6.0) e IIS Metabase Property Reference.

La tabla siguiente muestra las listas de control de acceso (ACL) establecidas de forma predeterminada en el archivo Machine.config y en el archivo Web.config raíz, que se encuentran ambos en el directorio %RaízSistema%\Microsoft.NET\Framework\versión\CONFIG. Estas ACL también se establecen en el mismo directorio pero incluyen permisos de modificación para el grupo de usuarios avanzados. El directorio es de sólo lectura.

Cuenta de Windows

Permisos

Administradores

Control completo

Cuenta de equipo de ASP.NET (<servidor>\ASPNET)

Lectura y ejecución

IIS_WPG (<servidor>\IIS_WPG)

Lectura y ejecución

LOCAL SERVICE

Lectura y ejecución

NETWORK SERVICE

Lectura y ejecución

Usuarios avanzados (<servidor>\Power Users)

Modificar

SYSTEM

Control completo

Usuarios (<servidor>\Users)

Lectura y ejecución

La tabla siguiente muestra las ACL que se deben establecer en archivos Web.config y en cualquier archivo listado en los atributos configSource.

Cuenta de Windows

Permisos

Administradores

Control completo

IIS_WPG (<servidor>\IIS_WPG)

Lectura y ejecución

INTERACTIVE

Leer

Cuenta de invitado de Internet (<servidor>\IUSR_<servidor>)

Leer

NETWORK

Leer

NETWORK SERVICE

Leer

SYSTEM

Control completo

Usuarios (<servidor>\Users)

Lectura y ejecución

Cuenta de Herramienta Administración de sitios Web en ASP.NET

Especial

El sistema de la configuración de ASP.NET admite las ACL que se establecen en archivos de configuración, independientemente de cómo se editen las opciones de configuración. Para obtener más información, vea Editar los archivos de configuración de ASP.NET.

Cuando almacene información confidencial en un archivo de configuración de una aplicación, debe cifrar los valores confidenciales mediante una configuración protegida. Entre la información especialmente confidencial se encuentran las claves de cifrado almacenadas en el elemento de configuración machineKey y las cadenas de conexión a un origen de datos almacenadas en el elemento de configuración connectionStrings. Para obtener más información, vea Cifrar información de configuración mediante una configuración protegida.

Proteger los contenedores de claves de cifrado de la configuración

Un aspecto crítico de utilizar una clave de cifrado es la protección del archivo, también denominado contenedor, en el que se almacena la clave. Es importante tener presente el nivel de protección asociado al contenedor. Observe que el contenedor se almacena en un sistema normal del sistema operativo y que el acceso a la clave de acceso lo regulan las ACL en el archivo. Las ACL se pueden heredar de la carpeta donde se crea el archivo. Los contenedores de claves con ámbito de equipo local (useMachineContainer"true") se almacenan en una carpeta oculta en %TODOS LOS PERFILES DE USUARIO%\Application Data\Microsoft\Crypto\RSA\MachineKeys.

De forma predeterminada, el usuario que creó el contenedor de claves tendrá acceso total a la clave. Los demás usuarios (incluido el grupo de administradores) pueden o no pueden tener acceso al contenedor, dependiendo del conjunto de ACL en el contenedor. Los demás usuarios pueden obtener acceso al contenedor mediante el modificador –pa de la Herramienta Registro de IIS para ASP.NET (Herramienta Registro de IIS en ASP.NET (Aspnet_regiis.exe)). Los usuarios que intenten cifrar o descifrar con la clave especificada deberán tener los permisos necesarios para obtener acceso al contenedor de claves.

En algunos casos, un usuario que no tenga privilegios administrativos podrá crear, no obstante, una clave de cifrado. Esto puede suceder si una aplicación solicita un cifrado de configuración cuando una clave no existe. Observe que el contenedor se creará si no existe y que se ejecutará una operación de cifrado.

En este caso, .NET Framework creará la clave necesaria así como el contenedor relacionado con las ACL del usuario actual. El problema en este caso es que a un usuario con privilegios administrativos se le puede denegar el acceso al contenedor de claves de cifrado. Los administradores pueden recobrar el acceso a la clave tomando propiedad del archivo físico en la carpeta arriba mencionada. Las instrucciones sugeridas llaman a un usuario con privilegios administrativos para que se creen las claves necesarias antes de su uso y, por lo tanto, evitan su creación en tiempo de cifrado.

En un entorno de hospedaje compartido, los usuarios malintencionados podrán modificar las opciones de configuración mediante modificaciones directas de los archivos de configuración, modificaciones a través de las API de configuración así como otras herramientas de administración y configuración. Puede ayudar a impedir las modificaciones en la configuración de la aplicación bloqueando las secciones de configuración. Esto se hace agregando elementos location al archivo Machine.config o a cualquier archivo de configuración que se encuentre en un nivel de la jerarquía superior al del archivo de configuración al que desea limitar el acceso. El elemento location se utiliza para impedir que los archivos de configuración secundarios modifiquen la configuración. Para obtener más información, vea Cómo: Bloquear los valores de configuración de ASP.NET y Cómo: Configurar directorios concretos mediante la configuración de la ubicación.

La configuración remota está deshabilitada de manera predeterminada. Cuando está habilitada, el usuario se autentica en el nivel de DCOM y sólo los administradores locales están autorizados a leer o escribir datos de configuración. Para obtener más información, vea Editar los archivos de configuración remotos de ASP.NET.

Independientemente del símbolo (token) de seguridad del usuario actual, se ejecuta el código del controlador de secciones personalizado mediante las credenciales de la cuenta del proceso de hospedaje. Para escenarios web, ésta es la cuenta <servidor>\ASPNET en Windows 2000 y Windows XP, la cuenta NETWORK SERVICE en Windows Server 2003 o una cuenta de usuario configurada explícitamente. Para escenarios de clientes, ésta es la identidad del proceso que se está ejecutando actualmente.

El sistema de configuración establece permisos antes de llamar a un controlador de secciones de configuración personalizado y la llamada no es en absoluto de confianza para .NET Framework. La llamada se ejecuta con el permiso de confianza de la aplicación. El sistema de configuración de ASP.NET confía en el directorio %RaízSistema%\Microsoft.NET\Framework\versión\CONFIG, pero no confía en directorios que se encuentran en un nivel inferior de la jerarquía.

Un controlador de secciones de configuración personalizado debe establecer los atributos de solicitud de seguridad de acceso a código (CAS) para obtener los permisos. Para obtener más información, vea Seguridad de acceso a código de ASP.NET o Conceptos básicos sobre la seguridad de acceso a código.

Contener un bloqueo de archivo en un archivo de configuración

Sólo varios intentos de guardar en un archivo de configuración o de abrir un identificador de archivo pueden bloquear un archivo de configuración. Un usuario malintencionado puede intentar bloquear el archivo Machine.config o el archivo Web.config raíz pero para ello se necesita plena confianza, la cual está deshabilitada de forma predeterminada en ASP.NET.

Utilizar la API de configuración para leer archivos arbitrarios

Las clases de la API de configuración no pueden leer ningún directorio que no forme parte del dominio de aplicación o ningún archivo que no tenga una extensión de nombre de archivo .config.

Cuando IIS recibe una solicitud de una aplicación ASP.NET, las configuraciones de metabase IIS se aplican a la aplicación ASP.NET independientemente de las opciones de configuración de ASP.NET para esta aplicación. Esta restricción puede hacer que las aplicaciones ASP.NET sean inaccesibles para los usuarios o tengan una configuración de seguridad menos restrictiva.

Por ejemplo, si la configuración de seguridad de la metabase IIS está establecida en permitir sólo el acceso al sitio a los usuarios autenticados mientras la configuración de seguridad del archivo Web.config está establecida en permitir el acceso anónimo al sitio, se negará el acceso al sitio a los usuarios anónimos. Para resolver esto, debe configurar la aplicación Web en el Administrador IIS para que permita el acceso a los usuarios anónimos.

Para obtener más información sobre cómo proteger las características de IIS, vea Seguridad en IIS 6.0.

En las secciones siguientes se explica cómo mitigar los riesgos de seguridad potenciales a los que se expone por eventos y mensajes de error inesperados.

Excepciones

Para evitar que la información confidencial pueda verse en orígenes no deseados, configure la aplicación para que no muestre mensajes de error detallados o para que muestre estos mensajes únicamente cuando el cliente es el propio servidor Web. Para obtener más información, vea Elemento customErrors (Esquema de configuración de ASP.NET).

Registro de eventos

Si el servidor está ejecutando Windows Server 2003, puede mejorar la seguridad de la aplicación protegiendo el registro de eventos y estableciendo parámetros relativos al tamaño, la retención y otras características del registro de eventos con el fin de evitar un ataque de denegación de servicio indirecto. Para obtener más información sobre la configuración de registros de eventos, busque "Visor de eventos" o "Event Viewer" en Ayuda y soporte técnico de Windows.

Supervisión de estado

Los intentos de inicio de sesión que se realizan correctamente o en los que se producen errores se registran en la característica de supervisión de estado de ASP.NET. En la configuración predeterminada, esto significa que los intentos de inicio de sesión incorrectos incluirán el nombre de usuario y otra información de diagnóstico en el registro de eventos de la aplicación. Compruebe que el acceso al registro de eventos esta restringido para proteger esta información.

Mostrar: