vulnerabilities that developers may fail to identify before an application goes to production that can affect both commercial and custom applications. They include authorization bypass, SQL injection vulnerabilities, buffer overflow, and information leaks.
Authorization bypass occurs when a normal user is able to access information from a Web site or other type of application that was meant to be used by an administrator or a select group of individuals.
Custom in-house applications are particularly vulnerable to SQL injection vulnerabilities. Many are connected to the Internet and are vulnerable to this type of attack, which exploits Web applications using client-supplied data in SQL queries without first removing potentially harmful characters. In this situation, data provided by a user, such as an account number and username, is used to query additional data on the SQL database. A knowledgeable attacker injects commands into a database that allow him to take control of the database--even accessing user account information and details.
A buffer overflow is another vulnerability that has plagued the commercial software industry and custom applications. It occurs when a program or process tries to store more data into a memory buffer--a temporary data-storage area--than it is intended to hold. Since buffers are created to hold a limited amount of information, the extra data spills over into adjacent memory, corrupting the valid data held in the overstuffed buffer. In many cases the overflow will enable an attacker to execute commands of his choice on the machine. Applications written in Java and other "safer" languages are still susceptible to buffer overflows when they interact with services and libraries written in native code.
Information leaks also pose a threat to applications. A single information leak often is not a serious problem, but has the potential to provide an attacker with the information necessary to launch other attacks. Error messages are a prime source of information leakage. For example, if a user purposely enters an erroneous string of text rather than an eight-digit account number, an insecure application will send the user the detailed error message generated by a component of the application, such as an SQL server. This message often provides the attacker with valuable information concerning what type and version of an SQL database is being used and how the system is constructed. These details allow the attacker to refine the attack and more easily compromise sensitive data.
Building Security into the Wireless Development Lifecycle
Each major phase of development--requirements collection, application design, and application implementation--can introduce vulnerabilities into an application. A holistic approach to building security into the development lifecycle will save tremendous amounts of time and money, because problems are identified early in the process and continually addressed during each step. Security practices should be in place during requirements planning, design time, implementation, and testing in order to catch the majority of problems as early in the cycle as possible.
It is less expensive and less disruptive to discover design-level vulnerabilities during the design, rather than discovering them during implementation or testing and forcing a costly redesign of pieces of the application. For example, if proper authentication of administrators is not built into the program from the beginning, it is much more time consuming and risky to fix during the final QA phase.
QA people who understand the importance of testing security and functionality should conduct application testing. They should apply security-testing processes that test that the security features are working properly. Additionally, they should perform negative testing to determine how the application handles unexpected data such as long strings, special characters, and error conditions. QA should use a problem-tracking system to