CWE/SANS TOP 25 Most Dangerous Programming Errors

This article is making the rounds on the intarwebs.

"There appears to be broad agreement on the programming errors," says SANS Director, Mason Brown, "Now it is time to fix them. First we need to make sure every programmer knows how to write code that is free of the Top 25 errors, and then we need to make sure every programming team has processes in place to find, fix, or avoid these problems and has the tools needed to verify their code is as free of these errors as automated tools can verify."

Weird phrasing all over

The article has a long, impressive list of contributors, but some of the descriptions sound quite odd: e.g.

Computers have a strange habit of doing what you say, not what you mean. Insufficient output encoding is the often-ignored sibling to poor input validation, but it is at the root of most injection-based attacks, which are all the rage these days.

I feel like a high school student, listening to a comp-sec consultant on career day.

By Koray Can at Thu, 2009-01-15 01:59 | login or register to post comments

I think they're referring to something like [ http://www.isoc.org/isoc/conferences/ndss/09/program.shtml#security1 ] : one linguistic perspective on cross-site scripting susceptibility is horrible marshalling formats and language support. I disagree with the solution, but it shows a nice perspective to take.

By lmeyerov at Thu, 2009-01-15 03:47 | login or register to post comments

Ah, I thought they were cute

Ah, I thought they were cute. I really enjoyed reading these pearls:

CWE-119: Buffer overflows are Mother Nature's little reminder of that law of physics that says: if you try to put more stuff into a container than it can hold, you're going to make a mess.

CWE-665: Just as you should start your day with a healthy breakfast, proper initialization helps to ensure that your software will run without fainting in the middle of an important event.

CWE-94: While it's tough to deny the sexiness of dynamically-generated code, attackers find it equally appealing.

By dmbarbour at Thu, 2009-01-15 09:53 | login or register to post comments

Relevant reading.

By Ehud Lamm at Sat, 2009-01-17 06:27 | login or register to post comments

well said

so what do people feel are the best languages if one wants to take a "do it right in the first place" approach? SPARKAda? Haskell? Coq?

of course "it depends" on a lot of things, so i would first focus on the 50% of bugs that aren't design issues but are code issues, i guess. e.g. buffer overruns and the like, rather than SQL injection.

but then it does lead one to wonder how to tackle the other 50%, the design bugs such as allowing SQL injections.

By raould at Wed, 2009-01-21 22:18 | login or register to post comments

How are buffer overflows and

How are buffer overflows and sql injection substantively different, pushing one to (logical) 'code' and the other (language/software API) 'design'? Design solutions to buffer overflows are more popular than code ones (e.g., safe languages over fuzzing).

By lmeyerov at Thu, 2009-01-22 07:12 | login or register to post comments

good question

i think it all depends on context. in some sense, a buffer overrun is because the programming language used doesn't support range checks automatically e.g. C vs. Java, whereas SQL injection isn't going to be so easily prevented by picking a different language (at least at the C vs. Java level -- there might be ways to do it with good types in a real language, of course, in which case i agree with what you are saying).

By raould at Fri, 2009-01-23 20:35 | login or register to post comments

Lambda the Ultimate

User login

Navigation