Additional Ways of Ensuring Security in .NET

.NET provides different levels of security in terms of Authentication, Authorization, Confidentiality and Integrity. In addition, there are certain other features of .NET which ensures security. They are listed below:

Type Safety: Type Safe Code accesses only the memory locations for which it has permissions. Type Safe Code can access only the public members of the Object and not the private members. Hence Objects are isolated from each other and no malicious corruption can happen. Type Safety is ensured in .NET using CLR (Common Language Runtime) which manages code at execution time. CLR uses a tool called peverify.exe to perform type safety check during JIT compilation. This process is called Verification and the verified code is called verifiably type safe code. Not all languages are type safe. For example C, C++ is not type safe. An example for type safety is provided below:
double var1 = 12.50;
int var2 = 5;
var2 = var1;
The assignment of double value to integer value causes error at compilation time rather than waiting till runtime.

Code Access Security (CAS): This feature imposes security on code under execution. If your program requires a resource to be fetched, is that resource secure and trust worthy? CAS provides you information on how far you can trust the resource code based on where from the code is originated or downloaded. If the code is not trust worthy then you can prevent it from performing privileged actions. Moreover you can define what all operations your code should perform and list of operations that it should not perform using security permissions. CAS can be implemented by using Declarative Security or Imperative Security.

• Declarative Security uses Security Attributes that are placed at class level, assembly level or member level. The attribute can indicate either request type or overrides or demands. Enumeration called SecurityAction has to be passed to the permission attribute. Assume that you have a class in which all its members are restricted to access only “C:\App1\TestFolder” folder. Use the following piece of code to establish it:

[FileIOPermissionAttribute(SecurityAction.RequestRefuse, "C:\App1\TestFolder")]
public class testDeclarativeSecurity
{
public testDeclarativeSecurity()
{
}
Public void testMethod1()
{
}
}

Here all the members inside the class testDeclarativeSecurity, inclusive of the
constructor are protected using DeclarativeSecurity.

If the restriction is enforced at assembly level instead of class level, then code will be:
[assembly: FileIOPermissionAttribute(SecurityAction.RequestRefuse,
" C:\App1\TestFolder ")]

• Imperative Security is established by creating new instance of security permission object within your code. It can be performed only on demands and overrides and not on requests. Refer the sample code below for better understanding:

public class testImperativeSecurity
{
public testImperativeSecurity()
{
}
public void testMethod1()
{
FileIOPermissionAttribute attr = new FileIOPermissionAttribute();
attr.Demand();
}
public void testMethod2()
{
}
}

Here only the testMethod1 is protected by Imperative Security.

Impersonation: Executing Code of another User identity is known as Impersonation. This feature is required for the following reasons:

• Define Different Permissions for Different Applications: machine.config file in the machine will define permissions common to all web applications running in that computer. What if you want to enforce additional security where in different applications have to be defined with different permissions? This is achieved using Impersonation.
•
• Use Windows User Permissions to Authenticate: Rather than writing custom code in your application for performing authorization, you can use impersonation so that Windows checks for authorization while accessing the file.

Using Security Context: Each User who logs into your application is granted a Principal Object and Identity Object. Principal Object associates user identity with the Users roles, privileges and thereby helps in performing role based authorization. Identity Object has the User Identity related information. All Principal Objects and Identity Objects implement IPrincipal Interface and IIdentity Interface respectively. Sample methods and properties from these two interfaces are given below:

HttpContext.Current.User.IsInRole(“<rolename>”) – check if User belongs to specific role.

HttpContext.Current.User.Identity.IsAuthenticated – check whether user is authenticated to proceed with block of code in the page.

HttpContext.Current.User.Identity.Name - provides name of the user logged in

Other APIs: Membership API can be used in your code to manage user information and to perform password recovery if required. Roles API is used to group Users into roles and authorization can be defined for roles instead of individual users. Profiles API is used to maintain state of the User persistently on subsequent visits to your application.

.NET provides many ways of ensuring Security. However it is up to you to use most of it in your application and guarantee secured application to Customers.

| Additional Ways of Ensuring Security in .NET | Memory Lifecycle in .NET – An Overview | Few Best Coding Practices for ASP .NET | Handling Session Efficiently Using SQLSERVER State Management in .NET | How to Restrict a Program to Single Instance in .NET? | How to Use Structured Exception Handling in .NET | Understanding Boxing Versus Unboxing in .NET | Understanding Different Levels of Security in .NET | Understanding the Disadvantages of Memory Management in .NET | Using Membership API for Secured Coding in .NET |