Secure ASP.NET

LANGUAGES: ALL

ASP.NET VERSIONS: 1.1

Comparable Consent

All Permissions Are Not Alike

By Don Kiely

In the last couple of columns I ve been exploring some of the details about developing partially trusted ASP.NET applications, one of the most fundamental ways that you can protect yourself and your users from many of the most common attacks out on the network. Fundamental to a partially trusted app is how the .NET Common Language Runtime (CLR) makes available both unrestricted and restricted permissions. In most cases, you should request and grant the most restrictive form of a permission your app can get away with. To grant anything beyond the minimum is to build an insecure application.

Take FileIOPermission, for example. This is a permission that ASP.NET developers often fall afoul of when writing partially trusted applications. You can tell a lot about the characteristics of a permission class by its constructors, and FileIOPermission has three variations (in VB.NET):

Public Sub New(ByVal state As PermissionState)

Public Sub New(ByVal access As FileIOPermissionAccess, ByVal path As String)

Public Sub New(ByVal access As FileIOPermissionAccess, ByVal pathList() As String)

The last two are variations of a theme, so there are two fundamental ways to instantiate this permission. In the first, you can pass a member of the PermissionState enumeration, which has but two options: None and Unrestricted. None simply means that the current code has no permission to read or write to or from any disk file. This is the totally restrictive state of the FileIOPermission, indicating that whatever code this instance of the permission class is applied to has no file IO permissions at all.

The other option of the PermissionState enumeration, Unrestricted, essentially tells the CLR to bypass all file IO permission checking, since this code has unfettered permission to read or write wherever it wants to. Obviously I hope! this is not a permission that you ll ever give to an ASP.NET application, because then a hacker who got control of the app could party on anywhere on your file system that struck his or her fancy.

BIG CAVEAT! Code access security permissions are not a way to circumvent operating system permissions and privileges! Even if your assembly has unrestricted FileIOPermission within the world of the CLR, if the process identity under which the app is running ASPNET or NETWORK SERVICES by default doesn t have permission to read or write somewhere, your app isn t going to be able to read or write there. It would be a huge security hole if it could!

So the first FileIOPermission constructor is a way to grant complete file IO access or to completely withhold it. The other two constructors grant a restricted permission to either a single file or directory or to combinations of multiple files and directories. In either case, the first parameter specifies the type of file access being granted, using the FileIOPermissionAccess enumeration, which has all the variations you d expect: Read, Write, Append, and PathDiscovery (to access information in the path itself), as well as AllAccess and NoAccess to grant or deny every type of access.

The second argument to these two constructors is either a single path string or an array of path strings to which the access type is applied. Here is one example of the many possible variations:

Dim ioPerm As New FileIOPermission(FileIOPermissionAccess.AllAccess, "C:\MyDir\MyFile.txt")

Like most permission objects, FileIOPermission also has a full complement of properties and methods for configuring an instance of the permission and affecting how the CLR handles stack walks and other protections against various attacks.

Most .NET permissions have both unrestricted and restricted forms. Following the principle of least privilege, you should grant code only the permissions it requires to do its job, no more and no less. This means that it should be extremely rare that you grant code an unrestricted permission. In the case of FileIOPermission, you should never do it.

Next time I ll explore these and other features of .NET permissions.

Don Kiely is senior technology consultant for Information Insights, a business and technology consultancy in Fairbanks, AK. E-mail him at mailto:donkiely@computer.org.