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

Re:Better link

[frinkster]

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

Is one of the mistakes "Not being able to click on a link"? I would check myself, but I can't click on the link.

Headline reveals slashdot philosophy?

[damn_registrars]

it's-probably-fine,-we'll-test-it-live

Could describe every "upgrade" to slashdot that has happened since ... well probably ever.

Re:Those aren't "programming" mistakes...

[Short Circuit]

You seem to be advocating a distinction of responsibility of knowledge where programmers should not need knowledge of design. I would dispute that.

First, all you've done is replace "programmer" with "compiler." If you posit that there is no need for programmers to do anything more than convert a design specification to code, then all you've done is define programmers as transcoders operating on a higher-level formal langauge than current compilers already do. That seems ridiculous; you'd be able to replace "programmers" with "compilers" for this higher-level language ("Technical writing in English") your design spec is written in. At that point, your designers are doing nothing more than programming in a higher-level language...making them programmers again. Look at the trends in new and redeveloped languages to include declarative behaviors for evidence of this already happening; dataflow-driven and declaration-driven language features are getting a lot of attention.

Second, if your programmers aren't expected to have or build knowledge of good design and design practices, then they won't be able to identify mistakes--especially critical mistakes such as the ones discussed in TFA. People are people, people make mistakes. Without other people or tools (created by people) there to catch some the mistakes, more of the mistakes slip past. And while it's perhaps easy to build a unit test suite from a design document, that unit test suite is going to be better at detecting flaws in the code, not in the design.