다음을 통해 공유

  • 아티클

Silverlight Application Security Model

Microsoft Silverlight will reach end of support after October 2021. Learn more.

Silverlight applications operate within a partial-trust security boundary that is sometimes called a sandbox. Traditional Silverlight applications cannot access the file system and other system resources in the same way as traditional .NET applications. By default, access to the HTML page that hosts the Silverlight plug-in is restricted. This sandbox environment is enabled by a security model. This topic introduces the code types, security levels, and security attributes in Silverlight applications.

Silverlight 4 and later applications can be configured to run in a trusted environment thereby sidestepping many sandbox feature limitations. Most of the security limits described in this document do not apply to trusted applications, and you should use care when you create these types of applications. For more information, see Trusted Applications.

This topic contains the following sections:

  • Code Types

  • Security Levels

  • User Initiation

  • Security Attributes

Code Types

In the context of security within the application, there are two code types in Silverlight: platform code and application code. Platform code is the API provided by the Silverlight runtime and SDK. Application code is the code that you write by using the platform code.

The Silverlight runtime can detect the code type based on the location that the code assembly is loaded from and by checking the public key for the assembly. If an assembly is loaded from the Silverlight runtime or SDK installation directory, is signed with a public key from Microsoft, and meets some additional requirements, the assembly can contain platform code. This means that Silverlight application code is never considered to be platform code.

Security Levels

Silverlight code has three security levels: Transparent, SafeCritical, and Critical. Transparent code is code that cannot elevate the permissions of the call stack. This means that Transparent code can only run with the same permission level as its caller. All application code is Transparent code.

Critical code is code that has the ability to perform operations that are outside the security sandbox, such as writing to the file system. SafeCritical code is a code layer on top of Critical code that helps to ensure calls are safe. Platform code can be Transparent, SafeCritical, or Critical. The following illustration shows the security levels.

Security Model

Transparent code will not allow any security check to succeed, although it can cause the check to fail; typically throwing a MethodAccessException. If Transparent code attempts to call Critical code directly, a MethodAccessException is thrown, unless the application is a Windows-based trusted application

Transparent code in partial-trust Silverlight applications has the following restrictions:

  • Cannot contain unverifiable code. This means that all of the code must be verifiably type-safe.

  • Cannot call native code via platform invoke or COM interop.

  • Cannot access Critical code or data unless the target is marked SafeCritical.

SafeCritical code helps to ensure that it is safe for Transparent code to perform critical operations. SafeCritical APIs typically do various checks before passing control to a Critical API, including validating incoming parameters and ensuring that the application state is acceptable for the call to continue. Once a SafeCritical call is allowed to proceed, it invokes a Critical method on the caller's behalf or performs the operation directly.

For example, writing to the file system is implemented as Critical code. In order to provide access to persistent storage in the file system, Silverlight has a SafeCritical feature called isolated storage. When a sandboxed Silverlight application calls an isolated storage API, the API validates the request by making sure that the application is requesting a valid file and is not over its storage quota. Then, the isolated storage API calls the Critical APIs to perform the actual work of reading or writing to the hard disk. Trusted Silverlight applications can bypass these security checks and write to the file system directly. For more information, see How to: Access the Local File System in Trusted Applications

User Initiation

Another way that SafeCritical code ensures the call is safe in a sandboxed application is by requiring user-initiation. This means that to use some features of Silverlight, you must solicit input from the user. For example, the user must click a button to show the OpenFileDialog. If you attempt to show the OpenFileDialog without user input a SecurityException will occur. By requiring user input to enable many features, Silverlight helps makes it clear to the user which application they are running is asking for elevated privileges. Following is a list of features that require user initiation.

Application Feature

Details

File system access

File system access is limited and most dialog boxes must be user-initiated. For more information, see Dialog Boxes Overview.

Full-screen mode

Full-screen mode must be user-initiated and displays a message about how to exit. When the user presses the ESC key or switches to another window, the application automatically exits full-screen mode. For more information, see Full-Screen Support.

Webcam and microphone support

Use of a webcam or microphone must be user-initiated. The user must grant permission in the security prompt.

Silverlight 4 and later.

Printing

The Print dialog box must be user-initiated. For more information, see Printing.

Silverlight 4 and later.

Clipboard access

Clipboard access must be user-initiated. The user must grant permission in the security prompt. Permission ends when the current page is closed or the user navigates away. For more information, see Clipboard.

Silverlight 4 and later.

Security Attributes

To specify security levels, attributes are added to the platform code. All application code must be Transparent and should not be marked with security attributes. If application code is marked with a security attribute, the attribute is ignored and an exception occurs if an unsafe call is attempted.