Security Considerations: Windows User Interface
This topic provides information about security considerations in the Windows User Interface. This topic doesn't provide all you need to know about security issues. Instead, use it as a starting point and reference for this technology area.
With the increase in computer interconnectivity, developers now must concern themselves with application security. However, security also enhances general application safety and robustness; therefore it is another way that the developer can provide a good user experience. The following topics discuss some potential security concerns when using the Windows User Interface.
String Considerations
Many functions, messages, and macros use strings in their parameters. However, often the strings are not checked for null-termination or for length. A related concern is miscalculating the length of a string or buffer. In either case, this can lead to buffer overflow or data truncation, which can affect your application adversely. For more information about buffer overruns and other security concerns, see Writing Secure Code by Michael Howard and David Leblanc, Microsoft Press, 2002.
To handle strings in a safe manner, you should do the following:
- Check strings for null-termination or for the proper length, as appropriate.
- Take special care to determine the length of a string or buffer, especially when it contains TCHAR values.
- If you create a string or use a string that was used previously, initialize it to zero or insert a null-terminator, as appropriate.
In addition, consider using the StrSafe functions when dealing with strings. These functions are designed to handle strings safely.
User Input
The Windows user interface is concerned with getting and responding to information from users. However, users who enter incorrect data can disrupt your application, whether or not they intend to do so. Thus, the cardinal rule is that all input must be validated.
Of primary concern is string data, which is discussed in String Considerations. However, all types of input should be validated before being used by your application. Another concern is when data is validated at one point but changes before it is used, for example, when receiving messages that give the length of text. So, if there is a chance the data might change, you should check the data just before you use it
Security Alerts
The following table lists features that, if used incorrectly, can compromise the security of your applications.
| Feature | Mitigation |
|---|---|
| GetAtomName | Be careful when specifying the size of the buffer. |
| GlobalGetAtomName | Global string atoms are accessible to any application. However, if another application is careless, it could mishandle their reference counts and delete them. You should consider using global integer atoms instead. |
| ImpersonateDdeClientWindow | If the function fails, subsequent client requests are made in the security context of the calling process. This can be a problem if the calling process is running as a highly privileged account. Therefore, if the call fails or raises an error do not continue execution of the client request. |
| DdeImpersonateClient | If the function fails, subsequent client requests are made in the security context of the calling process. This can be a problem if the calling process is running as a highly privileged account. Therefore, if the call fails or raises an error do not continue execution of the client request. |
| GetClipboardFormatName | Miscalculating the proper size of the lpszFormatName buffer, especially when the application is used in both ANSI and Unicode versions, can cause a buffer overflow. Also, note that the string is truncated if it is longer than the cchMaxCount parameter, which can lead to loss of information. |
| GetMenuString | The lpString parameter is a TCHAR buffer, and nMaxCount is the length of the menu string in TCHARs. Sizing these parameters incorrectly can is the length of the menu string in characters. Sizing these parameters incorrectly can cause truncation of the string, leading to possible loss of data. |
| GetStringTypeA, GetStringTypeEx, GetStringTypeW | To avoid a buffer overflow, set the size of the lpCharType buffer correctly. |
| LoadLibrary | Using LoadLibrary incorrectly can compromise the security of your application by loading the wrong DLL. |
| LoadString | Incorrect use includes specifying the wrong size in the nBufferMax parameter. For example, sizeof(lpBuffer) gives the size of the buffer in bytes, which could lead to a buffer overflow for the Unicode version of the function. Buffer overflow situations are the cause of many security problems in applications. In this case, using sizeof(lpBuffer)/sizeof(TCHAR) gives the proper size of the buffer. |
| lstrcat | This function uses structured exception handling (SEH) to catch access violations and other errors. When this function catches SEH errors, it returns NULL without null-terminating the string and without NULL without null-terminating the string and without notifying the caller of the error. The caller is not safe to assume that insufficient space is the error condition. The first argument, lpString1, must be large enough to hold lpString2 and the closing '\0', otherwise a buffer overrun may occur. Buffer overruns may lead to a denial of service attack against the application if an access violation occurs. In the worst case, a buffer overrun may allow an attacker to inject executable code into your process, especially if lpString1 is a stack-based buffer. Consider using one of the following alternatives. StringCbCat or StringCchCat. |
| lstrcpy | This function uses structured exception handling (SEH) to catch access violations and other errors. When this function catches SEH errors, it returns NULL without null-terminating the string and without NULL without null-terminating the string and without notifying the caller of the error. The caller is not safe to assume that insufficient space is the error condition. The first argument, lpString1, must be large enough to hold lpString2 and the closing '\0', otherwise a buffer overrun may occur. Buffer overruns may lead to a denial of service attack against the application if an access violation occurs. In the worst case, a buffer overrun may allow an attacker to inject executable code into your process, especially if lpString1 is a stack-based buffer. Consider using StringCchCopy instead. |
| lstrcpyn | This function uses structured exception handling (SEH) to catch access violations and other errors. When this function catches SEH errors, it returns NULL without null-terminating the string and without NULL without null-terminating the string and without notifying the caller of the error. The caller is not safe to assume that insufficient space is the error condition. If lpString1 is not large enough to contain the copied string, a buffer overrun can occur. Also, when copying an entire string, note that sizeof returns the number of bytes rather than WCHAR, that sizeof returns the number of bytes rather than characters, which is incorrect for the Unicode version of this function. Buffer overruns can cause a denial of service attack against the application if an access violation occurs. In the worst case, a buffer overrun may allow an attacker to inject executable code into your process, especially if lpString1 is a stack-based buffer. Consider using StringCchCopy instead. |
| lstrlen | lstrlen assumes that lpString is a null-terminated string. If it is not, this could lead to a buffer overrun or a denial of service attack against your application. Consider using one of the following alternatives. StringCbLength or StringCchLength. |
| wsprintf | The string returned in lpOut is not guaranteed to be null-terminated. Also, avoid the %s format, which can lead to a buffer overrun. If an access violation occurs it causes a denial of service against your application. In the worse case, an attacker can inject executable code. Consider using one of the following alternatives. StringCbPrintf, StringCbPrintfEx, StringCbVPrintf, StringCbVPrintfEx, StringCchPrintf, StringCchPrintfEx, StringCchVPrintf, or StringCchVPrintfEx. |
| wvsprintf | The string returned in lpOutput is not guaranteed to be null-terminated. Also, avoid the use of the %s format, which can lead to a buffer overrun. This can lead to a denial of service if it results in an access violation, or an attacker may inject executable code. Consider using one of the following alternatives. StringCbPrintf, StringCbPrintfEx, StringCbVPrintf, StringCbVPrintfEx, StringCchPrintf, StringCchPrintfEx, StringCchVPrintf, or StringCchVPrintfEx. |
Related topics