Banish Security Blunders with an Error-prevention Process


http://www.devx.com	Printed from http://www.devx.com/security/Article/20678/1954

Traditionally, application security is an afterthought—we build our apps and try to poke holes in them later. Why not take potential security breaches into account from the very beginning? The Automated Error Prevention Methodology provides a framework you can use to integrate security concerns into your app development right from the start.

by Dr. Adam Kolawa

ecurity can be a complex and often overwhelming issue. To ensure application security, not only must you prevent hackers from entering the system, but you need code in place that safeguards security should those preventive measures fail. There is no room for error. You can anticipate and prevent hundreds of security vulnerabilities, but if you overlook just one vulnerability, a hacker can wreak total havoc on your system.

These are the three most commonly exploited internal software weaknesses:

Dangerously-constructed SQL statements (for programs that interact with a database).
Buffer overflows (for C and C++).
Uncaught runtime exceptions (for Java, as well as .NET-based languages such as managed C and C++).

The traditional industry approach to compensate for these weaknesses is to build code, then later perform a sort of "monkey testing" intended to simulate hacker actions. Testers attempt to design and execute a large number and variety of tests which pound on the application in as many different ways as possible—all in hopes that these tests will reveal a security vulnerability, which can then be remedied prior to deployment. If fastidiously applied, this strategy can expose many critical security vulnerabilities. However, such a thorough application of this strategy is difficult and time-consuming. The test cases that must be created to identify these security vulnerabilities are typically complex, and few teams have the time and resources to write the necessary number and range of complex test cases without slipping on their deadlines and budget.

A New Security Supplement
An easier way to protect code from these three common attacks is to apply preventative practices and start improving your code's security before you write test cases specifically for security verification. The Automated Error Prevention (AEP) Methodology provides an effective and feasible way to prevent security vulnerabilities through the automated application of industry-standard best practices, such as coding standards enforcement, unit testing, integration testing, and runtime error detection. Apply the recommended AEP practices throughout the software development lifecycle, and it's possible to remove many security vulnerabilities, as well as improve the overall code quality and reliability.

Introduction to AEP
The AEP Methodology is based on the AEP Concept, which is essentially to learn from your own mistakes and the mistakes of others, and then automatically apply that knowledge in the software lifecycle to make software work.

These are its five main principles:

Apply industry best practices to prevent common errors and establish a foundation for full life-cycle error prevention.
Modify practices as needed to prevent unique errors.
Ensure that each group implements AEP correctly and consistently.
1. Introduce AEP on a group-by-group basis.
2. Ensure that each group has an appropriate supporting infrastructure.
3. Implement a group workflow that ensures error prevention practices are performed appropriately.
Phase in each practice incrementally.
Use statistics to stabilize each process, and then make it capable.

This article demonstrates how to apply the AEP Methodology using three security vulnerabilities. Along the way, you'll learn several industry best practices: two for preventing SQL injection vulnerabilities, one for preventing buffer overflow vulnerabilities, and one for preventing uncaught runtime exception vulnerabilities. These best practices, which are based on lessons learned from previous developers' security mistakes, are an example of the application of AEP Methodology Principle 1. Other available industry best practices are designed to prevent functional errors, robustness/construction errors, performance errors, and usability errors. Like all industry best practices, these security-related practices should be applied in the manner described in AEP Methodology Principles 3-5. If you later identify security vulnerabilities that are unique to your project and that are not identified by the standard AEP practices, you would apply AEP Methodology Principle 2: you would modify existing error prevention practices (or develop new ones). You would then implement the modified or new practices in the same manner that you implemented the industry-standard practices.

For more details about the AEP Methodology, including a blueprint for how to apply its five key principles to your own development group, see the AEP section of the Parasoft Website.

Editor's Note: The author, Dr. Adam Kolawa, is the chairman and CEO of Parasoft, a vendor of development tools that integrate an error-prevention process. We have selected this article for publication because we believe it to have objective technical merit. No endorsement of Parasoft products is implied by its publication.

Security Problem #1: SQL Injection Vulnerabilities
One security breach opens when SQL statements are dynamically created as software executes. If a hacker is able to pass fixed inputs into the SQL statement, the inputs can become part of the SQL statement. This technique can be used to gain access to privileged data, login to password-protected areas without a proper login, remove database tables, add new entries to the database, or even login to an application with administrator privileges. The traditional attempt to avoid this problem is to validate all user inputs, but there is a way to prevent these attacks altogether.

SQL Injection Best Practice #1: Ensure that all SQL statements recognize user inputs as variables, and that statements are precompiled before the actual inputs are substituted for the variables.

Typically, this best practice implemented as a two-stage process. In the first stage, you build and parse your SQL statements with variables in place of the expected user inputs. Next, before the statement is passed to the database, replace your variables with the user inputs. Make sure that your user inputs are never parsed as the actual SQL statement—this renders even malicious user inputs ineffective.

For instance, in Java, a secure way to build SQL statements is to construct all queries with PreparedStatement instead of Statement and/or to use parameterized stored procedures. Parameterized stored procedures are compiled before user input is added, making it impossible for a hacker to modify the actual SQL statement. When PreparedStatement is used, most JDBC drivers will prepare a statement with the server, and then supply the parameters separately. In either case, after the initial parsing, there is a clear distinction between the SQL statement and the variable. The variables are encapsulated and special characters within them are automatically escaped in a manner suited to the target database. Consequently, it is impossible for a hacker to pass malicious input and have it treated as if it were the actual SQL statement— which is necessary if the hacker is going to succeed with SQL injection attacks.

SQL Injection Best Practice #2: If you use PreparedStatement, ensure that all parameters should be inserted through appropriate JDBC calls.

Even if you use PreparedStatement, you still need to pay attention to the way in which you build arguments. All parameters should be inserted through the appropriate JDBC calls. If you concatenate the SQL sentence and omit the JDBC calls, then an attempted SQL injection could be parsed as SQL, and the hacker could succeed.

Implementing SQL Injection Best Practices
How do you ensure that code follows these best practices? Most SQL statements are created dynamically; consequently, you need to execute the application paths that create SQL statements and verify whether they are being constructed in a secure manner (i.e., that the statements are precompiled with variables before user input is added). In addition, you need to inspect the database-related code to verify that secure coding practices are being followed (for instance, the Java best practices of using PreparedStatement instead of Statement, and for using PreparedStatement correctly). The standard AEP best practices for Java, C/C++ and .NET applications that interact with a database cover both of these types of verification.

For instance, for Java applications, you would enforce the AEP coding standard and analyze the code that is responsible for forming the SQL statements, and then verify that if you build SQL for JDBC, you always use PreparedStatement. You could also verify whether all available PreparedStatements are built properly (with all parameters inserted through appropriate JDBC calls, rather than string concatenation). Moreover, to determine whether SQL statements are being built in the recommended two-step process, you could watch database calls as the application is being tested and determine if statements are always being constructed in a safe manner.

Security Problem #2: Buffer Overflow Vulnerabilities
Buffer overflows are a standard problem that affect C/C++ applications all too often. Buffer overflow attacks occur when a hacker manages to pass an input through all the program's built-in defenses and write to the buffer. It is only possible when the hacker is able to find and exploit a memory corruption bug in the application.

For example, assume that your C++ application has an array or a memory chunk on the stack, and a memory issue makes it possible to write beyond the size of the array or memory chunk, and overwrite the return address of the function. The hacker can exploit this weakness so that the function returns to a hacker-designated function, or so that the function executes a hacker-designated operation. In fact, some recently-discovered buffer overflows in major operating systems give hackers license to perform a variety of malicious actions, such as causing the system to fail, installing programs, viewing, changing, and deleting data, modifying any part of the system, and creating accounts with full privileges.

Buffer Overflow Best Practice: Identify and prevent memory corruption.

Developers traditionally try to handle buffer overflow exploits by limiting the size of the input or by verifying the input. However, it's easy to miss cases if you have no procedure for identifying all the inputs which need to be checked. To actually remove the opportunity for these attacks, you need ensure that memory corruption bugs do not occur in the released or deployed version of your software.

Implementing Buffer Overflow Best Practices
Memory corruption bugs can be prevented during integration testing. The application should be compiled with a runtime error detection tool, which detects memory corruption and pinpoints where the program is overwriting memory. As the application is being stimulated and exercised by the regression test suites, any memory corruption should be identified. You can then prevent security vulnerabilities by fixing the problem as soon as possible.

Security Problem #3: Uncaught Runtime Exception Vulnerabilities
It is true that languages such as Java and .NET (managed C/C++) do not have a problem with buffer overflows. However, these languages suffer from a different problem that is just as serious: uncaught runtime exceptions. Typical checked exceptions provide a relatively easy way to transfer flow and keep a program running when exceptional situations occur. However, unchecked runtime exceptions— exceptions that are automatically thrown by the runtime system when a program violates the language syntax/semantics— are usually an indication of software bugs. They typically stem from problems related to arithmetic, pointers, and indexing, and can occur at any point in a program. If these exceptions surface in the field, the resulting unexpected flow transfer and potential thread termination could lead to instability, unexpected results, or even crashes or security breaches. For example, a very simple NullPointerException in login code could allow a hacker to completely bypass the login procedure.

Uncaught Runtime Exception Best Practice: Identify and remove uncaught runtime exceptions.

The only real way to prevent uncaught runtime exception security vulnerabilities is to identify all possible uncaught runtime exceptions early in the development lifecycle, then examine and modify the code to ensure that it does not provide any opportunities for hackers.

Implementing Uncaught Runtime Exception Best Practices
AEP's standard unit testing practice is designed to expose uncaught runtime exceptions. As you perform the recommended AEP white-box testing practice, you will exercise each code unit with a wide variety of permissible inputs and then identify the potential runtime exceptions that could occur with those inputs. We recommend that you respond to all identified uncaught runtime exceptions before you start working on other code. The appropriate response to take for each reported exception typically varies based on the nature of the exception. However, one general preventative measure for crucial security methods is to always add to the client code a try/catch to handle any possible exception.

The Key to Success
With security, prevention is the key to success. Using preventative strategies in concert with detection-focused strategies allows you to dramatically reduce the risk of suffering from the problem you are trying to avoid, and can save you considerable time, effort, and resources. AEP can help you ensure that code is written so that later code modifications and reuse will not make the software vulnerable to attack.

Dr. Adam Kolawa is the Chairman/CEO of Parasoft, which he cofounded with a group of fellow CalTech graduate students in 1987. Kolawa's years of experience with various software development processes has resulted in his unique insight into the high-tech industry and the ability to successfully identify technology trends. He can be reached at ak@parasoft.com.