There are many ways to secure different parts of your application. The security of running code in .NET revolves around the concept of Code Access Security (CAS).
CAS determines the trustworthiness of an assembly based upon its origin and the characteristics of the assembly itself, such as its hash value. For example, code installed locally on the machine is more trusted than code downloaded from the Internet. The runtime will also validate an assembly’s metadata and type safety before that code is allowed to run.
There are many ways to write secure code and protect data using the .NET Framework. In this chapter, we explore such things as controlling access to types, encryption and decryption, random numbers, securely storing data, and using programmatic and declarative security.
Problem
You have an existing class that contains sensitive data, and you do not want clients to have direct access to any objects of this class. Instead, you want an intermediary object to talk to the clients and to allow access to sensitive data based on the client’s credentials. What’s more, you would also like to have specific queries and modifications to the sensitive data tracked, so that if an attacker manages to access the object, you will have a log of what the attacker was attempting to do.
Solution
Use the proxy design pattern to allow clients to talk directly to a proxy object. This proxy object will act as gatekeeper to the class that contains the sensitive data. To keep malicious users from accessing the class itself, make it private, which will at least keep code without the ReflectionPermissionFlag. MemberAccess access (which is currently given only in fully trusted code scenarios such as executing code interactively on a local machine) from getting at it.
The namespaces we will be using are:
using System;
using System.IO;
using System.Security;
using System.Security.Permissions;
using System.Security.Principal;
Let’s start this design by creating an interface, as shown in Example 17-1, “ICompanyData interface”, that will be common to both the proxy objects and the object that contains sensitive data.
Example 17-1. ICompanyData interface
internal interface ICompanyData
{
string AdminUserName
{
get;
set;
}
string AdminPwd
{
get;
set;
}
string CEOPhoneNumExt
{
get;
set;
}
void RefreshData();
void SaveNewData();
}
The CompanyData class shown in Example 17-2, “CompanyData class” is the underlying object that is “expensive” to create.
Example 17-2. CompanyData class
internal class CompanyData : ICompanyData
{
public CompanyData()
{
Console.WriteLine("[CONCRETE] CompanyData Created");
// Perform expensive initialization here.
this.AdminUserName ="admin";
this.AdminPd ="password";
this.CEOPhoneNumExt ="0000";
}
public str ing AdminUserName
{
get;
set;
}
public string AdminPwd
{
get;
set;
}
public string CEOPhoneNumExt
{
get;
set;
}
public void RefreshData()
{
Console.WriteLine("[CONCRETE] Data Refreshed");
}
public void SaveNewData()
{
Console.WriteLine("[CONCRETE] Data Saved");
}
}
The code shown in Example 17-3, “CompanyDataSecProxy security proxy class” for the security proxy class checks the caller’s permissions to determine whether the CompanyData object should be created and its methods or properties called.
Example 17-3. CompanyDataSecProxy security proxy class
public class CompanyDataSecProxy : ICompanyData
{
public CompanyDataSecProxy()
{
Console.WriteLine("[SECPROXY] Created");
// Must set principal policy first.
appdomain.CurrentDomain.SetPrincipalPolicy(PrincipalPolicy.
WindowsPrincipal);
}
private ICompanyData coData = null;
private PrincipalPermission admPerm =
new PrincipalPermission(null, @"BUILTIN\Administrators", true);
private PrincipalPermission guestPerm =
new Pr incipalPermission(null, @"BUILTIN\Guest", true);
private PrincipalPermission powerPerm =
new PrincipalPermission(null, @"BUILTIN\PowerUser", true);
private PrincipalPermission userPerm =
new PrincipalPermission(null, @"BUILTIN\User", true);
public string AdminUserName
{
get
{
string userName = ";
try
{
admPerm.Demand();
Startup();
userName =coData.AdminUserName;
}
catch(SecurityException e)
{
Console.WriteLine("AdminUserName_get failed! {0}",e.ToString());
}
return (userName);
}
set
{
try
{
admPerm.Demand();
Startup();
coData.AdminUserName = value;
}
catch(SecurityException e)
{
Console.WriteLine("AdminUserName_set failed! {0}",e.ToString());
}
}
}
public string AdminPwd
{
get
{
string pwd = ";
try
{
admPerm.Demand();
Startup();
pwd = coData.AdminPwd;
}
catch(SecurityException e)
{
Console.WriteLine("AdminPwd_get Failed! {0}",e.ToString());
}
return (pwd);
}
set
{
try
{
admPerm.Demand();
Startup();
coData.AdminPwd = value;
}
catch(SecurityException e)
{
Console.WriteLine("AdminPwd_set Failed! {0}",e.ToString());
}
}
}
public string CEOPhoneNumExt
{
get
{
string ceoPhoneNum = ";
try
{
admPerm.Union(powerPerm).Demand();
Startup();
ceoPhoneNum = coData.CEOPhoneNumExt;
}
catch(SecurityException e)
{
Console.WriteLine("CEOPhoneNum_set Failed! {0}",e.ToString());
}
return (ceoPhoneNum);
}
set
{
try
{
admPerm.Demand();
Startup();
coData.CEOPhoneNumExt = value;
}
catch(SecurityException e)
{
Console.WriteLine("CEOPhoneNum_set Failed! {0}",e.ToString());
}
}
}
public void RefreshData()
{
try
{
admPerm.Union(powerPerm.Union(userPerm)).Dem and();
Startup();
Console.WriteLine("[SECPROXY] Data Refreshed");
coData.RefreshData();
}
catch(SecurityException e)
{
Console.WriteLine("RefreshData Failed! {0}",e.ToString());
}
}
public void SaveNewData()
{
try
{
admPerm.Union(powerPerm).Demand();
Startup();
Console.WriteLine("[SECPROXY] Data Saved");
coData.SaveNewData();
}
catch(SecurityException e)
{
Console.WriteLine("SaveNewData Failed! {0}",e.ToString());
}
}
// DO NOT forget to use [#define DOTRACE] to control the tracing proxy.
private void Startup()
{
if (coData == null)
{
#if (DOTRACE)
coData = new CompanyDataTraceProxy();
#else
coData = new CompanyData();
#endif
Console.WriteLine("[SECPROXY] Refresh Data");
coData.RefreshData();
}
}
}
When creating thePrincipalPermissions as part of the object construction, you are using string representations of the built-in objects (“BUILTIN\Administrators”) to set up the principal role. However, the names of these objects may be different depending on the locale the code runs under. It would be appropriate to use the WindowsAccountType.Administrator enumeration value to ease localization because this value is defined to represent the administrator role as well. We used text here to clarify what was being done and also to access the PowerUsers role, which is not available through the WindowsAccountType enumeration.
If the call to the CompanyData object passes through the CompanyDataSecProxy, then the user has permissions to access the underlying data. Any access to this data may be logged, so the administrator can check for any attempt to hack the CompanyData object. The code shown in Example 17-4, “CompanyDataTraceProxy tracing proxy class” is the tracing proxy used to log access to the various method and property access points in the CompanyData object (note that the CompanyDataSecProxy contains the code to turn this proxy object on or off).
Example 17-4. CompanyDataTraceProxy tracing proxy class
public class CompanyDataTraceProxy : ICompanyData
{
public CompanyDataTraceProxy()
{
Console.WriteLine("[TRACEPROXY] Created");
string path = Path.GetTempPath() + @"\CompanyAccessTraceFile.txt";
fileStream = new FileStream(path, FileMode.Append,
FileAccess.Write, FileShare.None);
traceWriter = new StreamWriter(fileStream);
coData = new CompanyData();
}
private ICompanyData coData = null;
private FileStream fileStream = null;
private StreamWriter traceWriter = null;
public string AdminPwd
{
get
{
traceWriter.WriteLine("AdminPwd read by user.");
traceWriter.Flush();
return (coData.AdminPwd);
}
set
{
traceWriter.WriteLine("AdminPwd written by user.");
traceWriter.Flush();
coData.AdminPwd = value;
}
}
public string AdminUserName
{
get
{
traceWriter.WriteLine("AdminUserName read by user.");
traceWriter.Flush();
return (coData.AdminUserName);
}
set
{
traceWriter.WriteLine("AdminUserName written by user.");
traceWriter.Flush();
coData.AdminUserName = value;
}
}
public string CEOPhoneNumExt
{
get
{
traceWriter.WriteLine("CEOPhoneNumExt read by user.");
traceWriter.Flush();
return (coData.CEOPhoneNumExt);
}
set
{
traceWriter.WriteLine("CEOPhoneNumExt written by user.");
traceWriter.Flush();
coData.CEOPhoneNumExt = value;
}
}
public void RefreshData()
{
Console.WriteLine("[TRACEPROXY] Refresh Data");
coData.RefreshData();
}
public void SaveNewData()
{
Console.WriteLine("[TRACEPROXY] Save Data");
coData.SaveNewData();
}
}
The proxy is used in the following manner:
// Create the security proxy here.
CompanyDataSecProxy companyDataSecProxy = new CompanyDataSecProxy( );
// Read some data.
Console.WriteLine("CEOPhoneNumExt: " + companyDataSecProxy.CEOPhoneNumExt);
// Write some data.
companyDataSecProxy.AdminPwd = "asdf";
companyDataSecProxy.AdminUserName = "asdf";
// Save and refresh this data.
companyDataSecProxy.SaveNewData( );
companyDataSecProxy.RefreshData( );
Note that as long as the CompanyData object was accessible, you could have also written this to access the object directly:
// Instantiate the CompanyData object directly without a proxy.
CompanyData companyData = new CompanyData( );
// Read some data.
Console.WriteLine("CEOPhoneNumExt: " + companyData.CEOPhoneNumExt);
// Write some data.
companyData.AdminPwd = "asdf";
companyData.AdminUserName = "asdf";
// Save and refresh this data.
companyData.SaveNewData();
companyData.RefreshData();
If these two blocks of code are run, the same fundamental actions occur: data is read, data is written, and data is updated/refreshed. This shows you that your proxy objects are set up correctly and function as they should.
Discussion
The proxy design pattern is useful for several tasks. The most notable-in COM, COM+, and .NET remoting-is for marshaling data across boundaries such as AppDomains or even across a network. To the client, a proxy looks and acts exactly the same as its underlying object; fundamentally, the proxy object is just a wrapper around the object.
A proxy can test the security and/or identity permissions of the caller before the underlying object is created or accessed. Proxy objects can also be chained together to form several layers around an underlying object. Each proxy can be added or removed depending on the circumstances.
For the proxy object to look and act the same as its underlying object, both should implement the same interface. The implementation in this recipe uses an ICompanyData interface on both the proxies (CompanyDataSecProxy and CompanyDataTraceProxy) and the underlying object (CompanyData). If more proxies are created, they, too, need to implement this interface.
The CompanyData class represents an expensive object to create. In addition, this class contains a mixture of sensitive and nonsensitive data that requires permission checks to be made before the data is accessed. For this recipe, the CompanyData class simply contains a group of properties to access company data and two methods for updating and refreshing this data. You can replace this class with one of your own and create a corresponding interface that both the class and its proxies implement.
The CompanyDataSecProxy object is the object that a client must interact with. This object is responsible for determining whether the client has the correct privileges to access the method or property that it is calling. The get accessor of the AdminUserName property shows the structure of the code throughout most of this class:
public string AdminUserName
{
get
{
string userName = ";
try
{
admPerm.Demand( );
Startup( );
userName = coData.AdminUserName;
}
catch(SecurityException e)
{
Console.WriteLine("AdminUserName_get ailed!: {0}",e.ToString( ));
}
return (userName);
}
set
{
try
{
admPerm.Demand( );
Startup( );
coData.AdminUserName = value;
}
catch(SecurityException e)
{
Console.WriteLine("AdminUserName_set Failed! {0}",e.ToString( ));
}
}
}
Initially, a single permission (AdmPerm) is demanded. If this demand fails, a SecurityException, which is handled by the catch clause, is thrown. (Other exceptions will be handed back to the caller.) If the Demand succeeds, the Startup method is called. It is in charge of instantiating either the next proxy object in the chain (CompanyDataTraceProxy) or the underlying CompanyData object. The choice depends on whether the DOTRACE preprocessor symbol has been defined. You may use a different technique, such as a registry key to turn tracing on or off, if you wish.
This proxy class uses the private field coData to hold a reference to an ICompanyData type, which can be either a CompanyDataTraceProxy or the CompanyData object. This reference allows you to chain several proxies together.
Senior C# & SharePoint Developer in the market
10 years experience in various industries
BSC Degree in Computer Science (Cum Laude)
tomas.floyd@outlook.com
https://sharepointsamurai.wordpress.com
The CompanyDataTraceProxy simply logs any access to the CompanyData object’s information to a text file. Since this proxy will not attempt to prevent a client from accessing the CompanyData object, the CompanyData object is created and explicitly called in each property and method of this object.
.
SharePoint Samurai 