What is a per-application data compartment? How could it compromise applications, and is it a serious threat to...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
I think you’re referring to Microsoft’s .NET Framework data storage mechanism, Isolated Storage, which is designed to improve the security of application data by defining standardized ways of associating code with saved data. Most applications need to store and retrieve data while they’re running information such as, application state, temporary data and user-related settings. Potentially unsecure or only partially trusted applications -- Internet-based apps, for example -- don’t normally have the permissions to access the local file system to perform such operations, and so are limited in their functionality.
Applications built to incorporate .NET’s isolated storage are sandboxed. They can only access their own uniquely assigned virtual subset of the file system to store and retrieve data, thus removing the risk of malicious actions. The storage files can reside on the client or server, and remove the need to grant access rights to the user or the application for storing data in a specific file or folder.
Access to isolated storage is always restricted to the user who created it, and the data is always isolated by user and assembly. Components shared between applications can use isolated storage to provide controlled access to data stores, while a server can impersonate the user on whose behalf it is functioning to create isolated stores -- useful for those on the road and using roaming profiles.
The specific application permissions are controlled by the computer's security policy and the location from where it is accessed. The net effect of this is the same piece of code can be granted different sets of permissions depending on who, what and where it is being accessed from. Using the Code Access Security Policy editor, system administrators can modify and limit how much isolated storage an application or a user has available, delete unused data and set security policies to configure the level of trust of individual assemblies.
The aim of isolated storage is to increase the functionality of certain types of applications by allowing them to persist data whilst ensuring they remain safe to use by providing controlled access to only a small and restricted portion of the disk. How well this technology has been implemented remains to be seen. My main concern at this point is how well developers are implementing it in their applications. For example, isolated storage shouldn’t be used to store sensitive data such as unencrypted keys or passwords, because it can still be accessed by highly trusted code, unmanaged code and other trusted users of the computer. Despite years of warning developers not to store sensitive data in cookies, the practice still persists. As with any application, you need to carry out a full risk assessment before you decide to run it under partial, limited or full trust and allow your users access to it.
Dig Deeper on Software Development Methodology
Related Q&A from Michael Cobb
Open source NoSQL MongoDB database faced 30,000 insecure instances. Expert Michael Cobb explains the misconfiguration that led to this, and how to ...continue reading
A new Veracode report offers details on common mobile application security risks. Expert Michael Cobb explains these flaws, and what developers can ...continue reading
Juniper firewall products were found to have two backdoor vulnerabilities. Expert Michael Cobb explains how a cryptographic algorithm and hardcoded ...continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.