Estrategia de seguridad de WPF: seguridad de la plataforma

Aunque Windows Presentation Foundation (WPF) proporciona una variedad de servicios de seguridad, también aprovecha las características de seguridad de la plataforma subyacente, que incluye el sistema operativo, CLR e Internet Explorer. Estas capas se combinan para proporcionar a WPF un modelo de seguridad fuerte y de defensa en profundidad que intenta evitar cualquier único punto de error, como se muestra en la ilustración siguiente:

En el resto de este tema se describen las características de cada una de estas capas que pertenecen específicamente a WPF.

Seguridad del sistema operativo

El núcleo de Windows proporciona varias características de seguridad que forman la base de seguridad para todas las aplicaciones de Windows, incluidas las compiladas con WPF. En este tema se describe la amplitud de estas características de seguridad que son importantes para WPF, así como la forma en que WPF se integra con ellas para proporcionar más defensa en profundidad.

Microsoft Windows XP Service Pack 2 (SP2)

Además de una revisión general y el fortalecimiento de Windows, hay tres características clave de Windows XP SP2 que analizaremos en este tema:

• Compilación de /GS

• Microsoft Windows Update.

Compilación /GS

Windows XP SP2 proporciona protección al volver a compilar muchas bibliotecas principales del sistema, incluidas todas las dependencias de WPF, como CLR, para ayudar a mitigar las saturaciones del búfer. Esto se logra mediante el uso del parámetro /GS con el compilador de línea de comandos de C/C++. Aunque se deben evitar explícitamente los desbordamientos de búfer, la compilación /GS proporciona un ejemplo de una defensa en profundidad frente a posibles vulnerabilidades que se crean involuntariamente o malintencionadamente por ellos.

Históricamente, las saturaciones de búfer han sido la causa de muchas vulnerabilidades de seguridad de alto impacto. Una saturación del búfer se produce cuando un atacante aprovecha una vulnerabilidad de código que permite la inyección de código malintencionado que escribe más allá de los límites de un búfer. Esto permite a un atacante secuestrar el proceso en el que se ejecuta el código al sobrescribir la dirección de retorno de una función para provocar la ejecución del código del atacante. El resultado es código malintencionado que ejecuta código arbitrario con los mismos privilegios que el proceso secuestrado.

A un alto nivel, la marca del compilador -GS protege contra algunos desbordamientos de búfer potenciales mediante la inserción de un token de seguridad especial para proteger la dirección de retorno de una función que tiene búferes de cadenas locales. Una vez que se devuelve una función, la cookie de seguridad se compara con su valor anterior. Si el valor ha cambiado, es posible que se haya producido una saturación del búfer y el proceso se detenga con una condición de error. Detener el proceso impide la ejecución de código potencialmente malintencionado. Consulte -GS (Comprobación de seguridad del búfer) para obtener más detalles.

WPF se compila con la marca /GS para agregar otra capa de defensa a las aplicaciones WPF.

Windows Vista

Los usuarios de WPF en Windows Vista se beneficiarán de las mejoras de seguridad adicionales del sistema operativo, incluidas "Least-Privilege acceso de usuario", comprobaciones de integridad de código y aislamiento de privilegios.

Control de cuentas de usuario (UAC)

En la actualidad, los usuarios de Windows tienden a ejecutarse con privilegios de administrador porque muchas aplicaciones las requieren para la instalación o la ejecución, o ambas. La capacidad de escribir la configuración predeterminada de la aplicación en el Registro es un ejemplo.

La ejecución con privilegios de administrador significa realmente que las aplicaciones se ejecutan desde procesos a los que se conceden privilegios de administrador. El impacto en la seguridad de esto es que cualquier código malintencionado que secuestre un proceso que se ejecuta con privilegios de administrador heredará automáticamente esos privilegios, incluido el acceso a los recursos críticos del sistema.

Una manera de protegerse contra esta amenaza de seguridad es ejecutar aplicaciones con la menor cantidad de privilegios necesarios. Esto se conoce como el principio de privilegios mínimos y es una característica principal del sistema operativo Windows. Esta característica se denomina Control de cuentas de usuario (UAC) y la usa Windows UAC de dos maneras clave:

• Para ejecutar la mayoría de las aplicaciones con privilegios de UAC de forma predeterminada, incluso si el usuario es administrador; solo las aplicaciones que necesitan privilegios de administrador se ejecutarán con privilegios de administrador. Para ejecutarse con privilegios administrativos, las aplicaciones deben marcarse explícitamente en su manifiesto de aplicación o como entrada en la directiva de seguridad.

• Para proporcionar soluciones de compatibilidad como la virtualización. Por ejemplo, muchas aplicaciones intentan escribir en ubicaciones restringidas como C:\Archivos de programa. Para las aplicaciones que se ejecutan en UAC, existe una ubicación alternativa por usuario que no requiere privilegios de administrador para escribir. Para las aplicaciones que se ejecutan bajo UAC, este mecanismo virtualiza C:\Archivos de programa de modo que las aplicaciones que creen que están escribiendo allí, en realidad lo hacen en una ubicación alternativa específica por usuario. Este tipo de trabajo de compatibilidad permite al sistema operativo ejecutar muchas aplicaciones que no se podían ejecutar previamente en UAC.

Comprobaciones de integridad de código

Windows Vista incorpora comprobaciones de integridad de código más profundas para ayudar a evitar que el código malintencionado se inserte en archivos del sistema o en el kernel en tiempo de carga o ejecución. Esto va más allá de la protección de archivos del sistema.

Proceso de derechos restringidos para aplicaciones de Browser-Hosted

Las aplicaciones WPF hospedadas en el explorador se ejecutan dentro del espacio aislado de la zona de Internet. La integración de WPF con Microsoft Internet Explorer amplía esta protección con compatibilidad adicional.

Dado que las aplicaciones de explorador XAML (XBAPs) están generalmente restringidas por el conjunto de permisos de la zona de Internet, quitar estos privilegios no afecta a las aplicaciones de explorador XAML (XBAPs) desde la perspectiva de compatibilidad. En su lugar, se crea una capa de defensa en profundidad adicional; si una aplicación de espacio aislado puede aprovechar otras capas y secuestrar el proceso, el proceso solo tendrá privilegios limitados.

Consulte Uso de una cuenta de usuario de Least-Privileged.

Seguridad de Common Language Runtime

Common Language Runtime (CLR) ofrece una serie de ventajas clave de seguridad que incluyen validación y verificación, Seguridad de acceso a código (CAS) y metodología crítica de seguridad.

Validación y comprobación

Para proporcionar el aislamiento y la integridad de los ensamblados, el CLR utiliza un proceso de validación. La validación CLR garantiza que los ensamblados estén aislados, validando su formato de archivo Portable Executable (PE) para direcciones que apuntan fuera del ensamblado. La validación de CLR también valida la integridad de los metadatos incrustados en un ensamblado.

Para garantizar la seguridad de tipos, ayudar a evitar problemas comunes de seguridad (por ejemplo, saturaciones de búfer) y habilitar el aislamiento mediante subprocesos, la seguridad CLR utiliza el concepto de verificación.

Las aplicaciones administradas se compilan en lenguaje intermedio de Microsoft (MSIL). Cuando se ejecutan métodos en una aplicación administrada, su MSIL se compila en código nativo mediante la compilación Just-In-Time (JIT). La compilación JIT incluye un proceso de comprobación que aplica muchas reglas de seguridad y solidez que garantizan que el código no:

• Violaciones de contratos de tipo

• Introducción de saturaciones de búfer

• Acceder a la memoria de forma incontrolada.

El código administrado que no se ajusta a las reglas de verificación no puede ejecutarse, a menos que se considere código de confianza.

La ventaja del código verificable es una razón clave por la que WPF se basa en .NET Framework. En la medida en que se usa el código verificable, se reduce considerablemente la posibilidad de aprovechar posibles vulnerabilidades.

Seguridad de acceso del código

Un equipo cliente expone una amplia variedad de recursos a los que una aplicación administrada puede tener acceso, incluido el sistema de archivos, el Registro, los servicios de impresión, la interfaz de usuario, la reflexión y las variables de entorno. Para que una aplicación administrada pueda acceder a cualquiera de los recursos de un equipo cliente, debe tener permiso de .NET Framework para hacerlo. Un permiso en CAS es una subclase de ; CodeAccessPermission CAS implementa una subclase para cada recurso al que pueden acceder las aplicaciones administradas.

El conjunto de permisos que un CAS concede a una aplicación administrada cuando comienza a ejecutarse se conoce como un conjunto de permisos y viene determinado por la evidencia proporcionada por la aplicación. En el caso de las aplicaciones WPF, la evidencia proporcionada es la ubicación o zona desde la que se inician las aplicaciones. CAS identifica las siguientes zonas:

• Mi computadora. Aplicaciones iniciadas desde la máquina cliente (totalmente de confianza).

• Intranet local. Aplicaciones iniciadas desde la intranet. Moderadamente fiable

• Internet. Aplicaciones iniciadas desde Internet. (Menos de confianza).

• Sitios de confianza. Aplicaciones identificadas por un usuario como de confianza. (Menos de confianza).

• Sitios que no son de confianza. Aplicaciones identificadas por un usuario como que no son de confianza. (No es de confianza).

Para cada una de estas zonas, CAS proporciona un conjunto de permisos predefinido que incluye los permisos que coinciden con el nivel de confianza asociado a cada una. Estos incluyen:

• FullTrust. Para las aplicaciones iniciadas desde la zona Mi pc . Se conceden todos los permisos posibles.

• LocalIntranet. Para las aplicaciones iniciadas desde la zona intranet local . Se concede un subconjunto de permisos para proporcionar acceso moderado a los recursos de una máquina cliente, incluido el almacenamiento aislado, el acceso a la interfaz de usuario sin restricciones, los diálogos de archivos sin restricciones, la reflexión limitada y el acceso limitado a las variables de entorno. No se proporcionan permisos para recursos críticos, como el Registro.

• Internet. Para las aplicaciones iniciadas desde internet o desde la zona sitios de confianza . Se concede un subconjunto de permisos para proporcionar acceso limitado a los recursos de una máquina cliente, incluido el almacenamiento aislado, el archivo abierto solo y la interfaz de usuario limitada. Básicamente, este conjunto de permisos aísla las aplicaciones de la máquina cliente.

Las aplicaciones identificadas como procedentes de la zona Sitios que no son de confianza no tienen permisos de CAS en absoluto. Por lo tanto, no existe un conjunto de permisos predefinido para ellos.

En la ilustración siguiente se muestra la relación entre zonas, conjuntos de permisos, permisos y recursos:

Las restricciones del espacio aislado de seguridad de la zona de Internet se aplican igualmente a cualquier código que un XBAP importe desde una biblioteca del sistema, incluido WPF. Esto garantiza que todos los bits del código están bloqueados, incluso WPF. Desafortunadamente, para ejecutar un XBAP, se necesita emplear funciones que requieren más permisos que los habilitados por el entorno seguro de la zona de Internet.

Considere una aplicación XBAP que incluya la página siguiente:

FileIOPermission fp = new FileIOPermission(PermissionState.Unrestricted);
fp.Assert();

// Perform operation that uses the assert

// Revert the assert when operation is completed
CodeAccessPermission.RevertAssert();

Dim fp As New FileIOPermission(PermissionState.Unrestricted)
fp.Assert()

' Perform operation that uses the assert

' Revert the assert when operation is completed
CodeAccessPermission.RevertAssert()

Para ejecutar este XBAP, el código WPF subyacente debe ejecutar más funcionalidades de las que están disponibles para el XBAP que llama, entre las que se incluyen:

• Creación de un identificador de ventana (HWND) para el renderizado

• Envío de mensajes

• Carga de la fuente Tahoma

Desde un punto de vista de seguridad, permitir el acceso directo a cualquiera de estas operaciones desde la aplicación de espacio aislado sería catastrófico.

Afortunadamente, WPF atiende esta situación al permitir que estas operaciones se ejecuten con privilegios elevados en nombre de la aplicación de espacio aislado. Aunque todas las operaciones de WPF se comprueban con los permisos de seguridad de zona de Internet limitados del dominio de aplicación de XBAP, WPF (como con otras bibliotecas del sistema) se concede un conjunto de permisos que incluye todos los permisos posibles.

Esto requiere que WPF reciba privilegios elevados a la vez que impide que esos privilegios se rijan por el conjunto de permisos de zona de Internet del dominio de aplicación host.

WPF lo hace mediante el método Assert de un permiso. En el código siguiente se muestra cómo sucede esto.

FileIOPermission fp = new FileIOPermission(PermissionState.Unrestricted);
fp.Assert();

// Perform operation that uses the assert

// Revert the assert when operation is completed
CodeAccessPermission.RevertAssert();

Dim fp As New FileIOPermission(PermissionState.Unrestricted)
fp.Assert()

' Perform operation that uses the assert

' Revert the assert when operation is completed
CodeAccessPermission.RevertAssert()

La aserción impide esencialmente que los permisos ilimitados requeridos por WPF se vean restringidos por los permisos de la zona Internet del XBAP.

Desde una perspectiva de la plataforma, WPF es responsable de usar Assert correctamente; Un uso incorrecto de Assert podría permitir que el código malintencionado elevara los privilegios. Por lo tanto, es importante llamar únicamente a Assert cuando sea necesario y asegurarse de que las restricciones de espacio aislado se mantengan intactas. Por ejemplo, el código con restricciones de ejecución no puede abrir archivos aleatorios, pero se permite usar fuentes. WPF permite que las aplicaciones de espacio aislado usen la funcionalidad de fuentes llamando a Assert y para que WPF lea archivos conocidos que contienen esas fuentes en nombre de la aplicación de espacio aislado.

Implementación de ClickOnce

ClickOnce es una tecnología de implementación completa que se incluye con .NET Framework y se integra con Visual Studio (consulte Seguridad e implementación de ClickOnce para obtener información detallada). Las aplicaciones WPF independientes se pueden implementar mediante ClickOnce, mientras que las aplicaciones hospedadas en el explorador deben implementarse con ClickOnce.

Las aplicaciones implementadas mediante ClickOnce reciben una capa de seguridad adicional sobre seguridad de acceso al código (CAS); básicamente, las aplicaciones implementadas de ClickOnce solicitan los permisos que necesitan. Solo se conceden esos permisos si no superan el conjunto de permisos para la zona desde la que se implementa la aplicación. Al reducir el conjunto de permisos a solo los necesarios, incluso si son menores que los proporcionados por el conjunto de permisos de la zona de inicio, el número de recursos a los que la aplicación tiene acceso se reduce a un mínimo. Por lo tanto, si se secuestra la aplicación, se reduce la posibilidad de daños en la máquina cliente.

Metodología de Security-Critical

El código WPF que emplea permisos para habilitar el sandbox de la zona de Internet para las aplicaciones XBAP debe someterse al más alto grado posible de auditoría y control de seguridad. Para facilitar este requisito, .NET Framework proporciona nueva compatibilidad para administrar código que eleva los privilegios. En concreto, CLR le permite identificar el código que eleva los privilegios y marcarlo con SecurityCriticalAttribute; cualquier código no marcado con SecurityCriticalAttribute se convierte en transparente mediante esta metodología. Por el contrario, se impide que el código administrado que no esté marcado con SecurityCriticalAttribute pueda elevar privilegios.

La metodología Security-Critical permite organizar el código WPF que eleva privilegios en el kernel crítico para la seguridad, mientras que el resto permanece transparente. Aislar el código crítico para la seguridad permite al equipo de ingeniería de WPF centrarse en un análisis de seguridad adicional y control de código fuente en el kernel crítico para la seguridad anterior y más allá de los procedimientos de seguridad estándar (consulte Estrategia de seguridad de WPF - Ingeniería de seguridad).

Tenga en cuenta que .NET Framework permite que el código de confianza extienda el espacio aislado de la zona de Internet XBAP al permitir que los desarrolladores escriban ensamblados administrados marcados con AllowPartiallyTrustedCallersAttribute (APTCA) e implementados en la caché global de ensamblados (GAC) del usuario. Marcar un ensamblado con APTCA es una operación de seguridad altamente confidencial, ya que permite que cualquier código llame a ese ensamblado, incluido el código malintencionado de Internet. Debe usarse extrema precaución y procedimientos recomendados al hacerlo y los usuarios deben elegir confiar en ese software para que se instale.

Seguridad de Microsoft Internet Explorer

Además de reducir los problemas de seguridad y simplificar la configuración de seguridad, Microsoft Internet Explorer 6 (SP2) contiene varias características que mejoran la seguridad para los usuarios de aplicaciones de explorador XAML (XBAP). El impulso de estas características intenta permitir a los usuarios un mayor control sobre su experiencia de exploración.

Antes de IE6 SP2, los usuarios podrían estar sujetos a cualquiera de las siguientes opciones:

• Ventanas emergentes aleatorias.

• Redirección de scripts confusa.

• Numerosos diálogos de seguridad en algunos sitios web.

En algunos casos, los sitios web no confiables intentarían engañar a los usuarios mediante la suplantación de la interfaz de usuario de instalación (UI) o mostrar repetidamente un cuadro de diálogo de instalación de Microsoft ActiveX, aunque el usuario lo haya cancelado. Con estas técnicas, es posible que se haya engañado a un número significativo de usuarios para tomar decisiones deficientes que dieron lugar a la instalación de aplicaciones spyware.

IE6 SP2 incluye varias características para mitigar estos tipos de problemas, que giran en torno al concepto de inicio del usuario. IE6 SP2 detecta cuándo un usuario ha realizado clic en un vínculo o elemento de página antes de una acción, que se conoce como inicio del usuario, y lo trata de forma diferente que cuando el script desencadena una acción similar en su lugar en una página. Por ejemplo, IE6 SP2 incorpora un bloqueador dePop-Up que detecta cuándo un usuario hace clic en un botón antes de crear un elemento emergente en la página. Esto permite que IE6 SP2 permita la mayoría de las ventanas emergentes inofensivas, a la vez que impide los elementos emergentes no solicitados ni deseados. Los elementos emergentes bloqueados están atrapados en la nueva barra de información, lo que permite al usuario anular manualmente el bloqueo y visualizar el elemento emergente.

La misma lógica de inicio de usuario también se aplica a los avisos de seguridad de Open/Save . Los cuadros de diálogo de instalación de ActiveX siempre están atrapados en la barra de información a menos que representen una actualización de un control instalado previamente. Estas medidas se combinan para proporcionar a los usuarios una experiencia de usuario más segura y controlada, ya que están protegidas contra sitios que los acosan para instalar software no deseado o malintencionado.

Estas características también protegen a los clientes que usan IE6 SP2 para navegar a sitios web que les permiten descargar e instalar aplicaciones WPF. En concreto, esto se debe a que IE6 SP2 ofrece una mejor experiencia de usuario que reduce la posibilidad de que los usuarios instalen aplicaciones malintencionadas o desviadas independientemente de la tecnología que se usó para compilarla, incluido WPF. WPF agrega estas protecciones mediante ClickOnce para facilitar la descarga de sus aplicaciones a través de Internet. Dado que las aplicaciones de navegador XAML (XBAPs) se ejecutan dentro de un entorno de seguridad de la zona de Internet, se pueden iniciar sin problemas. Por otro lado, las aplicaciones WPF independientes requieren plena confianza para ejecutarse. Para estas aplicaciones, ClickOnce mostrará un cuadro de diálogo de seguridad durante el proceso de inicio para notificar al uso de los requisitos de seguridad adicionales de la aplicación. Sin embargo, esto debe iniciarse por el usuario, también se regirá por la lógica iniciada por el usuario y se puede cancelar.

Internet Explorer 7 incorpora y amplía las funcionalidades de seguridad de IE6 SP2 como parte de un compromiso continuo con la seguridad.

Consulte también

• Seguridad de acceso al código
• Seguridad
• Seguridad de confianza parcial de WPF
• Estrategia de seguridad de WPF: ingeniería de seguridad