Improving Web Application Security: Threats and - CGISecurity

Chapter 21: Code Review 629●●Is the unmanaged entry point publicly visible?Check that your unmanaged code entry point is marked as private or internal.Callers should be forced to call the managed wrapper method that encapsulatesthe unmanaged code.Do you guard against buffer overflows?Unmanaged code is susceptible to input attacks such as buffer overflows.Unmanaged code APIs should check the type and length of supplied parameters.However, you cannot rely on this because you might not own the unmanagedsource. Therefore, the managed wrapper code must rigorously inspect input andoutput parameters. For more information, see “Buffer Overflows” in this chapter.Note All code review rules and disciplines that apply to C and C++ apply to unmanaged code.●●●Do you range check enumerated types?Verify that all enumerated values are in range before you pass them to a nativemethod.Do you use naming conventions for unmanaged code methods?All unmanaged code should be inside wrapper classes that have the followingnames: NativeMethods, UnsafeNativeMethods, and SafeNativeMethods. Youmust thoroughly review all code inside UnsafeNativeMethods and parametersthat are passed to native APIs for security vulnerabilities.Do you call potentially dangerous APIs?You should be able to justify the use of all Win32 API calls. Dangerous APIsinclude:● Threading functions that switch security context● Access token functions, which can make changes to or disclose informationabout a security token● Credential management functions, including functions that creates tokens●●●Crypto API functions that can decrypt and access private keysMemory Management functions that can read and write memoryLSA functions that can access system secrets