Improving Web Application Security: Threats and - CGISecurity

Chapter 8: Code Access Security in Practice 215●Native. This is potentially dangerous unmanaged code, but code that is protectedwith a full stack walking demand for the unmanaged code permission. These areimplicitly made by the interop layer unless they have been suppressed with theSupressUnmanagedCode attribute.class NativeMethods {[DllImport("user32")]internal static extern void FormatDrive(string driveLetter);}●Unsafe. This is potentially dangerous unmanaged code that has the securitydemand for the unmanaged code permission declaratively suppressed. Thesemethods are potentially dangerous. Any caller of these methods must do a fullsecurity review to ensure that the usage is safe and protected because no stackwalk is performed.[SuppressUnmanagedCodeSecurity]class UnsafeNativeMethods {[DllImport("user32")]internal static extern void CreateFile(string fileName);}Request the Unmanaged Code PermissionStrong-named[assembly: SecurityPermission(SecurityAction.RequestMinimum,UnmanagedCode=true)]Sandbox Unmanaged API CallsIsolate calls to unmanaged code in specific assemblies and keep the number ofassemblies that call unmanaged code to a minimum. Then, use the sandboxingpattern to ensure that the unmanaged code permission is only granted to selectedassemblies. To sandbox your managed code that calls unmanaged code1. Place your code that calls unmanaged code in a separate (wrapper) assembly.2. Add a strong name to the assembly.This allows custom code access security policy to be easily applied to theassembly. For more information, see the “Strong Names” section in Chapter 7,“Building Secure Assemblies.”3. Request the unmanaged code permission (as described in the preceding section.)