Recipe 14.12 Minimizing the Attack Surface of an Assembly

Problem

Someone attacking your assembly will first attempt to find out as many things as possible about your assembly and then use this information in constructing the attack(s). The more surface area you give to an attacker, the more they have to work with. You need to minimize what your assembly is allowed to do so that if an attacker is successful in taking over your assembly—possibly through luring it into doing something like executing a small program that attempts to email a password file back to the attacker—the attacker will not have the necessary privileges to do any damage to the system.

Solution

Use the SecurityAction.RequestRefuse enumeration member to indicate, at an assembly level, the permissions that you do not wish this assembly to have. This will force the CLR to refuse these permissions to your code and will ensure that even if another part of the system is compromised, your code cannot be used to perform functions that it does not need the rights to do.

The following example allows the assembly to perform file I/O as part of its minimal permission set but explicitly refuses to allow this assembly to have permissions to skip verification:

[assembly: FileIOPermission(SecurityAction.RequestMinimal,Unrestricted=true)]
[assembly: SecurityPermission(SecurityAction.RequestRefuse,
             SkipVerification=false)]

Discussion

Once you have determined what permissions your assembly needs as part of your normal security testing, you can use RequestRefuse to lock down your code. If this seems extreme, think of scenarios where your code could be accessing a data store with sensitive information contained, such as Social Security numbers or salary information. This proactive step can help you show your customers that you take security seriously and can help defend your interests in case of a break-in on a system your code is part of.

One serious consideration with this approach is that the use of RequestRefuse marks your assembly as partially trusted and will in turn prevent it from calling any strong-named assembly that hasn't been marked with the AllowPartiallyTrustedCallers attribute.

See Also

See the "SecurityAction Enumeration" and "Global Attributes" topics in the MSDN documentation. See Chapter 8, "Code Access Security in Practice," of Microsoft Patterns & Practices Group: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/THCMCh08.asp.