Wang Lingfeng compiled
During the Microsoft Windows Security Push event held by Microsoft, a batch of testers, program management managers and ordinary programmers jointly decided to customize a string handler with higher security for C language, and hope these functions Can be adopted by the programmers within the Windows programmer and Microsoft.
Simply put, the existing C language runtime function is difficult to be based on the big environment that is full of malicious attacks attempts. These functions either lack consistency on the return value and parameters, either implies a so-called "truncation error" error or unable to provide sufficient powerful features. Conduct, calling the code to call these functions is too easy to generate a "memory overflow" problem.
We have found that the classes for C programmers are sufficient to cope with various security handling strings; they can choose the MFC's CSTRING class, ATL's CCOMBSTR class or STL's String class, and so on. However, classic C language procedures are still generally existed, let alone many people are using C as "improved C language", but put rich C categories.
In fact, you only need to add a line of code, you can call the STRSAFE series functions in the C language code (see "Using The Strsafe.h Functions). These new functions are included in a header file and a library (optional), and the last two can be found in the new version of Platform SDK. Yes, it is as simple:
#include "strsafe.h"
What are you waiting for!
Rethony again, reference to the StrsaFe library is optional.
In order to achieve the goal of the strsafe series, your code must meet the following conditions:
· Always end strings with NULL characters.
• Always detect the length of the target buffer.
· Always produce a unified return value with the HRESULT statement.
· Take into account 32 bits and 64-bit operational environments.
· It is flexible.
We feel that lack of unity is the root cause of the existing C language string processing function that is easy to generate security vulnerabilities, and the highly uniformity of the StrsaFe series function is exactly a good medicine to solve this problem. However, Strsafe is not universal medicine. Simply relying on STRSAFE series functions and cannot guarantee the security and robustness of the code - you must also start your brains - however, this is also helpful to solve the problem!
The following is a code that uses a classic C language runtime function:
Void unsafefunc (lptstr szpath, dword cchpath) {
Tchar Szcwd [MAX_PATH];
GetCurrentDirectory (arraysize (szcwd), szcwd);
STRNCPY (Szpath, Szcwd, Cchpath);
Strncat (Szpath, Text ("), CCHPATH);
Strncat (Szpath, Text ("Desktop.ini"), CCHPATH);
}
BUG in the above code can be seen everywhere - it does not check any return value, and does not correctly use cchpath in the call to the Strncat function (because the max_path is saved is the length of the remaining space in the target buffer, not the target. The total length of the buffer). So, the "memory overflow" problem will come to the door. However, the code snacks like this have already been disaster.
If you switch to the strsafe series function, then the above code should become:
Bool SaferFunc (LPTSTSTSTSTSTSTSTSTSZPATH) {
Tchar Szcwd [MAX_PATH];
IF (Arraysize (SZCWD), SZCWD && successEded (Stringcchcopy (Szpath, cchpath, szcwd) &&
Succeeded (StringCchcat (Szpath, Cchpath, Text ("))) &&
Succeeded (StringCchcat (Szpath, Cchpath, Text ("Desktop.ini"))))))
Return True;
}
Return False;
}
This code not only checks each return value, but also guarantees the total length of the same target buffer in a timely manner. You can also use the EX version of the Strsafe series function to achieve more advanced features, such as:
· Get the current pointer to the target buffer.
· Get the remaining space length of the target buffer.
• Fill the empty buffer in a particular character.
· Once the string processing function fails, fill the string with a particular value.
· Once the string handle function fails, set the target buffer into null.
How is this improved code performance? Tell you a good news: it is almost no difference in performance with the original code. I have tested the code of various string connection functions in the classic C language on my own 1.8 GHz computer, mixing the code of various string connection functions in the Strsafe series, and mixing the EX version STRSAFE series various string connection functions Code. They have their own independently run a million (yes, 10,000,000) consumes the time of:
· Classic C Language - 7.3 seconds
· STRSAFE series - 8.3 seconds
· STRSAFE series (EX version) - 11.1 seconds
In the test, the program that calls the EX version of the strsafe series function will set the buffer to NULL when the call fails, and the code is as follows:
DWORD DWFLAGS = strsafe_null_on_failure | strsafe_fill_byte (0xfe);
There is more time consumption in which the code filled bytes is set. In fact, if you only set the buffer to null, the code using the EX version of the STRSAFE series function will be the same as the code used by the normal STRSAFE series function.
It can be seen that the performance differences in the above three programs are extremely small. I believe that you will not repeatedly execute the code containing a large number of string handle functions in a program!
It is also worth noting that when you reference the STRSAFE series function, the original C language string handler will be automatically downloaded. This is no problem, because the error information during the debugging process will tell you which functions have been replaced by the corresponding STRSAFE series functions.
Ok, please use strsafe.h with confidence! See "Using The Strsafe.h Functions" for more information.
