[WEB SECURITY] 2009 Top 25 Programming Errors
Steven M. Christey
coley at linus.mitre.org
Thu Jan 15 15:25:44 EST 2009
On Thu, 15 Jan 2009, Amichai Shulman wrote:
> Considering that this project is trying to set a standard language for
> secure coding you would expect more effort in providing formal, coherent
> and accurate descriptions for application developers as well as security
It's not trying to set a language for secure coding, just what the minimum
expectations are and which bugs to concentrate on first... and for a
broader set of software than web apps.
> Second, I think that the important issue at hand is creating a "Lingua
> Franca" between security professionals, IT operations, developers and
> business stake holders. Thus, creating a new taxonomy that is focused on
> the mitigation technique (specific coding practices) rather than the
> problem, and which is not tied into existing accepted de-facto standards
> (OWASP 10 Ten, WASC thread classification, etc.) is not helpful.
The approach we've taken is to help developers clean up their code.
Understanding how an attack works does not tell them how to fix the
problems. This is something that SANS discovered in the past few years,
while they've been talking to many large development organizations.
For example: you can fully understand how a CSRF attack works without ever
figuring out that double-checked cookies might be an effective solution.
And the XSS Cheat Sheet is almost all about bypassing the developer's
attempted protection mechanisms.
> I also find the claim that the list is a tool for software consumers to
> evaluate the software that they are buying peculiar at best. Merely
> going to your vendor and asking whether his software is vulnerable to
> buffer overflow or not is useless, much the same as asking if all buffer
> operations are safe.
You mean that, nobody can truly guarantee that they are free of overflows?
Or are you saying that customers shouldn't care about whether their
software has overflows, and instead should prioritize other things like
whether the vendor has established practices?
> If SANS and CWE are serious in their intension to provide a standard for
> application vulnerabilities they should open this list for discussion as
> OWASP and WASC do with their projects. We will be, of course, willing to
> contribute to any such effort.
This is a very good point, and now that the initial list is out there,
I'll make it happen.
It should be noted that an open invitation was extended to the SC-L list a
month ago, and the effort was announced elsewhere, too. So we have not
been hiding it. I will admit that Robert Auger recommended announcing the
effort to this list, but I dropped the ball on that one.
> A list of our detailed comments to the document will be delivered to
> SANS / CWE shortly and will also be posted to this list for review.
I welcome any and all such critiques. We knew that there would be lots of
feedback, and the end result will be a better product - whatever form it
happens to take.
Join us on IRC: irc.freenode.net #webappsec
Have a question? Search The Web Security Mailing List Archives:
Subscribe via RSS:
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
Join WASC on LinkedIn
More information about the websecurity