Buffer overflows
The major cause of security breaches in application code these days is buffer overflows. A buffer overflow is simply where the code allocates only a small amount of memory space for the parameters it is provided and then the function receives more data than it was expecting. Occasionally, this opens the capability for someone to run malicious code because the end of the buffer overwrites some of the application's code and, when the application goes to run its code, it accidentally runs what was at the end of the parameter that was provided.
Most people working in languages today take a relatively carefree attitude to buffer overflows. Working in Visual Basic, Visual Basic.Net, C#, Java, or one of a dozen other languages means that you don't have to worry about buffer overflows internally in your applications. Either the language itself or the underlying infrastructure automatically manages the amount of buffer space allocated for strings and other parameters. Because of this, for all practical purposes, it's impossible to overflow a buffer within the confines of an application.
The challenge comes in when you utilise an API, a COM object, or some other component that was not designed in a language that automatically manages memory allocation and buffers for you. Most of the APIs available in Windows, including the core Windows APIs, were written in C or C++. Neither of these languages have automatic management for buffers. This leaves the possibility open that you could pass in a parameter that exceeds the internal buffer and allows the execution of someone else's code.
Obviously, some consideration must be given to parameter lengths when calling outside "safe" languages. If you're taking input in directly from a user or external system and passing it along to an API, check the length of the parameter for the API. This will prevent your "safe" language from passing through an unsafe request. A few quick "sanity" checks for parameters can prevent real problems.
