The OWASP top ten web application vulnerabilities [LWN.net]

The Open Web Application Security Project has issued a new version of its top-ten list of web application security vulnerabilities; the full version is available from the SourceForge download network in PDF format. The list is little changed from last year - web sites are still being attacked using the same sorts of vulnerabilities. This year's list is:

Unvalidated input, usually in the form of playing with HTTP requests. Many of the other problems on this list come down to input validation problems in the end.
Broken access control mechanisms. Access control is often an oversight, and often implemented poorly.
Broken authentication and session management. Among other things, the study points out that identifiers like session cookies must be protected by SSL or session hijacking is possible.
Cross-site scripting. ("The likelihood that a site contains XSS vulnerabilities is extremely high").
Buffer overflows. Web applications are certainly not unique in suffering from this class of vulnerabilities, of course. The paper singles out Java-based web applications as being immune to buffer overflow attacks.
Injection flaws with SQL injection topping the list.
Improper error handling which discloses internal information.
Insecure storage; being the failure to use (good) encryption when storing important information.
Denial of service, in all the usual ways.
Bad configuration management, such as the failure to apply security updates and poor system administration in general.

This is a daunting list for anybody trying to deploy any sort of web application in a secure manner. There are so many things which can go wrong. The risks of running a web application can be managed, however. The first step toward that end is developing an awareness of where the pitfalls lie; OWASP, in compiling its list, has helped us to take a step in that direction.

(Log in to post comments)

The OWASP top ten web application vulnerabilities

Posted Feb 5, 2004 21:39 UTC (Thu) by slamb (guest, #1070) [Link]

#4 (cross-site scripting) is really a subclass of #6 (injection attacks). Cross-site scripting attacks are possible because of improperly escaped HTML. They just have a different payload (commands to the browser rather than commands to the SQL server or shell).

I'm convinced that injection attacks (including cross-site scripting) can be solved through new coding patterns, rather than reduced through extreme care (the current situation, mostly).

The problem essentially is that people are using patterns where they have manually generate the SQL or HTML and manually escape it. This is extremely error-prone - you can forget just once, you can expect the caller of a function to have escaped something already and then change the interface and forget to update a caller, etc. Bugs can sneak in over time. It's a horrible way of doing things.

Instead, we should be using patterns that handle things a little more for you:

bind variables for SQL (they make manual escaping unnecessary)
SAX events (they correctly escape for a variety of different contexts)
XSLT rather than home-brewed, buggy templating technologies. Again, XSLT knows a bit more about the context in which things will be used, so it can do the escaping for you.

If you'll forgive me, I want to make my usual plug for a couple pieces of (poorly-named) software I'm working on:

xmldb's Statement and Library makes SQL fragments easier to deal with in Java code. It separates them from the Java code and makes it possible to use named bind variables, which Java doesn't support natively. The goal is to make the correct way easier than the incorrect way.
framework is to SAX- based XML as JSP is to raw HTML generation. It makes it easy to create web pages with XML and pump them through XSLT. Again, it strives to make the correct way easier than the incorrect way.

There are other, similar projects out there. I've got links to them on those pages.

Likewise, #5 (buffer overflows) can be solved through using a high-level language rather than reduced through more discipline than programmers are apparently capable of, given the number of these vulnerabilities. I'm surprised buffer overflows were so high on web code - I thought most web code was written in these languages. They mention Java, but also Perl and Python are immune to this problem. Maybe it was buffer overflows in the webserver themselves that put this so high on the list, as webservers tend to be written in C.