Top 25 Most Dangerous Programming Mistakes

I don't usually do news and current events here, but I'm making an exception for the CWE/SANS Top 25 Most Dangerous Programming Errors list. This one is important, and deserves a wide audience, so I'm repeating it here -- along with a brief hand-edited summary of each error.


This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2009/01/top-25-most-dangerous-programming-mistakes.html

A good reference for data validation guidelines a href=http://www.owasp.org/index.php/Testing_for_Data_Validationhttp://www.owasp.org/index.php/Testing_for_Data_Validation/a

absolutely hilarious - from the mitre.com web site The list is the result of collaboration between the SANS Institute, MITRE, and many top software security experts in the US and Europe.

So I’m wondering how many highly expensive top software security expert man-hours were invested in this trivial list of obvious errors.

They could have just asked on stackoverflow.com and gotten the same or a better list in a few minutes.

the amazing thing here is not the list, the list is self-evident and nominally trivial; the amazing thing is that people are reacting to this list like it is some kind of stunning revelation from the gods!

A really good resource is The Open Web Application Security Project

http://www.owasp.org/index.php/Main_Page

the amazing thing here is not the list, the list is self-evident and nominally trivial; the amazing thing is that people are reacting to this list like it is some kind of stunning revelation from the gods!

Simple explanation:

Content … hmmm…
Audience size … hmmm…
Audience type … HMMM… (+me)
Match!!!
Post!

Nothing very wrong, given the already populous knowledge bank of how to be a better programmer articles. Hey, I have my own 30 points on the internets elsewhere, but they make most sense for someone like me, but maybe not you. Maybe you could post links to articles around the web describing similar errors in well-known web or dekstop apps so that the thread becomes a bit more useful.
Like this: 15 – http://en.wikipedia.org/wiki/Md5sum
dekstop. nit.pick();

@Serge: they can, and often do. An improperly checked return value, which almost made it onto the top 25, is behind the most recent OpenSSL vulnerability that let attackers spoof certificates. A recent Linux kernel issue involved a wrong variable in a function call. If you use a regular expression with improper anchoring, maybe you’ll find that you’re checking if your input contains at least one digit, instead of only digits. If you really want to dig deep into the inter-relationships between regular bugs and vulnerabilities, take a look at CWE’s chains and composites.

@Kinesh: (1) is a goal of ours. (2) is a concern, but this will likely evolve into best-practice claims by the vendor like we ran security-tool X against this code, and we’re clean - which is more actionable than the nothing we have today.

@silvercode: now that customers can ask what do you do about the Top 25, if it begins to affect the bottom line, your non-PHB managers will have to figure out how to make budget and training available.

@hribek: this list isn’t one man said it. It’s a bunch of gov’t organizations, software developers, security vendors, and academics said it.

@Mark: only two items are really web-only. Other items show up all the time in web, but they apply to other classes of software, too.

@Atwood: new fanboy here. can’t believe I only found your site last week while digging up more info on HttpOnly. Check out CWE-445, CWE-355, and CWE-655, you’ll dig 'em. Naturally, nobody pays attention to those CWEs or their children (they’re also in a messier corner of the CWE, apologies ahead of time).

Steve Christey
The MITRE Corporation
Top 25 document editor

I like the list, but two things spring to mind right away:

  1. These aren’t mistakes!! For instance, failure to check input to make sure it doesn’t contain SQL injections ISN’T a mistake. In a world without hackers, this code would work perfectly well. In the context of programming, the program is working without mistake.

Don’t get me wrong, I agree that this loop-hole that should be addressed, but rather than considering it a mistake of the programmer, consider it part of the securing of the application and therefore the responsibility of the project lead(s)/software designer(s). That is, injection blocking code can be implemented in a custom control (which extends the base controls), and therefore the programmer never needs to worry about it. It would be a mistake to use an insecure control - but that’s the end of the programmer’s responsibility.

  1. This list is almost entirely web based or client facing software. Internal software (such as the ERP I manage) has easier security to manage because you know the specific users connecting, and you know exactly what they should have permission to and what they shouldn’t. I’m not saying that the program’s aren’t open to these types of attacks, but their logins and activity are tracked down to the user - so the person would be fired.

I think #1 and #2 are the biggest problems I face in web development. People just don’t get that some idiot will put his address in the ‘phone’ field and totally shatter the back-end if you don’t validate it.

Great list Jeff.

Whoa, speaking of coding horrors! Very McConnell-ish list; i.e., excellent and required reading. Top marks, and thanks.

I deeply hate valueless comments like use Linux OSs for safety. Linux is no silver bullet of the security. Usually has a larger attack surface than Windows Server.

Fine list. The first item is very important, but the implementation all too often leads to usability problems with unnecessary harsh demands on input formatting. I’d like to suggest splitting it in two:

1 a: Allow all user input that can be interpreted unambiguously.
1 b: Never trust input from the client.

Ideally a system accepts today as a date input (Outlook does this) and at the same time implements vigorous validation on the server side.

The list seems to boil down to :

Check what you are given - don’t assume it is valid/clean/good

Program correctly : Initialise/deallocate memory correctly
Use Really random numbers
Use descent encryption
Use a real security system

Security is based on least access : don’t give anyone/anything more access/information that it needs

I think that covers all 25 points …

Jeff, you are missing an end blockquote on #15 :wink: good read.

Since my career change into programming three years ago, at age 28, I notice a whole lot of some idiot phrases, almost on the middle-school heights of usage. I wonder if you would comment on programmer egotism.

Hey Now Jeff,

What a great post. I’m bout to read it again.

Coding Horror Fan,
Catto

What, no pics? I thought someone had hacked your url and redirected to some other person’s blog.

26.) Improper nesting of HTML-Lists

Oddly enough, I don’t see the word security in your introduction. However, the 25 listed items are ALL related to security. Does it mean that dangerous programming mistakes boils down security holes?

If you work on software in any capacity

I guess you mean website software. I work on a hell of a lot of software and very little of it has any relation to this stuff :slight_smile:

However, I am always dealing out bitchslaps to our web guys about these exact things. Emailed!

Now this is what Coding Horror is all about! (at least on the surface anyways)

Thank you Jeff. :slight_smile:

Cheers