WebApp Sec mailing list archives
Re: Top Ten Web App Sec Problems
From: "Steven M. Christey" <coley () linus mitre org>
Date: Wed, 4 Dec 2002 16:39:10 -0500 (EST)
= Steve Christey= Jeff Williams
It sounds like you're advocating a "top ten" that's based on other criteria besides "the most frequently occurring" types of issues. The basic question is, what would be the proper criteria for such a top ten list, and what would be the goals?The problem with "most frequently occurring" is that our instruments for measuring are so poor that I don't believe they represent reality.
Agreed. There is a bias in what's publicly reported, too - reflected by "fads" (why else is XSS so popular these days? oh yeah, it's really easy to find) and the amount of efforts by researchers. There are too many cases when a piece of software suffers the "death of a thousand cuts" with advisory after advisory on variants of the same issue, which often demonstrates how incomplete the original research was.
The public vulnerability databases don't list problems with individual websites (although there's at least an argument that they should).
We've had to deal with this in CVE and, in short, stay away from it. The general approach has been to record problems that require "customer action."
Companies don't release information about vulnerabilities in their sites, assuming that they even uncover them.
Maybe some bold company will do this one day, I hope... and while many in the security community will sing their praises, their stock price would probably plummet :-(
I'd like to see a top ten list that helps to crystallize the issue for government and industry.
I'd like to see something that customers can use to tell their vendors "we want you to guarantee that you won't make these mistakes." Something that the security community can use to say "this is the same old issue and vendors shouldn't be making such obvious mistakes." That's a little pie-in-the-sky, but one benefit of the SANS Top Ten was that it gave "management" a means of talking about vulnerabilities in a non-technical fashion.
Roughly how big do you think the risk from web application vulnerabilties is? Equal to the risk from "network" vulnerabilties like SANS lists? Half? Quarter?
That's a great question. In web apps, you have situations which the risk to the end user is as important (or more so) than risk to the server/provider, and the customer may have different priorities, security-wise, than the server/provider. I bet the "real" answer will change over the next few years, too. Server software seems to be getting much more robust, at least from major vendors. Major server software these days is hit by "interesting" or new problems more often than not. As server software is better protected, people may start looking at web apps more than they already do.
I think we should select the vulnerabilities that pose the greatest aggregate risk to government and industry (in terms of likelihood and impact).
Makes sense - and easier said than done :-) Here's my cut, which is probably biased by the overall set of publicly known vulnerabilities. One "pro" of this bias would be that it captures errors made by programmers of widely varying skill levels (instead of companies who hire consultants, who might be in better shape overall). This may in some sense reflect the lowest hanging fruit. - Directory traversal - XSS (for 3 reasons: it's commonplace, every single input is suspect, and educating programmers about XSS will have cascading effects) - Shell metacharacters / OS system command injection - Poor credential management (cookies, whatever) - Unprotected privileged apps (i.e. bypassing the "login" screen and directly accessing a program that should require authentication, but assumes the login screen handled it) - Parameter/form tampering - Canonicalization (since it can defeat otherwise good input validation) - SQL injection - storing sensitive files under the web root - plaintext passwords - in URLs or in data files - bad crypto - buffer overflows OK, that's 12 ;-) One thing that would be nice to see is a document that is organized around overall application functionality, versus vulnerability type. Many secure programming doc's are organized by vulnerability type instead of, say, "managing files," "protecting data," "processing incoming data," "using encryption," "performing authentication," etc. Some bug types will cross many functional areas, but this sort of organization might be more useful to programmers. - Steve
Current thread:
- RE: Top Ten Web App Sec Problems, (continued)
- RE: Top Ten Web App Sec Problems Richard M. Smith (Dec 02)
- Re: Top Ten Web App Sec Problems Kevin Spett (Dec 02)
- Re: Top Ten Web App Sec Problems Alex Lambert (Dec 02)
- Re: Top Ten Web App Sec Problems Marc Slemko (Dec 02)
- RE: Top Ten Web App Sec Problems Richard M. Smith (Dec 02)
- Re: Top Ten Web App Sec Problems Jeff Williams @ Aspect (Dec 02)
- RE: Top Ten Web App Sec Problems Craig, Scott (Dec 03)
- RE: Top Ten Web App Sec Problems Steven M. Christey (Dec 03)
- RE: Top Ten Web App Sec Problems Richard M. Smith (Dec 03)
- RE: Top Ten Web App Sec Problems b0iler _ (Dec 03)
- Re: Top Ten Web App Sec Problems Jeff Williams @ Aspect (Dec 04)
- Re: Top Ten Web App Sec Problems Steven M. Christey (Dec 04)