Proteger páginas de elementos Web

Artículo
10/22/2014

Actualización: noviembre 2007

Los elementos Web conforman la nueva característica de ASP.NET que proporciona a los usuarios finales la posibilidad de modificar o personalizar páginas Web. Disponer de páginas Web personalizadas ofrece muchas posibilidades a los usuarios de las aplicaciones Web, pero también tiene unas repercusiones en la seguridad que los desarrolladores deberían conocer.

Problemas de seguridad de elementos Web

Como los elementos Web son una característica de ASP.NET y los controles de elementos Web forman parte de los controles de servidor ASP.NET, las páginas de elementos Web son susceptibles a los mismos riesgos que las páginas ASP.NET. Una aplicación Web con páginas que utilice controles de elementos Web no es más que un tipo especializado de aplicación ASP.NET y una aplicación que utilice elementos Web puede ejecutarse en los mismos niveles de confianza que cualquier aplicación ASP.NET. Para obtener información general sobre la seguridad del sitio Web ASP.NET, vea Proteger sitios web ASP.NET. Sin embargo, los elementos Web tienen algunos problemas de seguridad únicos que las páginas normales ASP.NET no tienen. Estos problemas se tratan en las siguientes secciones.

Importación de datos de control

La característica de elementos Web con mayores riesgos de seguridad es la característica de importación. Esta característica permite al usuario importar un archivo de descripción XML que contenga datos sobre el estado y la propiedad para un control de servidor (el archivo de ensamblado del control ya debe estar disponible en el servidor Web). La importación de datos para controles permite a los usuarios compartir datos y configurar fácilmente controles complejos. Pero el riesgo inherente es que podría haber datos malintencionados en el archivo de descripción. Por ejemplo, si alguien ha colocado código de secuencia de comandos malintencionada como el valor de una propiedad de cadena en el archivo de descripción, entonces esa secuencia de comandos malintencionada podría ejecutarse cuando un usuario importara el archivo de descripción y agregara el control del servidor al que se ha hecho referencia a una página Web. Para minimizar el riesgo de importar archivos de descripción con datos malintencionados, los controles de servidor que tengan propiedades de tipo cadena siempre deberían codificar los datos de propiedad. Otro riesgo sería importar tipos mediante archivos de descripción (vea Archivos de descripción de controles de elementos Web). Un usuario malintencionado podría enviar solicitudes para cargar muchos ensamblados en AppDomain, provocando así un elevado consumo de memoria. Para evitar los riesgos asociados con las importaciones, basta con no utilizar el control de servidor que implementa la característica para desactivarla. O se puede limitar a los usuarios que tienen acceso al control. Por ejemplo, se puede utilizar la administración de funciones y si un usuario desempeña la función de administrador, se puede agregar ImportCatalogPart mediante programación a la página para ese usuario. Para obtener más información sobre el control, vea el tema de referencia para la clase ImportCatalogPart.

Exportación de datos de control

La característica de exportación tiene casi las mismas probabilidades de riesgo que la importación porque puede exponer datos confidenciales. La exportación permite a los usuarios guardar los datos de la propiedad y el estado para un control en particular en un archivo de descripción XML. (Este es el mismo archivo que se puede importar mediante la característica de importación.) El principal riesgo que conlleva es que los usuarios pueden exportar datos confidenciales de una aplicación a un archivo de descripción, que es un archivo de texto simple que cualquier usuario con los permisos adecuados puede leer. De forma predeterminada, la característica de exportación en ASP.NET está deshabilitada, por lo que si no es necesaria, se puede omitir con seguridad. Claramente esta es la opción más segura.

Si desea habilitar la característica de exportación, debe tener en cuenta las opciones para determinar las opciones que se pueden exportar. Cuando crea WebPart o control de servidor que se va a utilizar en una zona WebPartZone, para cada propiedad pública que desee hacer exportable, puede agregar el atributo Personalizable de metadatos. Esto hace que la propiedad sea exportable si la característica de exportación está habilitada a la vez que muestra al usuario un cuadro de mensaje advirtiendo que se van a exportar los datos. Uno de los parámetros del atributo Personalizable se llama IsSensitive. Este parámetro booleano es útil si tiene una propiedad que desea que sea exportable en algunas situaciones pero no en otras. Para obtener detalles y un ejemplo, vea el tema de referencia de la propiedad ExportMode.

Descripción de los detalles de personalización

La personalización de elementos Web es la característica que permite a los usuarios modificar las páginas Web para adaptarlas a sus preferencias y almacenar su configuración a largo plazo, de modo que las páginas personalizadas guarden los valores de las distintas sesiones del explorador. La mayoría de las características de elementos Web requieren personalización; por lo tanto, está activado de forma predeterminada en los sitios Web ASP.NET, aunque sólo se utilice en páginas que contengan controles de elementos Web. Al ser la personalización una característica tan importante, también conlleva cierto grado de riesgo. Los usuarios pueden modificar el diseño, el aspecto e incluso el contenido y los controles de un página Web. Los datos de personalización se almacenan en una base de datos y se utilizan para representar páginas, de forma que los usuarios tienen un gran riesgo de actividad malintencionada en relación con el contenido de un sitio. Los usuarios que tienen acceso al ámbito de personalización compartida pueden incluso cambiar la manera en que las páginas se muestran a todos los usuarios.

Si tiene una página en particular que utiliza características de elementos Web pero no requiere personalización (por ejemplo, una de las páginas comunes de un portal), es conveniente deshabilitar la personalización porque mejora el rendimiento y reduce la exposición del sitio a riesgos de seguridad. Para obtener más información, vea Cómo: Deshabilitar la personalización de elementos Web.

Autenticación de usuarios para personalización

La personalización requiere usuarios autenticados. No puede habilitar personalización para usuarios anónimos. Esto supone que para tener una personalización completa y funcionalidad de los elementos Web, su sitio Web debe utilizar autenticación basada en Windows o en formularios. Para obtener información sobre las opciones de autenticación, vea Procedimientos de seguridad básicos para aplicaciones web ASP.NET. Para configurar un sitio mediante la nueva característica de suscripción (que utiliza autenticación de formularios), vea Administrar usuarios mediante suscripciones.

Concesión de acceso mínimo a personalización compartida

Los cambios de personalización de elementos Web siempre se aplican a un intervalo dado o ámbito de usuario. Los cambios realizados en un ámbito de usuario sólo son visibles para el usuario que realiza los cambios, mientras que los cambios realizados en un ámbito compartido son visibles para todos los usuarios. El ámbito de personalización compartido existe para que los usuarios que desempeñan una función de gestión o administrativa puedan realizar cambios a una página que afecta a todos los usuarios de un sitio. De forma predeterminada, a todos los usuarios se les niega el acceso a los ámbitos compartidos. Sólo los usuarios seleccionados deben recibir acceso, lo cual se ha de realizar explícitamente en un archivo de configuración de un sitio Web. Para obtener información detallada, vea Cómo: Habilitar la personalización compartida de páginas de elementos Web.

Utilización de controles probados y de confianza

Dado que los elementos Web proporcionan a los usuarios funciones eficaces, como por ejemplo, la posibilidad de agregar nuevos controles de servidor a una página, los desarrolladores deben tener mucho cuidado con los controles de servidor que utilizan dentro de una aplicación de elementos Web. Los controles de servidor, especialmente aquellos de terceros o proveedores, deben revisarse y probarse con mucho cuidado para asegurarse de que se pueden utilizar en una aplicación de elementos Web. Por ejemplo, supongamos un determinado control de servidor que esté mal diseñado y sea ineficaz en el uso de su memoria. Si agrega dicho control a un catálogo de elementos Web, los usuarios pueden agregarlo a una página Web. Y puesto que un control de un catálogo se puede agregar a una página muchas veces (varias instancias), un usuario podría agregar el control que no funciona correctamente varias veces, que podría generar de forma efectiva un ataque de denegación de servicio cuando la página intente procesar muchas instancias del control. Para obtener más información sobre los catálogos de elementos Web, vea el tema de referencia para la clase CatalogPart.

Utilización de autorización y filtro en controles

Los elementos Web tienen una característica que permite al usuario establecer y comprobar el nivel de autorización para los controles de servidor que se utilizan para crear la interfaz de usuario (UI) de sus páginas de elementos Web. Si un control está autorizado según los criterios establecidos, aparecerá en la página, y si está autorizado en un nivel más reducido o no tiene autorización, puede cambiar su apariencia en consecuencia u ocultarlo del todo. Por ejemplo, suponga que tiene un usuario designado como administrador. Es posible que haya un control de servidor que desee que esté visible sólo para el administrador. Mediante las características de autorización y filtro de los elementos Web, podría asegurarse de que este control sólo le aparezca a un administrador designado y esté oculto para los demás usuarios. Los mecanismos principales para la utilización de autorización y filtro son la propiedad AuthorizationFilter de la clase WebPart, y los métodos IsAuthorized y OnAuthorizeWebPart de la claseWebPartManager.

Codificación de propiedades de tipo cadena en controles de edición

Una característica única de elementos Web es que los usuarios finales pueden cambiar una página a modo de edición y pueden editar un control de servidor cambiando su diseño, aspecto, comportamiento y los valores de propiedad personalizables. Pero esto presenta algunos riesgos, puesto que un usuario malintencionado podría insertar datos inapropiados o intentar un ataque de inyección de secuencia de comandos aprovechando la posibilidad de editar propiedades de tipo cadena. Como medida de seguridad, si crea controles EditorPart personalizados para editar controles de servidor, y si alguna de las propiedades personalizables de un control de servidor determinado es de tipo de cadena o utiliza un convertidor de cadena, el control EditorPart debe codificar los datos de cadena antes de asignarlos a la propiedad. Por ejemplo, consulte la documentación de referencia sobre el método HtmlEncode.

Compartir a través de