In-Depth

Top Ten Web Application Weak Spots - test doc

Avoid these weak spots in your Web applications.

• By Stephen Swoyer
• 02/19/2003

To help companies secure their Web applications, the Open Web Application Security Project's (OWASP) latest report details the top 10 Web application vulnerabilities and suggests how IT can combat them.

Companies know far too little about creating secure Web applications, says Jeffrey Williams, CEO of Web application security provider Aspect Security Inc. in Columbus, Md., the report's sponsor. Williams is one of the report's authors.

“Web application security focuses on the custom code that drives Web applications,” he says. The consequences of a Web application attack can be devastating. For starters, “it could easily disrupt or disclose database contents."

The OWASP report lists these top vulnerabilities:

1. Unvalidated Parameters

Many Web applications ask users to enter information, but then the Web application doesn’t check what’s entered to make sure it isn’t malicious code designed to overload the buffer, for example. “Attackers can modify anything in the request,” says Williams. Developers should make sure that applications check all values—that a user-entered date really looks like a date, for example.

2. Broken Access Control

Access control is how you “keep one user's information away from other users' information,” says Williams. Many Web applications don’t handle access control very well, so the threat is that once someone does break in, they have free access to all information. To address that, write the access control policy written down so that everyone knows what it is, and developers can implement it. Also, “don’t use any IDs that an attacker can manipulate,” such as storing identification information in cookies or HTTP headers. An attacker can simply change the ID and the Web application might return another user’s information.

3. Broken account and session management

“Handling credentials between a client and a server is tricky business,” says Williams. Make sure to restrict what authenticated users can see. Beyond that, tread carefully, since so many tools for creating sessions—something HTTP can’t do, so Web applications must do it themselves—introduce numerous security risks.

4. Cross-site scripting (XSS) Flaws

Web applications can be turned against users. “Web browsers execute code that is sent from trusted Web sites, but what if an attacker could get a website to forward an attack?” asks Williams. One possible way to do this is by entering malicious code into an online bulletin board that gets run when a user views the board. Successful attacks can reveal user session tokens to an attacker, or just attack the user’s PC. To combat it, validate as much as possible, and filter script output to remove potential problem characters.

5. Buffer Overflows

In some Web application components, returning a string longer than the Web application can handle can overwrite the stack and, in some cases, take over the process. Vulnerable components include CGI, some libraries, drivers, and Web application server components. To combat overflows, choose a programming language not subject to this type of error, and test all library components used thoroughly, says Williams. “C or C++ might not be the best language for this.”

6. Command Injection Flaws

“An attacker can create a malicious SQL query and then send it in like a normal request,” Williams observes, and the Web application may attempt to execute it. “The key point here is, use extreme care when invoking an interpreter.” It's better to use an interpreter-free native library, such as the JDBC (Java database connectivity) library in Java, because it’s harder to inject data into it. Also make sure developers validate return values, as noted above.

7. Error Handling Problems

“Errors occur in Web applications all the time,” says Williams. Unfortunately, the error messages often contain a wealth of information for someone who wants to attack the site. In some cases when a Web application can’t handle the error, it will crash or return explicit information. For instance, Microsoft will provide ODBC error messages back to users. To combat this type of attack, Williams recommends you provide only vague error messages.

8. Insecure Use of Cryptography

“Many Web applications use cryptography of some fashion to store sensitive information. The tricky part isn't the algorithms— they tend to be simple. The tricky part is building applications around them,” Williams says. Frequently, “it's the storing of keys, certificates and passwords that turns out to be the Achilles heel.” Given the difficulty of working with cryptography, take a step back and rethink what’s being stored in the first place. For example, maybe never store passwords. “It's possible to never store the real password. Use a hash like SHA-1.” If a user forgets their password, then instead of looking the old one up, send an e-mail to their address on file that they must use to create an entirely new password.

9. Remote Administration Flaws>

Remote administration tools are, of course, extremely powerful. Unfortunately, “a lot of organizations may not even know that their Web site can be administered remotely,” notes Williams. Default settings may leave backdoors in Web applications that a knowledgeable attacker could exploit. “Key points here are that if possible, you should eliminate administration over the Internet.” Instead, enable access, if needed, via another network—perhaps internal—or at least use strong authentication, and possible a VPN, for administrators.

10. Web and Application Server Mis-configurations

Code Red and Slammer were two recent attacks that affected Web servers, preventable with proper server configuration. The basics of configuration still apply: remove default passwords, unused libraries, default SSL settings, default certificates, and verbose error messages. Look to free scanning tools to double-check that servers have all the latest patches. Also, take notes. “It's very important to write down the way your servers are configured so the next administrator who comes along will know how to configure it properly,” says Williams.

Remembering the Basics

While this top 10 list will help Web application developers create secure applications, don’t forget the basics, Williams advises. “Make sure your developers are trained on Web application security. It's not that they're bad developers, it's just that Web application security is difficult.” Williams notes that far too few companies actually train their developers on security. One training tool is Web Goat, available free from the OWASP site, which is a complete Web application purposefully impregnated with flaws. Also “get expert code review and penetration testing periodically."

Many developers create Web applications that only rely on existing perimeter security. “Web applications typically don't do any security checks, and if they do, the results aren't logged,” Williams says. Yet Web applications break in ways that other applications don’t. Treat them as part of the network perimeter.

Finally, Williams points out that part of the blame for poor Web application security lies with educators. “Educators, please don't teach insecure coding. I've seen educators say, don't bother validating input, because this is just a little exercise.” Instead, security has to always be thought of as part of the equation.

The OWASP report can be found at www.owasp.org/.