10 tips to help programmers get out of trouble

Security experts Michael Howard and Keith Brown have 10 tips to help you get out of trouble.

Security issues involve many aspects. Security risks may come from anywhere. You may have written an invalid error-handling code, or were overly generous in granting permissions. You may have forgotten what services are running on your server. You may have accepted all user input. Mailroom To give you a good start in protecting your computer, your network, and your code, here are 10 tips to follow to get a more secure network strategy.

1. Trusting the user's input will put itself at risk.

Even if you don't read the rest of the content, remember that "do not trust user input." If you always assume that the data is valid and harmless, then the problem comes. Most security vulnerabilities are related to an attacker providing malicious data to the server.

The correctness of trust input can result in buffer overflows, cross-site scripting attacks, SQL injection code attacks, and so on.

Let's discuss these potential attacks in detail.

2. Prevent buffer Overflow

A buffer overflow occurs when the attacker provides a greater length of data than the application expects, and the data overflows into the internal memory space. A buffer overflow is primarily a C + + problem. They are a threat, but they are usually easy to fix. We have seen only two buffer overflows that are not obvious and difficult to repair. The developer did not anticipate that the externally supplied data would be larger than the internal buffer. The overflow causes the destruction of other data structures in memory, which are often exploited by attackers to run malicious code. Array index errors can also cause buffer underflow and overrun, but this situation

It's not that common.

Take a look at the following C + + code fragment:

void DoSomething(char *cBuffSrc, DWORD cbBuffSrc)
{
　 char cBuffDest[32];
　 memcpy(cBuffDest,cBuffSrc,cbBuffSrc);
}

Where is the problem? In fact, if CBUFFSRC and cbbuffsrc come from trustworthy sources (such as code that does not trust data and therefore validate the validity and size of the data), then there is no problem with that code. However, if the data comes from unreliable sources and is not validated, then an attacker (untrustworthy source) can easily make cbuffsrc larger than Cbuffdest, and also set CBBUFFSRC to be larger than cbuffdest. When memcpy copies data to Cbuffdest, the return address from dosomething is changed because Cbuffdest is adjacent to the return address on the stack frame of the function, at which point the attacker can perform some malicious action through the code.

The remedy is to not trust user input and not to trust any data that is carried in CBUFFSRC and CBBUFFSRC:

void DoSomething(char *cBuffSrc, DWORD cbBuffSrc)
{
　 const DWORD cbBuffDest = 32;
　 char cBuffDest[cbBuffDest];
　 #ifdef _DEBUG
　　 memset(cBuffDest, 0x33, cbBuffSrc);
　 #endif
　 memcpy(cBuffDest, cBuffSrc, min(cbBuffDest, cbBuffSrc));
}

This function shows three attributes of a properly written function that can reduce buffer overflows. First, it requires the caller to provide the length of the buffer. Of course, you can't blindly believe this value! Next, in a debug build, the code will detect if the buffer is really large enough to hold the source buffer. If not, it is possible to trigger an access violation and load the code into the debugger. When you are debugging, you will be surprised to find so many errors. Finally, and most importantly, the call to memcpy is defensive and does not replicate data that is more than the target buffer storage capability.

In Windows Security Push at Microsoft (Microsoft Windows? Security drive activity), we created a list of safe string handling functions for C programmers. You can find them in the strsafe.h:saferstring handling in C (English).