Export (0) Print
Expand All

Additional Security Considerations in Windows Forms

Visual Studio .NET 2003

Because of .NET Framework security settings, your application might run differently in a semi-trusted environment than it will on your local computer. The .NET Framework protects access to the Clipboard and restricts window manipulation. The security settings affect the ability to call the Microsoft Win32 API or other APIs that cannot be verified by the security system. Security also affects other aspects of your application, including file and data access and printing. For more information about file and data access in a semi-trusted environment, see Secure File and Data Access in Windows Forms. For more information about printing in a semi-trusted environment, see Secure Printing in Windows Forms.

The following sections discuss working with the Clipboard, performing window manipulation, and calling the Win32 API from applications running in a semi-trusted environment:

Clipboard Access

The UIPermission class controls access to the Clipboard, and the associated UIPermissionClipboard enumeration value indicates the level of access. The following table shows the possible permission levels.

UIPermissionClipboard valueDescription
AllClipboardThe Clipboard can be used without restriction.
OwnClipboardThe Clipboard can be used with some restrictions. The ability to put data on the Clipboard (Copy or Cut) is unrestricted. Intrinsic controls that accept Paste, such as a text box, can accept Clipboard data, but user controls cannot programmatically read from the Clipboard.
NoClipboardThe Clipboard cannot be used.

By default, the Local Intranet zone receives AllClipboard access and the Internet zone receives OwnClipboard access. This means that the application can copy data to the Clipboard, but it cannot programmatically paste to or read from the Clipboard. These restrictions prevent programs without full trust from reading content copied to the Clipboard by another application. If your application requires full Clipboard access but you do not have the permissions, you will need to elevate the permissions for your application. For more information about elevating permissions, see General Security Policy Administration.

Window Manipulation

The UIPermission class also controls permission to perform window manipulation and other UI-related actions, and the associated UIPermissionWindow enumeration value indicates the level of access. The following table shows the possible permission levels.

By default, the Local Intranet zone receives AllWindows access and the Internet zone receives SafeTopLevelWindows access. This means that in the Internet zone, the application can perform most windowing and UI actions, but the window's appearance will be modified. The modified window displays a balloon notification when first run, contains modified title bar text, and requires a close button on the title bar. The balloon notification and the title bar identify that the application is running under partial trust.

UIPermissionWindow valueDescription
AllWindowsUsers can use all windows and user input events without restriction.
SafeTopLevelWindowsUsers can only use safe top-level windows and safe subwindows for drawing, and can use only user input events for the user interface within those top-level windows and subwindows. These safe windows are clearly labeled and have minimum and maximum size restrictions. The restrictions prevent potentially harmful spoofing attacks, such as imitating system logon screens or the system desktop.
SafeSubWindowsUsers can only use safe subwindows for drawing, and can use only user input events for the user interface within that subwindow. A control displayed within a browser is an example of a safe subwindow.
NoWindowsUsers cannot use any windows or user interface events. No user interface can be used.

Each permission level identified by the UIPermissionWindow enumeration allows fewer actions than the level above it. The tables below indicate the actions that are restricted by the SafeTopLevelWindows and SafeSubWindows values. For exact permissions required for each member, refer to the reference for that member in the .NET Framework class library documentation.

SafeTopLevelWindows permission restricts the actions listed in the following table.

ComponentRestricted actions
Application
  • Setting the SafeTopLevelCaptionFormat property.
Control
  • Getting the Parent property.
  • Setting the Region property.
  • Calling the FindForm, Focus, FromChildHandle and FromHandle, PreProcessMessage, ReflectMessage, or SetTopLevel method.
  • Calling the GetChildAtPoint method if the control returned is not a child of the calling control.
  • Modify control focus inside a container control.
Cursor
  • Setting the Clip property.
  • Calling the Hide method.
DataGrid
  • Calling the ProcessTabKey method.
Form
  • Getting the ActiveForm or MdiParent property.
  • Setting the ControlBox, ShowInTaskbar, or TopMost property.
  • Setting the Opacity property below 50%.
  • Setting the WindowState property to FormWindowState.Minimized programmatically.
  • Calling the Activate method.
  • Using the None, FixedToolWindow, and SizableToolWindow FormBorderStyle enumeration values.
NotifyIcon
  • Using the NotifyIcon component is completely restricted.

The SafeSubWindows value restricts the actions listed in the following table, in addition to the restrictions placed by the SafeTopLevelWindows value.

ComponentRestricted actions
CommonDialog
  • Showing a dialog derived from the CommonDialog class.
Control
  • Calling the CreateGraphics method.
  • Setting the Cursor property.
Cursor
  • Setting the Current property.
MessageBox
  • Calling the Show method.

Win32 API Calls

If your application design requires calling a function from the Win32 API, you are accessing unmanaged code. This is because the code's actions to the window or operating system cannot be determined when working with Win32 API calls or values. The SecurityPermission class and the UnmanagedCode value of the SecurityPermissionFlag enumeration control access to unmanaged code. An application can access unmanaged code only when it is granted the UnmanagedCode permission. By default, only applications running locally can call unmanaged code.

Some Windows Forms members provide unmanaged access that requires the UnmanagedCode permission. The following table lists the members in the System.Windows.Forms namespace that require the permission. For more information about the permissions required for a member, refer to the .NET Framework class library documentation.

ComponentMember
Application
  • AddMessageFilter method
  • CurrentInputLanguage property
  • Exit method
  • ExitThread method
  • ThreadException event
CommonDialog
  • HookProc method
  • OwnerWndProc method
  • Reset method
  • RunDialog method
Control
  • CreateParams method
  • DefWndProc method
  • DestroyHandle method
  • WndProc method
Help
  • ShowHelp methods
  • ShowHelpIndex method
NativeWindow
  • NativeWindow class
Screen
  • FromHandle method
SendKeys
  • Send method
  • SendWait method

If your application does not have permission to call unmanaged code, you should consider alternative ways of implementing features; in many cases, Windows Forms provides a managed alternative to Win32 API functions. If no alternative means exist and the application must access unmanaged code, then you will need to elevate the permissions for the application.

Permission to call unmanaged code allows an application to perform most anything. Because of this, permission to call unmanaged code should only be granted for applications that come from a trusted source. Alternatively, depending on the application, the piece of application functionality that makes the call to unmanaged code could be optional, or enabled in the full trust environment only For more information about dangerous permissions, see Dangerous Permissions and Policy Administration. For more information about elevating permissions, see General Security Policy Administration.

See Also

Secure File and Data Access in Windows Forms | Secure Printing in Windows Forms | Introduction to Security In Windows Forms | Windows Forms Security

Show:
© 2014 Microsoft