Improving Web Application Security: Threats and - CGISecurity

Chapter 21: Code Review 615Buffer OverflowsWhen you review code for buffer overflows, focus your review efforts on your codethat calls unmanaged code through the P/Invoke or COM interop layers. Managedcode itself is significantly less susceptible to buffer overflows because array boundsare automatically checked whenever an array is accessed. As soon as you call aWin32 DLL or a COM object, you should inspect the API calls closely.The following process helps you to locate buffer overflow vulnerabilities:1. Locate calls to unmanaged code.Scan your source files for “System.Runtime.InteropServices,” which is thenamespace name used when you call unmanaged code.2. Check the string parameters passed to unmanaged APIs.These parameters are a primary source of buffer overflows. Check that your codechecks the length of any input string to verify that it does not exceed the limitdefined by the API. If the unmanaged API accepts a character pointer, you maynot know the maximum allowable string length unless you have access to theunmanaged source. A common vulnerability is shown in the following codefragment:void SomeFunction( char *pszInput ){char szBuffer[10];// Look out, no length checks. Input is copied straight into the buffer// Should check length or use strncpy.strcpy(szBuffer, pszInput);. . .}Note Buffer overflows can still occur if you use strncpy because it does not check for sufficientspace in the destination string and it only limits the number of characters copied.If you cannot inspect the unmanaged code because you do not own it, rigorouslytest the API by passing in deliberately long input strings and invalid arguments.3. Check file path lengths.If the unmanaged API accepts a file name and path, check that your wrappermethod checks that the file name and path do not exceed 260 characters. This isdefined by the Win32 MAX_PATH constant. Also note that directory names andregistry keys can be 248 characters maximum.