The Most Dangerous Programming Mistakes

snydeq writes "Fatal Exception's Neil McAllister discusses the most dangerous programming mistakes, and what can be done to avoid them. 'Even more than input validation errors, this year's list is rife with application security blunders of all kinds. Some of them sound fairly esoteric, such as "inclusion of functionality from untrusted control sphere." But of all such errors, the highest-ranking one on the list is "missing authentication for critical function" — in other words, the attacker was able to gain access because there was no lock on the door to begin with,' McAllister writes. 'With the pace of Internet attacks accelerating, now is not the time to cut QA staff or skimp on testing and code review.'"

Comments

Better link

[Chris Mattern]

If you'd like to read what the mistakes *are*, instead of a fluff piece that amounts to "oh, they're so awful! And people make them all the time, too!", here's the actual original article: http://cwe.mitre.org/top25/index.html

Did you try double right-click?

[tepples]

To work around Slashdot's brokenness, did you try double right-click, then open in new tab? It appears to work for me in Firefox 5.

What kind of mistakes they are

[DragonWriter]

Those are system design mistakes.

While TFS and TFA call them "programming" mistakes, the actual source refers to them as the "Top 25 Most Dangerous Software Errors".

A programming mistake is one where you meant to type x+1 and instead you write x-1.

No, that's a typographical error, not a programming mistake.

A programming mistake is when you incorrectly analyze the requirements and think you need to type x-1 to correctly implement them when in fact you need to type x+1.

But either one results in a "software error"; the list and the original source are fine, the fluff piece in between the original source and Slashdot (and, consequently, the Slashdot summary) is the only potential problem here.

If software was a car, you wouldn't say it's a manufacturing problem if the car didn't have a place to install a lock - you'd say it's a design problem. It would only be a "programming" issue if it had a place for a lock but it was left uninstalled.

While its fun to construct ways to point the finger somewhere else in an organization, or to pedantically categorize errors in to narrow boxes, what I'd say is that its a failure of each and every person who had sufficient contact with the product that they should have seen the relevant facts, and sufficient technical skill that they should have recognized the error, and who either did not recognize the error or who did recognize the error but did not take action to have it corrected [whether that was implementing a fix or providing notice up the line]. Plus all the people responsible for the process that produced the error.

And most of the errors on the list are things that, whether or not they should be explicitly foreseen in requirements, programmers are positioned to recognize and ought to be taking steps to prevent. Programming isn't narrowly constrained assembly-line work, at least in any organization that expects to produce quality software.

Re:QA - Microsoft is really to blame.

[Joce640k]

Microsoft's Visual C++ compiler will throw a huge number of warnings for things like strcpy, telling you to use strncpy_s or something like that.

You shouldn't even be using strcpy(). std::string has been around for more than ten years now.

Similarly arrays: Don't use them, use std::vector instead. Visual C++ vector even does range checking by default so this throws an exception instead of corrupting memory:

std::vector foo(10);
foo[11] = 123; // Will throw an exception in VC++...

A few basic changes in programming style can make C++ as safe as Java (but with none of the drawbacks). If you're still writing C code with your C++ compiler you're Doing It Wrong.