ASP.NET 2.0 Security Inspection Questions - Code Access Security

From Guidance Share

Jump to: navigation, search

- J.D. Meier, Alex Mackman, Blaine Wastell, Prashant Bansode, Jason Taylor, Rudolph Araujo


Contents

Code Access Security Vulnerabilities and Implications

Vulnerability

Implications

Improper use of link demands or asserts

The code is susceptible to luring attacks.

Code allows untrusted callers

Malicious code can use the code to perform sensitive operations and access resources.


Code access security is a resource-constraint model designed to restrict the types of system resources that the code can access and the types of privileged operations that the code can perform. These restrictions are independent of the user who calls the code or the user account under which the code runs. If the code you are reviewing operates in partially-trusted environments and uses explicit code access security techniques, review it carefully to make sure that code access security is used appropriately. Table 7 shows possible vulnerabilities that occur with improper use of code access security.

If your code uses explicit code access security techniques, review it for the following:

  • Does the code use link demands or assert calls?
  • Does the code use AllowPartiallyTrustedCallersAttribute?
  • Does the code use potentially dangerous permissions?
  • Does the code give dependencies too much trust?


Does the code use link demands or assert calls?

Look closely at each use of LinkDemand and Assert calls. These can open the code to luring attacks because the code access stack walk will be stopped before it is complete. While the use of these calls is sometimes necessary for performance reasons, make sure that there can be no un-trusted callers higher in the stack that could use this method's LinkDemand or Assert call as a mechanism for attack.


Does the code use AllowPartiallyTrustedCallersAttribute?

Pay particular attention if the code you are reviewing allows partially trusted callers by including the following attribute.

[assembly: AllowPartiallyTrustedCallersAttribute()]
 

This allows the assembly to be accessible from calling code that is not fully trusted. If the code you are reviewing then calls an assembly that does not allow partially trusted callers, a security issue could result.


Does the code use potentially dangerous permissions?

Check the code for requests to potentially dangerous permissions such as: UnmanagedCode, MemberAccess, SerializationFormatter, SkipVerification, ControlEvidence / ControlPolicy, ControlAppDomain, ControlDomainPolicy, and SuppressUnmanagedCodeSecurityAttribute.

The following code example uses SuppressUnmanagedCodeSecurityAttribute. You should flag this as a dangerous practice.

[DllImport("Crypt32.dll", SetLastError=true, CharSet=System.Runtime.InteropServices.CharSet.Auto)]
[SuppressUnmanagedCodeSecurity]
private static extern bool CryptProtectData(
 ref DATA_BLOB pDataIn, 
 string szDataDescr, 
 ref DATA_BLOB pOptionalEntropy,
 IntPtr pvReserved, 
 ref CRYPTPROTECT_PROMPTSTRUCT pPromptStruct, 
 int dwFlags, 
 ref DATA_BLOB pDataOut);


Does the code give dependencies too much trust?

Without explicit safeguards, it is possible for an attacker to trick your code into loading a malicious library instead of trusted code. Check to see if all the loaded assemblies are strongly named; this step ensures that tampering cannot occur. Without strong names, your code could be calling into malicious code without knowing it. The use of native code libraries makes this harder to do so be cautious about trusting native code implicitly. Native libraries can be checked with a hash or a certificate. Additionally you should make sure that all libraries are loaded with a complete path in order to avoid canonicalization attacks.

Also check whether delay signing is enabled. Delay signing is generally regarded as a good practice because it helps protect the confidentiality of the private key that will be used for signing the component:

[assembly:AssemblyDelaySignAttribute(true)]
Personal tools