[WEB SECURITY] 2009 Top 25 Programming Errors

Amichai Shulman shulman at imperva.com
Thu Jan 15 14:19:28 EST 2009

Hi all,

I did not analyze every entry in the Top 25 but I do share Arian's
concerns with the Top 25 list the way it was presented by SANS and CWE. 
First and foremost, the items are presented in a language that is far
from being professional, not enough attention was given to avoid massive
redundancy and problem definition is superfluous and not concise.
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
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.
Mitigation of web application vulnerabilities can be achieved in various
methods, including various flavors of code changes. For a consumer to be
able to evaluate potential mitigation options the right taxonomy should
focus on a careful combination of the attack technique and its root
cause. In particular, if an attack against an application is successful
where the application includes 3rd party components, the security
officer couldn't care less about the root coding mistake that caused the
vulnerability but how to protect the entire application assuming that
the component is not fixed within a short period of time.
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.
Having said the above, I support any initiative that can contribute to
more secure applications by clearly defining secure coding requirements.
One good example is the WASC threat classification project we are
currently involved in. The project aims at classifying the threats
associated with web application vulnerabilities and providing
information about their root and is going through many review cycles
within the application security community. 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
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. 

Amichai Shulman
CTO, Imperva
125 Menachem Begin St.
Tel Aviv 67010

(972) 3-6840103 Office
(972) 54-5885083 Mobile
(972) 3-6840200 Fax
shulman at imperva.com

Download Scuba by Imperva
FREE Database Assessment Scanner

-----Original Message-----
From: arian.evans at gmail.com [mailto:arian.evans at gmail.com] On Behalf Of
Arian J. Evans
Sent: Wednesday, January 14, 2009 1:21 PM
To: websecurity at webappsec.org
Subject: Re: [WEB SECURITY] 2009 Top 25 Programming Errors

For those that aren't paying attention -- you understand that this is
going to become your new "standard" for appsec, correct?

For all of you ignoring this -- this is going to replace the OWASP Top
10 and WASC TC 1.0 or 2.0 etc. That is the goal/agenda of SANS & CWE.
Begin press releases, beat the marketing campaign drums.

The language in this "Top 25" is quite poor. Friends & I were laughing
out loud at how unprofessional and childish the writing is in this
document is in many places.

If you don't get involved in steering this -- this "Top 25" is the most
likely new "standard" you'll be living with.

Take a gander at the completely subjective and often inaccurate
"remediation costs". These kind of parts should be removed, or strongly
clarified and justified.

Anyway -- I think OWASP and WASC people need to get involved or you are
going to find that your RFPs for tools, training, and testing are
comprised of this SANS/MITRE Top 25. People (Software Security
Consumers) are already starting to use the "Top 25" this way, and
desperate vendors & solutions are actively steering this to try and give
them some legitimacy. SANS has no clue in this problem domain and will
take this banner and charge forward with it.

I could be wrong and this is ignored, but it doesn't look that way.
State governments are already pushing this as a "standard" and I think
it will wind up, like the OWASP Top 10, being preempted and used by
various parties as a standard and guideline regardless of the intent.

--> So we either need to improve this thing, or offer up a better list
really quickly to be used (and have voices actively championing it).

As an aside -- I thought we had matured more as an "industry". I was a
bit surprised that in 2009 the best we can do is offer up a list of
negative "Failures" described with amateur security-nerd language of
DEFCON caliber. Who was this document written for anyway? This language
is not how I communicate to business owners and IT professionals.

Not only do I love negative language and mindless hyperbole; I have
found it very useful to actually point your finger at developers while
shouting "You FAILED to code securely" to get the point across. I also
like to point my finger at business owners, while letting them know that
"You Failed to specific and require security software" and your software
shouldn't even be allowed on the Internet. They really like that.

Here we go with our new Top 25 list:

I'll quote the XSS section. This description is .... ridiculous and
inaccurate hyperbole. Seriously:

CWE-79: Failure to Prevent Web 2.0 (aka 'Cross-site Scripting')


"Cross-site scripting (XSS) is one of the most prevalent, obstinate, and
dangerous vulnerabilities in web applications. It's pretty much
inevitable when you combine the stateless nature of HTTP, the mixture of
data and script in HTML, lots of data passing between web sites, diverse
encoding schemes, and feature-rich web browsers. If you're not careful,
attackers can inject Javascript or other browser-executable content into
a web page that your application generates. Your web page is then
accessed by other users, whose browsers execute that malicious script as
if it came from you (because, after all, it *did* come from you).
Suddenly, your web site is serving code that you didn't write.
The attacker can use a variety of techniques to get the input directly
into your server, or use an unwitting victim as the middle man in a
technical version of the "why do you keep hitting yourself?" game."

If I had not found this on SANS's website I would have thought this was
a joke.

So now we know that XSS "comes from me" and is "input directly into your

I really like and have tremendous respect for the minds at Mitre,
particularly Steven ... so I am truly baffled by the low quality of this

That said -- I do not want this list driving any form of a standard a
customer will be using, so someone get on the ball and finish TC 2.0 and
start promoting it aggressively. Like...now.

Arian Evans

Anti-Gun/UN people: you should weep for
Mumbai. Your actions leave defenseless dead.

"Among the many misdeeds of the British
rule in India, history will look upon the Act depriving a whole nation
of arms, as the blackest." -- Mahatma Gandhi

On Mon, Jan 12, 2009 at 10:44 AM, Mangiarelli, Jerry
<jerry.mangiarelli at td.com> wrote:
> For those interested, here's a listing that details 25 most dangerous 
> programming errors that lead to security bugs.
> http://cwe.mitre.org/top25/pdf/2009_cwe_sans_top_25.pdf
> Best regards,
> j.
> ----------------------------------------------------------------------
> -----
> Jerry Mangiarelli, CISSP, CEH
> Technology Risk Management and Information Security TD Bank Financial 
> Group
> Bus: 519-663-1577, Mobile: 519-670-6090 jerry.mangiarelli at td.com

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

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 mailing list