Improving Web Application Security: Threats and - CGISecurity

738 Improving Web Application Security: Threats and CountermeasuresThreadingCheck DescriptionResults of security checks are not cached.Impersonation tokens are considered when new threads are created (any existing threadtoken is not passed to the new thread).Threads are synchronized in static class constructors for multithreaded application code.Object implementation code is designed and built to be thread safe.Threads are synchronized in static class constructors.ReflectionCheck DescriptionCaller cannot influence dynamically generated code (for example, by passing assembly andtype names as input arguments).Code demands permission for user authorization where assemblies are loaded dynamically.Unmanaged Code AccessCheck DescriptionInput and output strings that are passed between managed and unmanaged code areconstrained and validated.Array bounds are checked.File path lengths are checked and do not exceed MAX_PATH.Unmanaged code is compiled with the /GS switch.Use of “dangerous” APIs by unmanaged code is closely inspected. These includeLogonUser, RevertToSelf, CreateThread, Network APIs, and Sockets APIs.Naming conventions (safe, native, unsafe) are applied to unmanaged APIs.Assemblies that call unmanaged code specify unmanaged permission requirements usingdeclarative security (SecurityAction.RequestMinimum).Unmanaged API calls are sandboxed and isolated in a wrapper assembly.Use of SuppressUnmanagedCodeSecurityAttribute is thoroughly reviewed and additionalsecurity checks are implemented.Types are not annotated with SuppressUnmanagedCodeSecurityAttribute. (This attribute isused on specific P/Invoke method declarations instead.)Calling code is appropriately authorized using a full stack walk Demand (using either a.NET Framework permission or custom permission).