Estrategia de seguridad de WPF: Seguridad de plataforma
A la vez que Windows Presentation Foundation (WPF) proporciona una gran variedad de servicios de seguridad, también aprovecha las características de seguridad de la plataforma subyacente, entre las que se incluyen el sistema operativo, CLR e Internet Explorer. Estas capas se combinan para proporcionar a WPF un modelo de seguridad sólido y profundo que intenta evitar todos los puntos flacos, como se muestra en la ilustración siguiente:
Diagrama en el que se muestra el modelo de seguridad de WPF.
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 de todas las aplicaciones de Windows, incluidas aquellas creadas con WPF. En este tema se aborda el alcance de estas características de seguridad que son importantes para WPF, así como la integración de WPF con ellas para ofrecer una mayor defensa en profundidad.
Microsoft Windows XP Service Pack 2 (SP2)
Además de realizar un análisis y un refuerzo general de Windows, en este tema estudiaremos tres características clave de Windows XP SP2:
Compilación /GS
Microsoft Windows Update.
Compilación /GS
Windows XP SP2 proporciona protección mediante la recopilación de muchas bibliotecas de sistema principales, incluidas todas las dependencias de WPF como el CLR, para ayudar a mitigar las saturaciones del búfer. Esto se logra usando el parámetro /GS con el compilador de línea de comandos de C o C++. Aunque las saturaciones del búfer se deben evitar de manera explícita, la compilación /GS proporciona un ejemplo de una defensa en profundidad contra posibles vulnerabilidades creadas por dichas saturaciones de forma accidental o malintencionada.
Históricamente, las saturaciones del búfer han sido la causa de muchas vulnerabilidades de seguridad de gran impacto. Una saturación del búfer se produce cuando un atacante aprovecha una vulnerabilidad de código que permite la inserció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; para ello, se sobrescribe la dirección de retorno de una función para que se ejecute el código del atacante. El resultado es un código malintencionado que ejecuta código arbitrario con los mismos privilegios que el proceso atacado.
En un nivel alto, la marca del compilador -GS protege contra algunas saturaciones del búfer potenciales mediante la inserción de una cookie de seguridad especial que protege la dirección de retorno de una función que tiene búferes de cadena locales. Una vez que se devuelve una función, la cookie de seguridad se compara con su valor anterior. Si el valor cambia, puede deberse a una saturación del búfer y el proceso se detiene 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 información.
WPF se compila con la marca /GS para agregar una capa más de defensa a las aplicaciones de WPF.
Windows Vista
Los usuarios de WPF en Windows Vista se beneficiarán de las mejoras de seguridad adicionales del sistema operativo, incluidos “Acceso de usuario con privilegios mínimos”, comprobaciones de integridad de código y aislamiento de privilegios.
Control de cuentas de usuario [UAC]
Hoy en día, los usuarios de Windows tienden a ejecutar las aplicaciones con privilegios de administrador porque muchas requieren esos privilegios para la instalación, la ejecución o ambas. Ser capaz de escribir la configuración predeterminada de una aplicación en el Registro es un ejemplo.
La ejecución con privilegios de administrador en realidad significa que las aplicaciones se ejecutan a partir de procesos que tienen concedidos privilegios de administrador. El efecto de esto en la seguridad 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 recursos críticos del sistema.
Una manera de protegerse frente a esta amenaza de seguridad es ejecutar las aplicaciones con los privilegios mínimos necesarios. Esto se conoce como el principio de privilegios mínimos y es una característica fundamental del sistema operativo Windows. Esta característica se denomina Control de cuentas de usuario (UAC) y el UAC de Windows la usa de dos maneras distintas:
Para ejecutar la mayoría de las aplicaciones con privilegios UAC de forma predeterminada, incluso si el usuario es un administrador; solo las aplicaciones que necesitan privilegios de administrador se ejecutarán con privilegios de administrador. Para ejecutarse con privilegios de administrador, 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 con UAC, existe una ubicación por usuario alternativa que no requiere privilegios de administrador para escribir en ella. Para las aplicaciones que se ejecutan en UAC, UAC virtualiza C:\Archivos de programa para que las aplicaciones que crean estar escribiendo en esa ubicación, en realidad lo estén haciendo en la ubicación por usuario alternativa. Este tipo de trabajo de compatibilidad permite al sistema operativo ejecutar muchas aplicaciones que anteriormente no se podían ejecutar en UAC.
Comprobaciones de integridad de código
Windows Vista incorpora comprobaciones más severas de integridad de código para evitar la inserción de código malintencionado en los archivos del sistema o en el kernel en tiempo de carga o de ejecución. Esto va más allá de la protección de archivos de sistema.
Proceso de derechos limitados para las aplicaciones hospedadas en explorador
Las aplicaciones de WPF hospedadas en explorador se ejecutan en el espacio aislado de la zona de Internet. La integración de WPF con Microsoft Internet Explorer amplía esta protección con compatibilidad adicional.
Advertencia
Las aplicaciones XBAP requieren exploradores heredados, como Internet Explorer y versiones anteriores de Firefox. Estos exploradores anteriores suelen no ser compatibles con Windows 10 y Windows 11. Los exploradores modernos ya no admiten la tecnología necesaria para las aplicaciones XBAP debido a riesgos de seguridad. Los complementos que habilitan XBAPs ya no se admiten. Para obtener más información, vea Preguntas más frecuentes sobre las aplicaciones hospedadas en explorador (XBAP) de WPF.
Puesto que las aplicaciones del explorador XAML (XBAP) suelen limitarse al espacio aislado establecido por el conjunto de permisos de zona de Internet, quitar estos privilegios no daña las aplicaciones del explorador XAML (XBAP) desde una perspectiva de compatibilidad. En su lugar, se crea una capa adicional de defensa en profundidad; aunque una aplicación en espacio aislado sea capaz de vulnerar otras capas y secuestrar el proceso, el proceso solo tendrá privilegios limitados.
Consulte Uso de cuentas de usuario menos privilegiadas.
Seguridad de Common Language Runtime
Common Language Runtime (CLR) ofrece varias ventajas clave de seguridad que incluyen validación y comprobación, seguridad de acceso del código (CAS) y la metodología de seguridad crítica.
Validación y comprobación
Para proporcionar aislamiento de ensamblados e integridad, CLR usa un proceso de validación. La validación de CLR garantiza que los ensamblados se aíslen mediante la validación de su formato de archivo portable ejecutable (PE) para las direcciones que apuntan fuera del ensamblado. La validación de CLR también corrobora la integridad de los metadatos que se insertan en un ensamblado.
Para garantizar la seguridad de tipos, evitar problemas de seguridad comunes (por ejemplo, las saturaciones del búfer) y habilitar el espacio aislado a través de aislamiento de subprocesos, la seguridad de CLR usa el concepto de comprobació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 a través de la compilación Just-In-Time (JIT). La compilación JIT incluye un proceso de comprobación que aplica numerosas reglas de seguridad y solidez para impedir que el código realice las siguientes acciones:
Infringir contratos de tipo
Introducir saturaciones del búfer
Tener acceso descontrolado a la memoria
El código administrado que no cumple las reglas de comprobación no tiene permiso para ejecutarse, a menos que se considere código de confianza.
La ventaja que ofrece un código comprobable es una de las principales razones por las que WPF se compila en .NET Framework. En la medida en que se usa el código comprobable, se reduce en gran medida la posibilidad de aprovecharse de las posibles vulnerabilidades.
Seguridad de acceso del código
Una máquina cliente exhibe una amplia variedad de recursos a los que puede tener acceso una aplicación administrada, 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 tener acceso a cualquiera de los recursos de un equipo cliente, debe tener el permiso de .NET Framework para hacerlo. Un permiso en CAS es una subclase de la CodeAccessPermission; CAS implementa una subclase para cada recurso al que pueden tener acceso las aplicaciones administradas.
Los permisos que CAS concede a una aplicación administrada cuando comienza a ejecutarse se conocen como conjunto de permisos y están determinados por la evidencia proporcionada por la aplicación. Para las aplicaciones de WPF, la evidencia proporcionada es la ubicación —o zona— desde la que se inician las aplicaciones. CAS identifica las zonas siguientes:
Mi PC. Aplicaciones iniciadas desde la máquina cliente (de plena confianza).
Intranet local. Aplicaciones iniciadas desde la intranet (de confianza parcial).
Internet. Aplicaciones iniciadas desde Internet (de confianza mínima).
Sitios de confianza. Aplicaciones identificadas por un usuario como de confianza (de confianza mínima).
Sitios que no son de confianza. Aplicaciones identificadas por un usuario como no confiables (no confiables).
Para cada una de estas zonas, CAS proporciona un conjunto de permisos predefinidos que incluye los permisos que coinciden con el nivel de confianza asociado a cada una. Entre ellas se incluyen las siguientes:
FullTrust. Para las aplicaciones iniciadas desde la zona de Mi PC. Se conceden todos los permisos posibles.
LocalIntranet. Para las aplicaciones iniciadas desde la zona de Intranet local. Un subconjunto de los permisos se concede para proporcionar acceso moderado a los recursos de una máquina cliente, incluido almacenamiento aislado, acceso sin restricciones a la interfaz de usuario, cuadros de diálogo de archivos sin restricciones, reflexión limitada y acceso limitado a las variables de entorno. No se proporcionan permisos para los recursos críticos, como el Registro.
Internet. Para las aplicaciones iniciadas desde la zona de Internet o Sitios de confianza. Un subconjunto de los permisos se concede para proporcionar acceso limitado a los recursos de una máquina cliente, incluido almacenamiento aislado, apertura exclusiva de archivos e interfaz de usuario limitada. En esencia, este conjunto de permisos aísla las aplicaciones de la máquina cliente.
A las aplicaciones identificadas como pertenecientes a la zona de Sitios que no son de confianza, CAS no les concede ningún permiso en absoluto. Por lo tanto, no existe un conjunto de permisos predefinidos para ellas.
La siguiente ilustración muestra la relación entre zonas, conjuntos de permisos, permisos y recursos:
Diagrama que muestra conjuntos de permisos CAS.
Las restricciones del espacio aislado de seguridad de la zona de Internet se aplican igualmente a cualquier código que una aplicación XBAP importe desde una biblioteca del sistema, incluido WPF. Esto garantiza que cada bit del código está bloqueado, incluso WPF. Desgraciadamente, para poder ejecutarse, una aplicación XBAP necesita ejecutar funcionalidades que requieren más permisos que los habilitados por el espacio aislado de seguridad de la zona de Internet.
Advertencia
Las aplicaciones XBAP requieren exploradores heredados, como Internet Explorer y versiones anteriores de Firefox. Estos exploradores anteriores suelen no ser compatibles con Windows 10 y Windows 11. Los exploradores modernos ya no admiten la tecnología necesaria para las aplicaciones XBAP debido a riesgos de seguridad. Los complementos que habilitan XBAPs ya no se admiten. Para obtener más información, vea Preguntas más frecuentes sobre las aplicaciones hospedadas en explorador (XBAP) de WPF.
Imagine 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 esta aplicación XBAP, el código WPF subyacente debe ejecutar más funcionalidad de la disponible para la aplicación XBAP de llamada, lo que incluye:
Creación de un identificador de ventana (HWND) para la representación
Envío de mensajes
Carga de la fuente Tahoma
Desde el un punto de vista de la seguridad, permitir el acceso directo a cualquiera de estas operaciones desde la aplicación en espacio aislado resultaría catastrófico.
Afortunadamente, WPF se encarga de esta situación ya que permite que estas operaciones se ejecuten con privilegios elevados en nombre de la aplicación en espacio aislado. Mientras que todas las operaciones de WPF se comprueban con los permisos limitados de seguridad de la zona de Internet del dominio de XBAP, a WPF (al igual que a otras bibliotecas de sistema) se le concede un conjunto de permisos que incluye todos los permisos posibles.
Esto requiere que WPF reciba privilegios elevados al tiempo que se evita que esos privilegios se rijan por el conjunto de permisos de zona de Internet del dominio de la aplicación host.
Para lograrlo, WPF usa el método Assert de un permiso. El siguiente código muestra cómo se produce 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()
Básicamente, Assert evita que los permisos ilimitados que necesita WPF estén restringidos por los permisos de la zona de Internet de XBAP.
Desde la perspectiva de plataforma, WPF es responsable de usar Assert correctamente; un uso incorrecto de Assert podría permitir que el código malintencionado elevase los privilegios. En consecuencia, es importante llamar a Assert únicamente cuando sea necesario y asegurarse de que las restricciones del espacio aislado permanezcan intactas. Por ejemplo, el código en espacio aislado no tiene permiso para abrir archivos aleatorios, pero sí para usar fuentes. WPF permite que las aplicaciones en espacio aislado usen la funcionalidad de fuentes mediante la llamada a Assert y que WPF lea los archivos que contienen estas fuentes en nombre de la aplicación en espacio aislado.
Implementación 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 ClickOnce para obtener información detallada). Mientras que las aplicaciones independientes de WPF pueden implementarse de forma optativa con ClickOnce, las aplicaciones hospedadas en explorador deben implementarse obligatoriamente con ClickOnce.
Las aplicaciones implementadas mediante ClickOnce tienen una capa de seguridad adicional sobre la seguridad de acceso del código (CAS); básicamente, las aplicaciones implementadas de ClickOnce solicitan los permisos que necesitan. Esos permisos se les conceden únicamente si no exceden el conjunto de permisos para la zona desde la que se implementa la aplicación. Al reducir el conjunto de permisos exclusivamente a 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 tiene acceso la aplicación se reduce al mínimo necesario. Por lo tanto, si se secuestra la aplicación, se reduce la posibilidad de daños en la máquina cliente.
Metodología crítica para la seguridad
El código WPF que usa permisos para habilitar el espacio aislado de zona de Internet para las aplicaciones XBAP debe mantenerse en el máximo nivel de control y auditoría de seguridad. Para facilitar este requisito, .NET Framework ofrece nueva compatibilidad para administrar el código que eleva los privilegios. En concreto, CLR permite identificar el código que eleva los privilegios y lo marca con SecurityCriticalAttribute; cualquier código que no esté 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 eleve sus privilegios.
Advertencia
Las aplicaciones XBAP requieren exploradores heredados, como Internet Explorer y versiones anteriores de Firefox. Estos exploradores anteriores suelen no ser compatibles con Windows 10 y Windows 11. Los exploradores modernos ya no admiten la tecnología necesaria para las aplicaciones XBAP debido a riesgos de seguridad. Los complementos que habilitan XBAPs ya no se admiten. Para obtener más información, vea Preguntas más frecuentes sobre las aplicaciones hospedadas en explorador (XBAP) de WPF.
La metodología crítica para la seguridad permite la organización de código WPF que eleva los privilegios en el kernel crítico para la seguridad, y hace que el resto sean transparentes. Aislar el código crítico para la seguridad permite al equipo de ingenieros de WPF centrar un control de origen y análisis de seguridad adicional en el kernel crítico para la seguridad más allá de las prácticas 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 amplíe el espacio aislado de zona de Internet de XBAP al dejar que los desarrolladores puedan escribir 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 muy sensible ya que permite que cualquier código llame a ese ensamblado, incluso el código malintencionado procedente de Internet. Cuando lo haga, extreme las precauciones y siga los procedimientos recomendados; asimismo, los usuarios deben confiar en el software para que pueda instalarse.
Seguridad de Microsoft Internet Explorer
Más allá 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 del explorador XAML (XBAP). Estas características intentan ofrecer a los usuarios un mayor control sobre su experiencia de exploración.
Advertencia
Las aplicaciones XBAP requieren exploradores heredados, como Internet Explorer y versiones anteriores de Firefox. Estos exploradores anteriores suelen no ser compatibles con Windows 10 y Windows 11. Los exploradores modernos ya no admiten la tecnología necesaria para las aplicaciones XBAP debido a riesgos de seguridad. Los complementos que habilitan XBAPs ya no se admiten. Para obtener más información, vea Preguntas más frecuentes sobre las aplicaciones hospedadas en explorador (XBAP) de WPF.
En versiones previas a IE6 SP2, los usuarios podían experimentar lo siguiente:
Ventanas emergentes aleatorias.
Redirección de script confusa.
Numerosos cuadros de diálogo de seguridad en algunos sitios web.
En algunos casos, sitios web de poca confianza trataban de engañar a los usuarios mediante la suplantación de la interfaz de usuario (IU) de instalación o mostrando repetidamente un cuadro de diálogo de instalación de Microsoft ActiveX, incluso después de que el usuario lo cancelase. Es posible que estas técnicas indujeran a un número significativo de usuarios a tomar malas decisiones que hayan dado lugar a la instalación de aplicaciones de spyware.
IE6 SP2 incluye varias características para mitigar este tipo de problemas centradas en el concepto de inicio por usuario. IE6 SP2 detecta si un usuario hace clic en un vínculo o elemento de la página antes de una acción, lo que se conoce como inicio por usuario, y se trata de manera diferente a cuando una acción parecida se activa con el script de una página. Por ejemplo, IE6 SP2 incorpora un bloqueador de elementos emergentes que detecta si un usuario hace clic en un botón antes de que la página cree un elemento emergente. De este modo, IE6 SP2 permite la mayoría de los elementos emergentes inocuos y evita los elementos emergentes que los usuarios no solicitan ni desean. Los elementos emergentes bloqueados se capturan en la nueva Barra de información, lo que permite al usuario invalidar manualmente el bloqueo y ver el elemento emergente.
La misma lógica de iniciación por usuario también se aplica a las advertencias de seguridad Abrir/Guardar. Los cuadros de diálogo de instalación de ActiveX siempre se capturan en la Barra de información, a menos que representen una actualización de un control previamente instalado. Estas medidas se combinan para brindar a los usuarios una experiencia de usuario más segura y controlada, puesto que están protegidos contra los sitios que les importunan para instalar software malintencionado o no deseado.
Estas características también protegen a los clientes que usan IE6 SP2 para ir a sitios web donde pueden descargar e instalar las aplicaciones de 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 dañinas independientemente de qué tecnología se utilizó para crearlas, incluido WPF. WPF se suma a estas protecciones usando ClickOnce para facilitar la descarga de sus aplicaciones a través de Internet. Puesto que las aplicaciones del explorador XAML (XBAP) se ejecutan dentro de un espacio aislado de seguridad de la zona de Internet, pueden iniciarse sin problemas. Por otro lado, las aplicaciones de WPF independientes requieren plena confianza para ejecutarse. Para estas aplicaciones, ClickOnce mostrará un cuadro de diálogo de seguridad durante el proceso de inicio a fin de notificar el uso de los requisitos de seguridad adicionales de la aplicación. Sin embargo, esto debe ser iniciado por el usuario, se regirá por la lógica iniciada por el usuario y se puede cancelar.
Internet Explorer 7 incorpora y amplía las capacidades de seguridad de IE6 SP2 como parte de un compromiso continuo con la seguridad.
Consulte también
.NET Desktop feedback