.NET Framework developed by Microsoft , is an application development platform that provides services for building, deploying, and running desktop, web, and phone applications and web services. The .NET Framework has number of versions. We will cover security aspects of .Net 4 based applications but before let’s get a little overview of .Net framework 4 which is essential for the topic.
.Net framework 4.0 was released on 12 April 2010. Applications that are based on earlier versions of the .Net Framework will continue to run on the target version by default. It consists of the common language runtime (CLR), a common type system and extensive class library. The .NET Framework programs occur in a specialized software environment that helps to manage the runtime of the program as per the requirements. The runtime environment, which is also an integral part of the .NET Framework, is referred as the Common Language Runtime (CLR). CLR provides memory management and other system services. Extensive class library includes tested, reusable code for all major areas of application development. The extensive class library and the CLR together compose the .NET Framework. .Net 4 offers Language interoperability, Version compatibility, Side-by-side execution, Common type system and Multi-targeting. The common language runtime (CLR) and the .NET Framework provide many useful classes and services that enable developers to easily write secure code and enable system administrators to customize the permissions granted to code so that it can access protected resources. Moreover, the runtime and the .NET Framework provide useful classes and services that facilitate the use of cryptography and role based security.
Microsoft has released security patches for all version of the .NET Framework. The .NET Framework 4 offers security transparency, code access security and role-based security to help address security concerns about mobile code and to provide support that enables components to determine what users are authorized to do. These security mechanisms use a simple, consistent model so that developers familiar with code access security can easily use role-based security, and vice versa. Both code access security and role-based security are implemented using a common infrastructure supplied by the common language runtime (CLR).
Code Access Security (CAS) is a security technology developed to provide the ability to protect system resources when a .NET assembly is executed. Such system resources could be: local files, files on a remote file system, registry keys, databases, printers and so on. Unauthorized access to these types of resources can lead to potential security risks, as malicious code could perform damaging operations on them, such as removing critical files, modifying registry keys, or deleting data stored in databases to suggest just a few. Microsoft has changed CAS a lot in .NET Framework 4.0, with the goal of making it easier to implement and manage. Unlike previous versions the greater part of the CAS strategy framework has been totally uprooted. Choices about what authorizations can be allowed to a get together are presently taken by the host in which the get together runs. This takes out all issues identified with CAS Policies setup. The requirement component, that is, the system utilized by the runtime to compel a gathering to execute just code that has authorization to execute, has been supplanted by the Security Transparent model. This streamlines a ton of the work expected to set the entrance conditions for the assets that the get together needs to utilize.
.NET Framework role-inspired security aids authorization by supplying information about the Principal, which was initially constructed from an relative identity, ready for use on the current thread. The same windows identity may be based on a Custom identity unfamiliar to a Windows account. .NET Framework applications also makes authorization choices based on the principal ID membership role. A role can be defined as set of principles that have the same privileges and with regards to security. A principal can be a member of one role or the other or more roles. Therefore, applications can use role membership to determine whether a principal is authorized to perform a requested action. Most at times, in order to provide ease of use and consistency with code access security, .NET Framework role-based security provides System Security Permissions, Principalpermission objects that enable the common language runtime to perform authorization in a way that is similar to code access security checks. The Principal Permission class represents the identity or role that the principal must match and is compatible with both declarative and imperative security checks.
In pre-4.0 adaptations of the .NET Framework, straightforwardness couldn’t be utilized for implementation, as authorization was taken care of by the CAS Policy framework; this conduct is presently called Level1 Security Transparency. With .NET Framework 4.0, these confinements have been uprooted and the Security Transparent model turned into the standard approach to ensure assets. The new model has been called Level2 Security Transparency. Level 2 security transparent model helps break all code in three sections: Security Critical Code, Security Transparent code and Security Safe Critical Code.
The overall security model has changed, becoming easier to implement, and so reducing the chance of potentially dangerous errors. The framework is intended to make it easier to develop computer applications and to reduce the vulnerability of applications and computers to security threats to ensure maximum protection.