The 25 Most Dangerous Programming Errors

Hugh Pickens writes "The Register reports that experts from some 30 organizations worldwide have compiled 2010's list of the 25 most dangerous programming errors along with a novel way to prevent them: by drafting contracts that hold developers responsible when bugs creep into applications. The 25 flaws are the cause of almost every major cyber attack in recent history, including the ones that recently struck Google and 33 other large companies, as well as breaches suffered by military systems and millions of small business and home users. The top 25 entries are prioritized using inputs from over 20 different organizations, who evaluated each weakness based on prevalence and importance. Interestingly enough the classic buffer overflow ranked 3rd in the list while Cross-site Scripting and SQL Injection are considered the 1-2 punch of security weaknesses in 2010. Security experts say business customers have the means to foster safer products by demanding that vendors follow common-sense safety measures such as verifying that all team members successfully clear a background investigation and be trained in secure programming techniques. 'As a customer, you have the power to influence vendors to provide more secure products by letting them know that security is important to you,' the introduction to the list states and includes a draft contract with the terms customers should request to enable buyers of custom software to make code writers responsible for checking the code and for fixing security flaws before software is delivered."

Comments

Yeah, right.

[Anonymous Coward]

I'll sign such a contract, but the project will take twice as long and my hourly rate will go up 300%.

People like to draw the comparison with civil engineering, where an engineer may be liable (even criminally) if, say, a bridge collapsed. But this isn't really the same thing. We're not talking about software that simply fails and causes damage. We're talking about software that fails when people deliberately attack it. This would be like holding a civil engineer responsible when a terrorist blows up a bridge -- he should have planned for a bomb being placed in just such-and-such location and made the bridge more resistant to attack.

The fault lies with two parties -- those who wrote the insecure code, and those who are attacking it. I'll start taking responsibility for my own software failures when the justice system starts tracking down these criminals and prosecuting them. Until then, I'll be damned if you're going to lay all the blame on me.

Re:Yeah, right.

[timmarhy]

Not only will it take twice as long and cost 3 times as much, but i'd also reserve the right to deny the customer any features i deemed unsafe.

I could lock down any system and make 100% hacker proof - i'd unplug their server.

it's a ratio of risk to reward like most things, if you want zero risk there won't be any reward.

Re:Yeah, right.

[rolfwind]

People like to draw the comparison with civil engineering, where an engineer may be liable (even criminally) if, say, a bridge collapsed. But this isn't really the same thing. We're not talking about software that simply fails and causes damage. We're talking about software that fails when people deliberately attack it. This would be like holding a civil engineer responsible when a terrorist blows up a bridge -- he should have planned for a bomb being placed in just such-and-such location and made the bridge more resistant to attack.

Not only that, but civil/mechanical/other engineers usually know exactly what they are dealing with - a Civil engineer may specify the type of concrete used, car engineer may specify the alloy of steel.

Most of the time, software engineers don't have that luxury. Video Game consoles (and still are, mostly) used to be nice that way and it was the reason they had fewer problems than PCs.

Tell a bridge engineer that he has no absolutely control over the hardware he has to work with and that it may have a billion variations, and see if he signs his name to it.

Re:Yeah, right.

[timmarhy]

nope wrong. the car has doors and locks, but their are criminals out there that are skilled enough to pick the locks. how far should you raise the complexity of the hack before your off the hook?

Re:Yeah, right.

[pclminion]

It's laughable to equate an outright lack of security (lock-less doors) with subtle programming errors which result in security holes. It's not like a door with no locks. It's like a door with a lock which can be opened by some method that the designer of the lock did not envision. Does it mean the lock designer did a poor job? That depends on the complexity of the hack itself.

Software is designed by humans. It won't be perfect. Unfortunately, software is targeted by miscreants because of its wide deployment, homogeneity, and relative invisibility, which are concepts that are still quite new to human society. I'd be willing to take responsibility for security failures in my products, but I'm sure as hell not going to do so when I'm subjected to your every idiotic whim as a client, nor will I do so at your currently pathetic pay rates. If you want me to take the fall for security failures, then I reserve the right not to incorporate inherently unsecure technologies into my solutions. In fact, I reserve the right to veto just about any god damned thing you can come up with. After all, I'm a security expert, and that's why you hired me, right? And I'm going to charge you $350 an hour. Don't like it? Go find somebody dumber than me to employ.

Re:Yeah, right.

[fuzzyfuzzyfungus]

Worse, in addition to being management blame-storming(and hardly novel, at that). It is quite arguably a member of a very old and inglorious school of argument, the one that asserts that people are fully rational agents, who will perform properly if suitably threatened. Sure, Mr. "Eh, I'd rather masturbate and play Halo than check for bugs in the software I was paid to write" could probably do with a kick in the ass; but the main threat is simple honest mistakes, which humans make with some frequency, depending on their constitution and surrounding conditions.

Anybody who honestly thinks that scary looking contracts are going to keep the engineers in line should read up on the sorts of things that happen in workplaces with real hazards: heavy machinery, toxic materials(and not the chickenshit "recognized by the state of california to cause reproductive harm" type, the "Schedule 2, Part A, per CWC" type), molten metal, exposed high voltages, and the like. Even when their lives are on the line, when the potential for imminent gruesome death is visible to even the least imaginative, people fuck up from time to time. They slip, they make the wrong motion, they get momentarily confused, some instinct that was real useful back when lions were the primary occupational hazard kicks in and the adrenalin shuts down their frontal lobe. Happens all the time, even in countries with some degree of industrial hygiene regulation.

Re:Yeah, right.

[cgenman]

Let's see. The top programming errors are:
Let people inject code into your website through cross site scripting.
Let people inject code into your database by improperly sanitizing your inputs.
Let people run code by not checking buffer sizes.
Granting more access than necessary.
Granting access through unreliable methods.

Geez, #7 is fricking directory traversal. DIRECTORY TRAVERSAL. In 2010! It's not like your drawbridge is getting nuked by terrorists here. Generally bridges are built to withstand certain calamaties, like small bombs, fires, hurricanes, earthquakes, etc. Being successfully assaulted through a directory traversal attack is like someone breaking into the drawbridge control room because you didn't install locks on the doors and left it open in the middle of the night. Why not leave out cookies and milk for the terrorists with a nice note saying "please don't kill us all [smiley face]" and consider that valid security for a major public-facing application.

Further down the list: Failing to encrypt sensitive data. Array index validation. Open redirects. Etc, etc, etc. These aren't super sophisticated attacks and preventative measures we're talking about here. Letting people upload and run PHP scripts! If you fall for THAT one, that's like a bridge that falls because some drunk highschooler hits it with a broken beer bottle. Forget contractual financial reprisals. If your code falls for that, the biggest reprisal should be an overwhelming sense of shame at the absolute swill that you've stunk out.

And yes, security takes longer than doing it improperly. It always does, and that has to be taken seriously. And it is still cheaper than cleaning up the costs of exposing your customer's banking information to hackers, or your research to competitors in China. Stop whining, man up, and take your shit seriously.

Re:Yeah, right.

[digitalchinky]

How many clients have you ever met that actually ~know~ what they want? :-)

Re:Yeah, right.

[ScrewMaster]

y drafting contracts that hold developers responsible when bugs creep into applications.

Arguably the stupidest thing I've ever heard, and I'm old enough to have heard a lot of stupid shit.

Anybody who honestly thinks that scary looking contracts are going to keep the engineers in line

Is a moron who would have been a candidate for early-term abortion if we could only predict such things. The reality here is this: if you try to put engineers (especially software engineers) into a situation where every line of code they produce might put them in court, you're going to find yourself with a severe shortage of engineers. There are many things that creative minds can do, and if you make a particular line of work too personally dangerous nobody will enter that field.

More to the point however, only completely drain-bamaged organizations actually ship alpha code, which is obviously what we are talking about in this case. Because if we're not, if we're discussing production code that was overseen by competent management, conceived by competent designers, coded by competent software engineers and tested by competent QC engineers (you do have those, don't you?) then blaming the programmer alone is absolutely batshit insane, and will serve no legitimate purpose whatsoever.

Modern software development, much like the production of a motion picture, is a complex team effort, and singling out one sub-group of such an organization for punishment when failures occur (as it happens, the ones least responsible for such failures in shipping code) is just this side of brain-dead.

And I mean that about the programmers being the least responsible. Unless management has no functioning cerebral cortex material, they will understand and plan for bugs. You expect them, and you deal with them as part of your quality control process. Major failures can most frequently be attributed to a defective design and design review process: that sort of high-level work that happens long before a single developer writes one line of code. The reason that engineers who build bridges are not put in jail when a bridge fails and kills someone is because there are layers and layers and layers of review and error-checking that goes on before a design is approved for construction. It's no different in a well-run software team.

If your team is not well run, you have a management failure, not a programmer problem.

I had stupid people, I really do. And people that propose to punish programmers for bugs are fundamentally stupid.

Re:Yeah, right.

[mabhatter654]

Except what really happens is that American coders won't sign the documents. That's where Indian and Chinese agencies will sign "whatever", cash the check, and farm it out to low paid code monkeys. Legally, they're not in the USA so your contract is Worthless.

Re:Yeah, right.

[Have Brain Will Rent]

Software is designed by humans. It won't be perfect.

There is a big difference between "not perfect" and "damn sloppy" and buffer overflows fall into the latter category. For decades we've been teaching students to make sure a buffer has enough space for a chunk of data before writing the data to the buffer. Any so-called programmer who does this is lazy or stupid, or both, and doesn't deserve the title of programmer or a job trying to do what real programmers do for a living. Good gravy, the quality of most software I encounter (and by that I mean software that I use) is so poor it's amazing! I find myself thinking with discouraging frequency "didn't anybody at Widget Co. even try this software out before shipping?"

Re:Yeah, right.

[Anonymous Coward]

"Guess what, princess: coding is a hell of a lot easier to do, is simpler to test, and has less inherent risk than any other kind of engineering."

False, false, and true, in that order. The non-inherent risk can be pretty high though, but this is also true of other types of engineering.

"You can't put out a patch to fix a collapsed bridge" ...do you understand that the word "patch" did not originate in programming? I think the closest analogue to a collapsed bridge is unrecoverable data loss (or possibly hardware failure, which is rarely software-induced, at least on the desktop).

"or release a service pack for a unbalanced rotor shaft that destroys a generator" ...do you know what you're talking about? You also can't reinforce a bad password-negotiation algorithm with tempered steel, but that doesn't mean ANYTHING.

"You can't do destructive testing on a completed project in the real world."

Sure you can. The computer equivalent would be doing it on a live system. Stupid, in either case.

"You can't tell a client that it's going to take twice as long and he's going to have to pay you three times as much for you to do it properly."

Up until this point I could see where you were coming from, but this is divorced from reality. Cost and schedule overruns are not disproportionately present in the computer field, and anyway the GP didn't seem to be talking about overruns, he was talking about what it costs compared to the jackass who wants to use crazy glue and popsicle sticks to build his bridge. Where some of what you said before was ignorant or hyperbole, this is just a stupid statement. I realize you're trying to turn the GP's words on him, but you failed.

"You might have a program that takes two numbers and adds them together and spits out the answer. I type in a number and a letter, your program crashes because you're retarded and didn't sanitise the inputs. My bridge doesn't fall down because a bus drives over it instead of a car."

Do you realize that you just made an argument that building a bride that can support a bus is easier than input-validation? It isn't, of course. I can imagine extremely stupid ways to make a bad bridge.

"The programming errors identified are repeated, endemic errors. The attack vectors are the same every time. You have the tools to check and protect your code. Your software still breaks. That's why everyone's pissed at you. You have a mindset that any errors in the program will be trivial to correct, so you don't do it properly the first time."

True, false, inherently imperfect tools, true, true, strawman, misdirected anger.

"Your'e paid to produce software that performs a given function, not software that might work under some circumstances. Harden the fuck up, and do your job properly."

Not two paragraphs ago you argued that he should be paid the going rate for software that might work under some circumstances.

Re:Yeah, right.

[Sique]

It's fine to say "don't trust user input", but it's pretty much impossible to actually make sure that you've accounted for all possible ways it can be faulty, and this becomes harder the more powerful the program is, since using that power requires more complex input.

It is nearly impossible if you want to enumerate all possible ways input can be wrong. Thus you should just enumerate all ways input is right. If you expecting for instance numerical input, don't look for ";" or ")" or anything that could have been inserted maliciously. Just throw everything away that doesn't fit [0-9]*.
You know the input your program can work with. So instead of trying to formulate rules how input may differ from the input you want to catch errors, write down the rules the input has to follow and reject everything else. This is straightforward.

Re:Yeah, right.

[fuzzyfuzzyfungus]

The problem is not accountability, accountability is perfectly fine. The problem is incorrect application of accountability, and overbroad belief in its effectiveness.

For "accountability" to be properly applied, it must always be connected to power. The relationship goes both ways. Nobody with power should ever lack accountability, lest their power degenerate into mere tyranny, and nobody with accountability should ever lack power, lest they merely be made the scapegoat. This is the real problem with the false "accountability" commonly found in organizational contexts:

If, for example, you have a "release engineer" who must sign off on a software product, or a team of mechanics that must get a 747 ready for passenger flight, those people must have the power to halt the release, or the flight, if they believe that there is a problem. If they do no have this power, they aren't actually "accountable" they are merely scapegoats, and the one who does have this power is truly accountable; but is dodging accountability by assigning it to subordinates. The trouble is, in real world situations, being the person proximately responsible for expensive delays is, at best, thankless. Unless the organization as a whole is invested in the importance of that role, the person filling it will be seen as an obstruction. Obstructions have a way of being circumvented. Assigning blame under those circumstances is actually the opposite of accountability; because punishing the person who didn't make the decision will mean letting the person who did off the hook(in the same way that falsely convicting the innocent isn't "tough on crime" because it implies releasing the guilty). The second issue is the belief that being made accountable will make humans behave fully responsibly. This isn't the abusive mess that the first issue is; but it is contrafactual and tends to distract attention away from the more valuable task of building systems that are (at least somewhat) resistant to human error. Even when accountability is correctly apportioned to power, humans are imperfect instruments. If you want to build systems of complexity unprecedented in human evolutionary history, you will have to learn to build systems that are tolerant of some amount of error. Checklists, automated interlocks, automated fuzz testing, etc, etc. must all be employed; because, ultimately, "accountability" and punishment, while they have their virtues, cannot remediate failure. Executing murderers doesn't resurrect their victims. Suing programmers doesn't recover data stolen in some hack attack. There isn't anything wrong with punishing the guilty; but its utility in accomplishing people's actual objectives is surprisingly tepid. People don't want to sue programmers, they want high-quality software. People don't want to fire mechanics, they want planes that don't crash. People don't want to incarcerate criminals, they want to be free of crime. "Accountability" is one tool that can be used to build the systems that people actually want(and there are arguments to be made that it is ethically obligatory in any case); but single minded focus on it will not achieve the ultimate objectives that people are actually seeking.

Bad Idea

[nmb3000]

a novel way to prevent them: by drafting contracts that hold developers responsible when bugs creep into applications

Holding a gun to somebody's head won't make them a better developer.

I don't understand why well-known and tested techniques can't be used to catch these bugs. There are many ways to help ensure code quality stays high, from good automated and manual testing to full-on code reviews. The problem is that most companies aren't willing to spend the money on them and most open source projects don't have the manpower to dedicate to testing and review.

TFA seems like it's just looking for somebody to blame when the axe falls. If your method of preventing bugs is to fire everybody that makes a programming mistake pretty soon you won't have any developers left.

re:zero risk

[Tumbleweed]

"Insisting on absolute safety is for people who don't have the balls to live in the real world."
- Mary Shafer, NASA Dryden Flight Research Center