Consideraciones de seguridad adicionales en formularios Windows Forms
Actualización: noviembre 2007
La configuración de seguridad de .NET Framework puede hacer que la aplicación se ejecute de manera diferente en un entorno de confianza parcial que en el equipo local. .NET Framework restringe el acceso a recursos locales críticos como el sistema de archivos, la red y API no administradas, entre otras cosas. La configuración de seguridad afecta a la capacidad de llamar a la API Microsoft Win32 u otras API que no pueda comprobar el sistema de seguridad. La seguridad afecta también a otros aspectos de la aplicación, incluido el acceso a archivos y datos y su impresión. Para obtener más información sobre el acceso a archivos y datos en un entorno de confianza parcial, vea Acceso más seguro a archivos y datos en formularios Windows Forms. Para obtener más información sobre cómo imprimir en un entorno de confianza parcial, vea Impresión más segura en formularios Windows Forms.
Las siguientes secciones explican cómo trabajar con el Portapapeles, manipular ventanas y llamar a la API Win32 desde aplicaciones que se ejecutan en un entorno de confianza parcial.
Acceso al Portapapeles
La clase UIPermission controla el acceso al Portapapeles y el valor de enumeración UIPermissionClipboard asociado indica el nivel de acceso. La tabla siguiente muestra los niveles de permiso posibles.
Valor UIPermissionClipboard |
Descripción |
|---|---|
Se puede utilizar el Portapapeles sin límites. |
|
Se puede utilizar el Portapapeles con ciertas limitaciones. La capacidad de colocar datos en el Portapapeles (operaciones del comando Copiar o Cortar) no está limitada. Los controles intrínsecos que acepten Pegar, como un cuadro de texto, pueden aceptar datos del Portapapeles, pero los controles de usuario no pueden leer el Portapapeles mediante programación. |
|
No se puede utilizar el Portapapeles. |
De manera predeterminada, la zona Intranet local recibe el acceso AllClipboard y la zona Internet recibe el acceso OwnClipboard. Esto significa que la aplicación puede copiar datos en el Portapapeles, pero no puede leer el Portapapeles ni pegar datos en él mediante programación. Estas limitaciones impiden que los programas que no sean totalmente confiables lean el contenido copiado en el Portapapeles por otra aplicación. Si la aplicación requiere acceso total al Portapapeles pero no tiene los permisos necesarios, deberá conceder dichos permisos a la aplicación. Para obtener más información sobre la concesión de permisos, vea Administración de la directiva de seguridad general.
Manipulación de ventanas
La clase UIPermission controla también el permiso para manipular ventanas y otras acciones relacionadas con la interfaz de usuario, y el valor de enumeración UIPermissionWindow asociado indica el nivel de acceso. La tabla siguiente muestra los niveles de permiso posibles.
De manera predeterminada, la zona Intranet local recibe el acceso AllWindows y la zona Internet recibe el acceso SafeTopLevelWindows. Esto significa que, en la zona Internet, la aplicación puede realizar la mayoría de las operaciones de ventanas de la interfaz de usuario, pero se modificará la apariencia de la ventana. La ventana modificada muestra una notificación en un globo la primera vez que se ejecuta, contiene el texto de la barra de título modificada y requiere un botón Cerrar en la barra de título. La notificación del globo y la barra de título informan al usuario de la aplicación que ésta se está ejecutando bajo confianza parcial.
Valor UIPermissionWindow |
Descripción |
|---|---|
Los usuarios pueden utilizar todas las ventanas y los eventos de entrada de datos por el usuario sin límites. |
|
Los usuarios sólo pueden utilizar ventanas de nivel superior y subventanas más seguras para dibujar, y sólo pueden utilizar eventos de entrada de datos proporcionados por el usuario para la interfaz de usuario dentro de dichas ventanas y subventanas de nivel superior. Estas ventanas más seguras están claramente etiquetadas y tienen límites de tamaño máximo y mínimo. Las restricciones evitan posibles ataques de suplantación peligrosos, como la imitación de las pantallas de inicio de sesión en el sistema o del escritorio del sistema, y limitan el acceso mediante programación a las ventanas primarias, a las API relacionadas con el foco y el uso del control ToolTip |
|
Los usuarios sólo pueden utilizar subventanas más seguras para dibujar, y sólo pueden utilizar eventos de entrada de datos por el usuario para la interfaz de usuario dentro de esa subventana. Un control mostrado en un explorador es un ejemplo de una subventana más segura. |
|
Los usuarios no pueden utilizar ninguna ventana ni ningún evento de interfaz de usuario. No se puede utilizar ninguna interfaz de usuario. |
Cada nivel de permiso identificado por la enumeración UIPermissionWindow permite menos acciones que su nivel superior. Las tablas siguientes indican las acciones que restringen los valores SafeTopLevelWindows y SafeSubWindows. Para saber los permisos exactos necesarios para cada miembro, consulte el material de referencia de dicho miembro en la documentación de la biblioteca de clases de .NET Framework.
El permiso SafeTopLevelWindows limita las acciones enumeradas en la siguiente tabla.
Componente |
Acciones restringidas |
|---|---|
|
|
|
|
|
|
|
|
|
El valor SafeSubWindows restringe las acciones enumeradas en la siguiente tabla, además de las limitaciones que impone el valor SafeTopLevelWindows.
Componente |
Acciones restringidas |
|---|---|
|
|
|
|
|
|
|
Alojar controles de otro fabricante
Otro tipo de manipulación de ventanas es posible si los formularios alojan controles de otro fabricante. Un control de otro fabricante es cualquier UserControl personalizado que no ha desarrollado y compilado usted mismo. Aunque el escenario de alojamiento es difícil de manipular, teóricamente es posible que un control de otro fabricante expanda su superficie de representación para abarcar todo el área de su formulario. Después, el control podría imitar un cuadro de diálogo crítico y solicitar información tal como una combinación de nombre de usuario y contraseña o los números de cuenta bancaria de sus usuarios.
Para limitar este riesgo potencial, utilice sólo controles de proveedores de confianza. Si utiliza controles de otro fabricante que ha descargado de un origen que no puede comprobar, se recomienda que revise el código fuente en busca de posibles puntos vulnerables. Después de comprobar que el origen no es malintencionado, debería compilar el ensamblado para garantizar que el origen coincide con el ensamblado.
Llamadas a la API Win32
Si el diseño de la aplicación requiere llamar a una función de la API Win32, estará teniendo acceso a código no administrado. En este caso las acciones del código en la ventana o el sistema operativo no se pueden determinar cuando se trabaja con llamadas o valores de la API Win32. La clase SecurityPermission y el valor UnmanagedCode del control de enumeración SecurityPermissionFlag tienen acceso a código no administrado. Una aplicación sólo puede tener acceso a código no administrado cuando tiene el permiso UnmanagedCode. De manera predeterminada, sólo las aplicaciones que se ejecutan localmente pueden llamar a código no administrado.
Algunos miembros de formularios Windows Forms proporcionan acceso no administrado que requiere el permiso UnmanagedCode. La siguiente tabla enumera los miembros del espacio de nombres System.Windows.Forms que requieren el permiso. Para obtener más información sobre los permisos necesarios para un miembro, consulte la documentación de la biblioteca de clases de .NET Framework.
Componente |
Miembro |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
Si la aplicación no tiene permiso para llamar a código no administrado, tendrá que solicitar el permiso UnmanagedCode, o deberá considerar modos alternativos de implementar las características; en muchos casos, los formularios Windows Forms proporcionan una alternativa administrada a las funciones de la API Win32. Si no existen ningún medio alternativo y la aplicación debe tener acceso a código no administrado, deberá conceder permisos a la aplicación.
El permiso para llamar a código no administrado permite a la aplicación realizar casi todo. Por ello, este permiso para llamar a código no administrado únicamente se debe conceder a aplicaciones que procedan de un origen de confianza. De forma alternativa, dependiendo de la aplicación, la función que realiza la llamada al código no administrado podría ser opcional, o sólo habilitarse en el entorno de plena confianza. Para obtener más información sobre los permisos arriesgados, vea Permisos peligrosos y administración de directivas. Para obtener más información sobre la elevación de permisos, vea Administración general de directivas de seguridad.
Vea también
Conceptos
Acceso más seguro a archivos y datos en formularios Windows Forms
Impresión más segura en formularios Windows Forms
Información general sobre la seguridad en formularios Windows Forms
Implementación y seguridad con ClickOnce