Thursday, January 15, 2009

25 most dangerous programming errors

I found this recent article on the top 25 programming errors linked from Lambda the Ultimate. From the article:

...experts from more than 30 US and international cyber security organizations jointly released the consensus list of the 25 most dangerous programming errors that lead to security bugs and that enable
cyber espionage and cyber crime. Shockingly, most of these errors are not well understood by programmers; their avoidance is not widely taught by computer science programs; and their presence is frequently not tested by organizations developing software for sale... Just two of them led to more than 1.5 million web site security breaches during 2008 - and those breaches cascaded onto the computers of people who visited those web sites, turning their computers into zombies.

The sensationalist tone of the article may be appropriate for discussing the very real and scary subject of how programming errors affect everyone in the world. People know how to fix these things, but consumers of software seem blissfully ignorant/tolerant of unnecessarily buggy software.

Listed errors include cross-site scripting, cleartext transmission of sensitive information, race conditions, and other classic errors. There are also things like "improper initialization" and "incorrect calculation." (The descriptions can be amusing: "Just as you should start your day with a healthy breakfast, proper initialization helps ensure...")


Jesse A. Tov said...

This is sensationalist and dumb.

First, we have four errors that are essentially the same thing:

* Failure to Preserve SQL Query Structure (aka 'SQL Injection')
* Failure to Preserve Web Page Structure (aka 'Cross-site Scripting')
* Failure to Preserve OS Command Structure (aka 'OS Command Injection')
* Improper Encoding or Escaping of Output

Actually, the first three are all instances of the fourth, with a little "Improper Input Validation" thrown in for good measure. (These are all easy for moderately expressive type systems to prevent. You can do it in Java!)

I'll admit that "Race Condition" is a hard problem. But it's not fair to say that it's not well understood, and any CS department not teaching about this to its undergraduates is simply not doing it's job. This is nothing new.

Some of these shouldn't even be issues. "Failure to Constrain Operations within the Bounds of a Memory Buffer" — sane languages don't suffer this problem. Likewise, "Improper Initialization" and "Improper Resource Shutdown or Release" are easily avoided much of the time in safe languages. Don't write mission-critical software in C++, stupid.

Some more overlaps: "Client-Side Enforcement of Server-Side Security" is an instance of "External Control of Critical State Data," as may be "External Control of File Name or Path". I'll admit this one doesn't have a language solution, but it shouldn't be too hard to grasp. We taught it to our freshmen, when we had them construct a peer-to-peer hangman game. Who gets to control the secret?

And finally, "Hard-Coded Password"? If you're having trouble with minimal competency, how can you expect people to get the difficult things right?

Jean said...

Sensationalist, yes, but not dumb.

What the article reveals is that while people have developed good tools for not doing most of these things, the current practice is that software in the wild still ships with stupid, silly mistakes that can cause a lot of problems. What's more is that consumers are fine with this.

The stupidity of some of these "dangerous errors" shows that something needs to change with the way people produce and consume software.

Jesse A. Tov said...

I'm not sure that's true. Most software in unreliable because it costs more to produce reliable software, and people don't think it's worth paying for a reliable word processor. The U.S. military, on the other hand, does think it's worth it, they're willing to pay for it, and their track record (afaik) is pretty good.

Most people do their jobs carelessly, and I don't know why we'd expect software engineering to be any different. Publishing a list of careless mistakes is not how you get people to stop being careless. Making it impossible for carelessness to result in certain situations may be a better answer, but of course no one wants to do that.

Anonymous said...

>> "Improper Initialization" and "Improper Resource Shutdown or Release" are easily avoided much of the time in safe languages. Don't write mission-critical software in C++, stupid.

Are you shitting me? What should I write it in-- Cobol? You haven't had much contact with the real world of industrial software dev, have you?

Jesse A. Tov said...

Dear Anonymous,

No, I'm not shitting you, and yes, I have worked as a software developer, though currently I do not. I do still write software every day.

Frankly, your comment is bizarre. I can't figure out what class of people you suppose I might belong to that would recommend COBOL as the solution to, well, any problem at all. Certainly many people have no choice but to use COBOL for legacy projects, and I thank them for their service. Otherwise, there are plenty of modern languages that aren't as insane as C++ nor as braindead as COBOL.

xcod4r said...

Define function to multiply two int
c samples for beginner programmers