Stop intruders exploiting applications
Published: 09 Feb 2004 10:45 GMT
Designing for application security is one thing; keeping someone out of your application is important; however, allowing someone to take control of a system through your application can be substantially worse. Designing your applications to prevent a system-level security breach is significantly different from preventing security vulnerabilities at the application level. In application security, you're looking for things that are entirely in your control. In designing applications for system security, you're trying to prevent security vulnerabilities from occurring in your own code as well as the code that your code uses.
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.
Previous
Did you find this article useful?
200 out of 452 people found this useful
Digg
Slashdot
Del.ici.ous
Stumble
Reddit
