MSDN Magazine - February 2009 - (Page 32)

Figure 1 Browsing inside the Isolated Storage API have to cache data on the local machine. If a Silverlight application needs to save some data—any kind of data—locally, then it can only do so through isolated storage. In addition, with isolated storage each application can keep its own data isolated from any other applications or from any other applications outside the site. If you want a general, .NET-oriented introduction to isolated storage and its most common usage scenarios, you should read the .NET Framework Developer’s Guide to Isolated Storage (msdn.mi crosoft.com/library/bdts8hk0). The article mentions a couple of scenarios where using isolated storage is not appropriate. In particular, the guidelines say that you should not be using isolated storage to store sensitive data, code, or configuration settings (other than user preferences). Such guidelines stem from a general security awareness and do not necessarily imply any hazards inherent in the use of isolated storage. So, can you safely store in XAP packages you download into Silverlight isolated storage? In Silverlight, unlike in the desktop CLR, any piece of executable code is untrusted by default and is not allowed to invoke critical methods or elevate privileges of the calling stack. In Silverlight, whatever code you store for later execution will be unable to do anything dangerous. This is no more risky than executing any other piece of Silverlight code. By building a permanent cache of Silverlight packages, you end up storing locally a segment of the Silverlight application you are consciously executing. In Silverlight, the role of isolated storage is analogous—as far as persistence is concerned—to the role of HTTP cookies in classic Web applications. In Silverlight, you should look at isolated storage as a set of larger cookies that can contain any sort of data, including executable code. In this case, though, the Silverlight core CLR provides protection. According to the Silverlight security model, in fact, the core CLR will throw an exception any time the application code wants to execute critical methods. Unlike HTTP cookies, isolated storage in Silverlight is not linked to network I/O and no content is transmitted with requests. Data in isolated storage is isolated by application and no other Silverlight application can access the store. The data is stored on the local file system, however, so an administrator of the machine is certainly able to access it. Again, the overall model is not really different from what happens 32 msdn magazine with HTTP cookies. An administrator can always locate and even alter the content of cookies. If it’s worthwhile in your context, you can use encryption to add another level of data protection. If you’re still worried about having some downloaded executable code lying around your machine, you should refresh your understanding of the Silverlight security model. In brief, the Silverlight core CLR throws an exception any time application code attempts to execute a critical method. In the Silverlight Base Class Library (BCL), methods and classes that perform operations requiring high privileges are marked with a special SecurityCritical attribute. Note that this is the case with most of the content of the System.IO namespace. The Silverlight security acknowledges that some platform classes may need to place safe calls to critical methods. Such classes and methods are then marked with the SecuritySafeCritical attribute. This is the case with classes in the System.IO.IsolatedStorage API (see Figure 1). The key point about Silverlight security is that no piece of application code can ever be marked with the SecurityCritical or SecuritySafeCritical attribute. This attribute is reserved for classes in assemblies digitally signed by Microsoft and loaded into memory from the Silverlight installation directory. As you can see, even in the very unfortunate (and unlikely) circumstance that some malicious guy penetrates your computer and replaces downloaded Silverlight content, the damage is limited to regular operations executable in transparent mode. Isolated Storage API The Silverlight BCL comes with its own implementation of the isolated storage that is tailor-made for the Web scenario. Isolated storage provides access to a subtree of the whole local file system, and no method or property ever allows running code to figure out where the file store is physically located on the user machine. A Silverlight application is not allowed to use absolute file system paths through isolated storage. Likewise, drive information is not available and is unsupported and the same applies to relative paths that contain ellipsis like this one: \..\..\myfile.txt The isolated storage subtree is rooted in a folder located under the current user path. For example, on Windows Vista, the root of the isolated storage folder is located under the Users directory. A Silverlight application gains access to the application-specific isolated storage entry point through a method call: using (IsolatedStorageFile iso = IsolatedStorageFile.GetUserStoreForApplication()) { } Figure 2 Classes in the Isolated Storage API Class IsolatedStorageException IsolatedStorageFile IsolatedStorageFileStream Description Represents the exception thrown when an operation in isolated storage fails. Represents an isolated storage area containing files and directories. Exposes a file within isolated storage. Cutting Edge http://msdn.microsoft.com/library/bdts8hk0 http://msdn.microsoft.com/library/bdts8hk0

Table of Contents Feed for the Digital Edition of MSDN Magazine - February 2009

MSDN Magazine - February 2009 Contents Toolbox CLR Inside Out Data Points Cutting Edge Patterns In Practice Best Practices .Net Interop "Oslo" Basics Patterns Silverlight Under The Table Foundations Windows With C++ .NET Matters Going Places { End Bracket }

MSDN Magazine - February 2009

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.