As the number of Web applications grows so does the number of vulnerabilities introduced. Failure to follow proper coding guidelines can expose an organization, its employees, and its customers to malicious attacks.

This is the first in a series of articles in which I explore the Open Web Application Security Project (OWASP) Top Ten and how the OWASP recommendations for dealing with the identified vulnerabilities can be integrated into your Software Development Lifecycle.

Business risk

As organizations rush to provide access to information via browser-based user interfaces -- and as they increase the amount of integration between applications with Web services -- business risk is rising. It isn't that developers are any less concerned about writing good code. Instead it's due to the change in the increased exposure of that code to the outside world -- the Internet. According to the OWASP:

"When an organization puts up a Web application, they invite the world to send them HTTP requests. Attacks buried in these requests sail past firewalls, filters, platform hardening, and intrusion detection systems without notice� This means that your Web application code is part of your security perimeter. As the number, size and complexity of your Web applications increases, so does your perimeter exposure." ("The Ten Most Critical Web Application Security Vulnerabilities", January 27, 2004).

Many, if not most, new applications developed by organizations today are Web applications. In addition, Web services are frequently deployed to implement intra-system integration. Any new solution where a third party application is a possibility often carries a requirement for a browser-based front-end. The problem is that this growth in Web applications and services can easily outpace developer security training and awareness.

Because of this growing pool of potential Web application security issues, the OWASP put together a top ten list of the most critical Web application security vulnerabilities. Created in collaboration with a large number of service providers and end-user organizations, the Top Ten List includes recommendations for ensuring that these vulnerabilities don't find their way into your production systems.

The OWASP Top Ten has also become a guide to determine whether organizations are practicing due diligence when safeguarding customer information. For example, the Federal Trade Commission (FTC) used the list as a reference point for information security in a June 2003 Facts for Business document. That same year, the FTC used the OWASP Top Ten as a reference in its charge that Guess, Incorporated was not providing sufficient information security to protect customer data. More recently, BJ's Wholesale Club was the focus of an FTC action based on the list.

The Top Ten List

The following is the Top Ten List as documented in the OWASP Top Ten Project: (OWASP, 2006):

  1. Unvalidated Input -- Failure to check data moving into an application before it is processed is a common programming mistake. As we explore each of the vulnerabilities in more detail, it will become quickly apparent that unvalidated input is the underlying cause for most Web application security holes.
  2. Broken Access Control -- Most organizations are very conscientious about establishing access controls. However, allowing certain input strings can enable an attack that bypasses these controls.
  3. Broken Authentication and Session Management -- Establishing strong access controls isn't enough. Organizations must also protect passwords, session tokens, account lists, and any other information that might provide an attacker with enough knowledge about the network to crack security controls.
  4. Cross Site Scripting (XSS) Flaws -- XSS is a common attack vector. Once an attack script is embedded in a server Web page or other commonly accessed Web resource, it will be executed by any unprotected workstation accessing that resource. This can result in the compromise of hundreds or thousands of employee or customer end-user devices.
  5. Buffer Overflows -- Buffer overflows are caused by a common mistake programmers make when using low level languages like C. The programming error consists of failing to check input to ensure it fits into the memory allocated for it. As we'll see later in this series, using development environments like Java and .Net can all but eliminate this vulnerability.
  6. Injection Flaws -- Failure disallow syntactic input can result in unauthorized access to database information. Input into Web forms, for example, should be simple, non-executable character strings.
  7. Improper Error Handling -- It's normal to provide error messages to inform users when an error occurs. However, providing too much information can help an attacker footprint a target network.
  8. Insecure Storage -- A common challenge is the secure storage of passwords, account names, and other information related to inter-application authentication. Encrypting this information is the best approach, but some organizations choose not to use well-tested encryption solutions.
  9. Application Denial of Service -- Like network Denial of Service (DoS), application DoS is the use of application resources by unauthorized users such that authorized users are unable to work.
  10. Insecure Configuration Management -- The existence of an effective configuration management process can provide for the hardening of both Web applications as well as the underlying infrastructure.

There are two points about this list I want to make. First, this list is not a complete list of all the vulnerabilities that might plague an organization's Web application environments. It's simply the OWASP member organizations' take on the most critical issues you might encounter.

Second, the list is not in any particular order. It's up to each organization to determine how to order the vulnerabilities listed based on its unique Web application implementations.

In the next article in this series we'll take a detailed look at the first two items in the Top Ten List -- unvalidated input and broken access control.