Forgot your password?
typodupeerror
Programming

The 25 Most Dangerous Programming Errors 534

Posted by samzenpus
from the spilling-your-soda dept.
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."
This discussion has been archived. No new comments can be posted.

The 25 Most Dangerous Programming Errors

Comments Filter:
  • Yeah, right. (Score:5, Insightful)

    by Anonymous Coward on Wednesday February 17, 2010 @10:00PM (#31179316)

    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. (Score:5, Insightful)

      by timmarhy (659436) on Wednesday February 17, 2010 @10:09PM (#31179386)
      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:zero risk (Score:5, Insightful)

        by Tumbleweed (3706) * on Wednesday February 17, 2010 @10:35PM (#31179592)

        "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

      • by shentino (1139071)

        If simple common sense coding techniques can plug most of the avenues of attack, then any developer worth his salt SHOULD be responsible for plugging them...especially in this day and age where security holes are making headlines.

        For the bridge analogy, I'd consider a buffer overflow equivalent to missing a rivet. If you know what you're doing it shouldn't be possible. Trusting user-generated input is one of the first taboos you learn about in computer science.

        • Re:Yeah, right. (Score:5, Interesting)

          by ultranova (717540) on Thursday February 18, 2010 @02:55AM (#31181000)

          For the bridge analogy, I'd consider a buffer overflow equivalent to missing a rivet. If you know what you're doing it shouldn't be possible. Trusting user-generated input is one of the first taboos you learn about in computer science.

          I once coded a program for my own use that downloaded images from binary newsgroups, decoded them, and inserted them into a PostgreSQL database, with keywords extracted from the message. It was a nice program, handled multipart messages, and only stored each image once, using SHA1 hashes to check for dublicates - I even took the possibility of a hash collision into account and only used them as an index. No buffer overruns, no SQL injections, no nothing. Yet it crashed. So why did it crash?

          Some moron included the same image twice in a single message.

          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.

          • by secondhand_Buddah (906643) <secondhand.budda ... .com minus punct> on Thursday February 18, 2010 @03:17AM (#31181078) Homepage Journal
            so Pornorama never quite made it to the market?
          • Re:Yeah, right. (Score:5, Insightful)

            by Sique (173459) on Thursday February 18, 2010 @06:24AM (#31182148) Homepage

            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: (Score:3, Informative)

              by Deus777 (535407)
              I agree with this, but in practice I have found that it can lead to a lot of bug fixing if you don't have a complete understanding of what valid input looks like. For instance, in one project I was validating some input that should've been user names. I initially allowed for two groups of letters separated by space characters. Later I found out that some people had multi-part first names or last names that had spaces in them, so I had to account for multiple groups of letters. Later, I found out that so
          • Re:Yeah, right. (Score:4, Insightful)

            by discord5 (798235) on Thursday February 18, 2010 @06:37AM (#31182214)

            I once coded a program for my own use that downloaded images from binary newsgroups, decoded them, and inserted them into a PostgreSQL database, with keywords extracted from the message.

            So, I'm guessing you were building a porn search engine? For "research" purposes of course.

          • by YourExperiment (1081089) on Thursday February 18, 2010 @06:46AM (#31182252)

            Your ideas are intriguing to me and I wish to subscribe to your pr0n scraper.

          • Re: (Score:3, Insightful)

            by dzfoo (772245)

            Ah, the ol' Reject-Known-Bad or Sanitise-All-Input paradigm. It is indeed impossible to anticipate all the bone-headed ways in which input can be botched, maliciously or not. Thus, it is then more secure to prepare a discreet list of valid input and only accept that, rejecting anything that does not conform to what you expect. This rejection is not based on a black-list of bad input to compare against, but on a sort of white-list what you assert your program can handle.

            If you would have considered this a

    • Re: (Score:3, Insightful)

      by TapeCutter (624760) *
      Yes, damage caused by a deliberate attack is an insurance matter, not an engineering matter. Nothing can be made 100% failsafe.
    • Re: (Score:2, Insightful)

      Yep this isn't about removing vulnerabilities or improving quality - this is about making someone accountable.

      Having a countract where the developer is made liable? This is management blame-storming at it's finest.

      • Re:Yeah, right. (Score:5, Insightful)

        by fuzzyfuzzyfungus (1223518) on Wednesday February 17, 2010 @11:13PM (#31179826) Journal
        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. (Score:5, Insightful)

          by ScrewMaster (602015) * on Thursday February 18, 2010 @12:05AM (#31180158)

          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. (Score:4, Insightful)

            by Grishnakh (216268) on Thursday February 18, 2010 @12:32AM (#31180318)

            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.

            I'd be happy to do the job. However, I'll probably never actually finish it, as I'll be checking it over and over for bugs until they get tired of me refusing to release it and sign off on it and fire me, at which point I'll move on to the next sucker^Wemployer and continue to collect a paycheck.

          • Re: (Score:3, Insightful)

            by dkf (304284)

            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.

            Actually, you're going to end up paying a fortune for software in order to cover the developers' litigation insurance premiums. Most customers prefer to have cheaper software and carry the risk themselves.

          • Re:Yeah, right. (Score:4, Insightful)

            by asc99c (938635) on Thursday February 18, 2010 @09:15AM (#31183142) Homepage

            I think the main reason we have so many bugs in software is quite simply that no one really cares. Of course everyone complains about it, but when you look past the words towards the actions, you can see it more clearly.

            Everyone still buys the cheap software with tons of features. A simple bridge with a few modifications to an almost cookie cutter design costs a lot more than a very complex piece of custom business software with far more potential points of failure. And that's about right. If the bridge fails there's a good chance someone will die. If business software fails, someone might lose some money. So when you're looking at the risk of bugs in business software, paying for a lot of people to do detailed design, design reviews, code, code reviews, QA testing etc. etc. Well it just doesn't add up. The cost of getting it right is higher than the cost of dealing with the bugs.

            The reason this contract is fundamentally stupid is because a vendor following it will have to increase the contract cost by an order of magnitude. Probably some more as well to cover the risk of litigation. Then the customer will have to weigh up the costs and risks, and realise their older contract might actually be more sensible in the real world.

        • Re:Yeah, right. (Score:5, Insightful)

          by mabhatter654 (561290) on Thursday February 18, 2010 @12:54AM (#31180444)

          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: (Score:3, Insightful)

        this is about making someone accountable.

        Exactly. Why do you see that as a bad thing? Suppose instead of "contract" we say "these are the design/coding standards at this company and as an employee of this company you are required to follow them. If you don't then we will penalize you." What exactly is wrong with that?

        For the last umpteen years, in all sorts of venues social and professional, I've been seeing accountability become more and more denigrated and dismissed. "Oh let's not play the blame gam

        • Re:Yeah, right. (Score:5, Insightful)

          by fuzzyfuzzyfungus (1223518) on Thursday February 18, 2010 @09:34AM (#31183358) Journal
          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.
    • Re: (Score:2, Insightful)

      Bad analogy. It is like holding the car company responsible for making cars without doors and locks when they get stolen. True, stealing a car is a criminal activity. But designing a car that can not be secured effectively is aiding and abetting.
      • Re:Yeah, right. (Score:5, Insightful)

        by timmarhy (659436) on Wednesday February 17, 2010 @10:24PM (#31179518)
        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. (Score:5, Insightful)

        by pclminion (145572) on Wednesday February 17, 2010 @10:47PM (#31179650)

        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. (Score:4, Interesting)

          by danlip (737336) on Wednesday February 17, 2010 @11:09PM (#31179792)

          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.

          I mostly agree. My pet peeve is SQL injection attacks, because they are so frickin' easy to avoid. Any developer that leaves their code open to SQL injection attacks should be held liable (unless their employer insists they use a language that doesn't have prepared statements, in which case the company should be held liable).

          • Re: (Score:3, Interesting)

            by filterban (916724)
            SQL injection attacks are very easy to avoid, yes, if you know about them.

            In my time, I have seen several instances of SQL injection-vulnerable code, and 99% of the time it comes from junior level developers, who obviously have had no security training.

            Should the developer be liable, or the company that let them code without being trained?

        • Re:Yeah, right. (Score:5, Interesting)

          by Antique Geekmeister (740220) on Wednesday February 17, 2010 @11:18PM (#31179864)

          Unfortunately, many of these errors are _not_ subtle. Let's take Subversion as an example. It is filled with mishandling of user passwords, by storing them in plaintext in the svnserve "passwd" file or in the user's home directory. Given that it also provides password based SSH access, and stores those passwords in plaintext, it's clear that it was written by and is maintained by people who simply _do not care_ about security. Similarly, if you read the code, you will see numerous "case" statements that have no exception handling: they simply ignore cases that the programmer didn't think of.

          This is widely spread, popular open source software, and it is _horrible_ from a security standpoint. Collabnet, the maintainers of it, simply have no excuse for this: they have been selling professional services for this software for years, and could have at least reviewed if not accepted outright the various patches for it. The primary patch would be to absolutely disable the password storage features at compilation time, by default, especially for SSH access. There was simply never an excuse to do this.

          I urge anyone with an environment requiring security that doesn't have the resources to enforce only svn+ssh access to replace Subversion immediately with git, which is not only faster and more reliable but far more secure in its construction.

          • Re: (Score:3, Insightful)

            by profplump (309017)

            I agree writing password to the disk is bad, but have you ever used CVS/SVN/etc. without stored passwords? You end up typing your password a thousand times a day, which is simply unusable.

            So there needs to be *some* way to store passwords, or no one will use the system. On some systems there's a wallet/keychain/etc. available for secure password storage, but on most there is not, and there's certainly not a universal one among Win/Mac/linux/BSD/etc., so you pretty much have to write your own if you intend t

        • Re:Yeah, right. (Score:5, Insightful)

          by Have Brain Will Rent (1031664) on Thursday February 18, 2010 @02:03AM (#31180792)

          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: (Score:3, Insightful)

            by dzfoo (772245)

            Actually, software is applied mathematics, which can be perfect to solve a discreet problem, indeed. However, there are many factors involved in the development of software, most unrelated to mathematics and algorithms, that hasten the design and implementation, and require compromising such perfect solutions.

            It would then be more accurate to say Software is subject to business pressures, and as such it won't be perfect.

                    -dZ.

      • There's another problem here which we seem to be forgetting: The user.

        Users continue to buy systems with inferior security -- every dollar spent on Windows is a dollar telling Microsoft that you're OK with them taking months to fix known security bugs, and Apple is no better. Maybe this "contract" would help, though it will kill Easter Eggs, among other things, and that makes me sad.

        But even if you design the most secure system ever, it's useless if the users aren't educated about security. This was specifi

      • Re: (Score:3, Funny)

        by Maxo-Texas (864189)

        Oh please... what's with this "Window" customer requirement? It's trivial for a thief to break it with a rock. So what exactly is the point of doors and locks????

        Apparently all car makers are aiding and abetting by including windows.

    • Re:Yeah, right. (Score:5, Informative)

      by 0x000000 (841725) on Wednesday February 17, 2010 @10:17PM (#31179454)

      Holding programmers accountable for their coding errors should happen inside of the corporation as they are working on the project. I don't remember which company had this, but if a developer broke the build it failed to pass a test a lava lamp at their cubicle would turn on, and until the developer fixed the build the lava lamp would stay on, which generally meant you had a certain amount of time to fix the issue before it would actually start bubbling. This way there is an incentive not to break the build, and a bit of competition between the various programmers to have the least amount of bugs or build breakages.

      Having programmers imagine every way that their program may be attacked is impossible. There will always be new attacks that take advantage of that one that the programmer had not thought of. Just like the security systems that are in place at airports around the world. If the good guys could come up with every single scenario that an attacker could take airports would be much safer, as every single scenario had already been thought about.

      I agree with you, don't put all the blame on me as a programmer.

      Oh, if I had mod points, you sir would have them!

      • Re: (Score:3, Funny)

        by ls671 (1122017) *

        > Holding programmers accountable for their coding errors

        We used to have a board where we would note "bozo the clown points" for anybody involved in the project, even managers ! ;-))

        http://en.wikipedia.org/wiki/Bozo_the_Clown [wikipedia.org]

      • by putaro (235078) on Thursday February 18, 2010 @05:09AM (#31181714) Journal

        We used to have the "Diaper of Shame". That started when one of the engineers said "If my code is broken, I will wear a diaper around the office all day tomorrow". Sure enough, it was broken and sure enough, some one went out and got a package of adult diapers.

        We let him wear it over his pants and afterwards it would just migrate to your cubicle.

        I wonder if we could still do that today....I smell a harassment suit being stirred up somewhere.

      • Having programmers imagine every way that their program may be attacked is impossible.

        Fortunately, that's typically not required for software security. In a lot of cases, you can prove that for all inputs, the software does the intended thing.

        For instance, if you know that the username variable will always be properly escaped, you don't care whether the user is called "bobby" or "bobby tables" (http://xkcd.com/327/ [xkcd.com]).

        It takes a lot of discipline, though, to always consider who the origin of a particular piece of data is, to decide (based on that) exactly what amount of trust to place in it,

    • Re:Yeah, right. (Score:5, Insightful)

      by rolfwind (528248) on Wednesday February 17, 2010 @10:22PM (#31179504)

      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. (Score:4, Insightful)

        by chebucto (992517) * on Wednesday February 17, 2010 @11:16PM (#31179850) Homepage

        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.

        But other engineers can't specify all the variables. They have to deal with the real world - rock mechanics, soil mechanics, wind, corrosion, etc. - so they too can never know exactly what they're dealing with. Many of the worst engineering disasters occured because some aspect of the natural world was poorly understood or not accounted for. However, it remains the engineer's responsibility to understand and mitigate those uncertainties.

      • Re:Yeah, right. (Score:5, Insightful)

        by cgenman (325138) on Wednesday February 17, 2010 @11:23PM (#31179900) Homepage

        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: (Score:3, Insightful)

          by pla (258480)
          Geez, #7 is fricking directory traversal. DIRECTORY TRAVERSAL. In 2010!

          While that (and a good many of these "bugs") sounds really really obvious, consider that many apps vulnerable to such attacks started as strictly single-user locally-running versions. Yes, you want to take basic steps to make sure your users don't accidentally overwrite system files (though any "real" OS does this for you), but for the most part, you trust a local user not to trash their own files. Permissions? If a (local) program
    • Re: (Score:3, Insightful)

      by daem0n1x (748565)

      It's funny those nazi assholes are trying to pin all the problems on developers. A background check? Are they fucking crazy?

      A lot less software bugs would exist if PHBs weren't trying to cut costs all the time, assigning to the lowest bidder, establishing stupid project timelines and disregarding training, planning, documentation and tests as useless time-wasters.

  • by empesey (207806) on Wednesday February 17, 2010 @10:00PM (#31179326) Homepage

    A real programmer can do all 25 in one line of code.

  • Alanis ? (Score:5, Funny)

    by daveime (1253762) on Wednesday February 17, 2010 @10:02PM (#31179338)

    Kind of ironic the report is a PDF file, when another report stated that PDF accounts for 9/10 (or something like that) exploits last year.

  • by drfreak (303147) <dtarsky&gmail,com> on Wednesday February 17, 2010 @10:02PM (#31179340)

    Some of the errors are not relevant, mainly having my code in a managed (i.e. .NET) environment. The SQL injection and XSS potential vulnerabilities are still very relavent to me. Although most of my responsibility lies in code which is only reached via a https authenticated connection, as with any other web programmer, a "trusted" user can still -especially- find exploits.

    This is even more true in inherited code. If you inherited code from a previous employee, I recommend a rigorous audit of the input and output validation. You just don't know what was missed in something you didn't write.

  • by WrongSizeGlass (838941) on Wednesday February 17, 2010 @10:04PM (#31179348)
    ... letting me try assembler with my level of dyslexia.
  • Bad Idea (Score:5, Insightful)

    by nmb3000 (741169) <nmb3000@that-google-mail-site.com> on Wednesday February 17, 2010 @10:05PM (#31179354) Homepage Journal

    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: (Score:3, Insightful)

      by Meshach (578918)
      It does not matter how well you test something there will still be bugs. A successful test does not prove the absence of bugs, it just fails to prove the presence of any bugs.
    • Re: (Score:3, Interesting)

      by evanbd (210358)

      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.

      Yeah, but you can keep them from doing it again.

      The reason people don't use these well-known techniques is very simple: it takes time and effort, and people are lazy. So until the customer tells them to, they won't bother.

      Which brings me to my biggest objection to this proposed contract. There's lots of documentation requirements, and no assignment of liability. Documentation is expensive to produce, and much of this I really don't care about. (Exception: the document on how to secure the delivered soft

      • Re:Bad Idea (Score:4, Insightful)

        by Canberra Bob (763479) on Thursday February 18, 2010 @01:30AM (#31180608) Journal

        Yeah, but you can keep them from doing it again.

        The reason people don't use these well-known techniques is very simple: it takes time and effort, and people are lazy. So until the customer tells them to, they won't bother.

        Which brings me to my biggest objection to this proposed contract. There's lots of documentation requirements, and no assignment of liability. Documentation is expensive to produce, and much of this I really don't care about. (Exception: the document on how to secure the delivered software, and security implications of config options, is an excellent idea.) For most of the documentation requirements, I don't really need to hear how you plan to do it: I just need to know that, if you screw up, you're going to be (at least partially) financially liable. And yet, the contract fails to specify that. What happens when there *is* a security breach, despite all the documentation saying the software is secure? If the procedures weren't followed, then that's obviously a breach of contract — but what if there was a problem anyway?

        I actually like designating a single person in charge of security. Finding someone to blame after the fact is a horrible idea. However, having someone who's job it is to pay attention early, with the authority to do something about it is an excellent way to make sure it doesn't just fall through the cracks. By requiring their personal signoff on deliverables, you give them the power they need to be effective. (Of course, if management inside your vendor is so bad that they get forced into just rubber-stamping everything, that's a different problem. But if you wanted to micromanage every detail of how your vendor does things internally, why are you contracting to a vendor?)

        I don't agree there re the lazy comment. The reason poor coders release insecure code is because they are lazy. For the rest of us, it is generally because we are told we MUST release X features by go-live date. Go-live date will not slip under any circumstances. X features are non-negotiable for go-live date. The project manager (not the development PM, the project owner) has assigned a certain period for testing, however this testing is never SIT or the such, it is usually UAT of a very non-technical nature and the devs time is spent on feedback from UAT. Development itself has virtually no proper regression / SIT / design time factored in. The development team are never asked how long realistically something will take, instead some non-technical person will tell them how long they have and then tells them to figure out how to make it happen. Specs will change continuously throughout the project so a design approach at the beginning will be all but useless at the end after numerous fundamental changes (got this one on a project I'm working on now - had my part finished, fully tested and ready to deploy about 3 months ago, then change after change after change and I'm still doing dev and if I mention that I need time to conduct SIT / regression testing I'm told "but I thought you fully tested it already a few months ago?"). This leads a dev with a fast approaching deadline, who doesn't have the authority to say "no, this won't give us enough time to test properly" and the emphasis on being feature complete rather than a few features down but fully tested and secure.

        This of course does not even touch on the subject of what happens if a third party library or other software sourced externally has vulnerabilities. Can you in good faith sign off that you guarantee a piece of software is totally secure without knowing how third party libraries, runtime environments or whatever were developed? This is not just isolated to open source, try holding MS liable for a security vulnerability that was uncovered after you deployed and see how far you get. This then starts taking us out of the realm of absolutes and into the realm of "best practices" etc. So how good is a contract that expects the signatory to follow "best practi

  • Or did they retire that category?
  • ... how many of these errors have been committed by slashdot?
  • When you say "developer", I think individual employee. However, the individual employee isn't around long enough, the project validation will more than likely happen after the majority of them have finished, taken their final pay and left.

    As for the actual contract? It reads like lawyer bait.

    Consistent with the provisions of this Contract, the Vendor shall use the highest applicable industry standards for sound secure software development practices to resolve critical
    security

  • I didn't see this [boingboing.net] one in there... I once typed it into some code by accident. It's more common than you'd expect.
  • by QuantumG (50515) * <qg@biodome.org> on Wednesday February 17, 2010 @10:28PM (#31179558) Homepage Journal

    So much shit. So much commentary. Just gimme the list? Here it is:

    1. Failure to Preserve Web Page Structure ('Cross-site Scripting') [mitre.org]
    2. Improper Sanitization of Special Elements used in an SQL Command ('SQL Injection') [mitre.org]
    3. Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') [mitre.org]
    4. Cross-Site Request Forgery (CSRF) [mitre.org]
    5. Improper Access Control (Authorization) [mitre.org]
    6. Reliance on Untrusted Inputs in a Security Decision [mitre.org]
    7. Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') [mitre.org]
    8. Unrestricted Upload of File with Dangerous Type [mitre.org]
    9. Improper Sanitization of Special Elements used in an OS Command ('OS Command Injection') [mitre.org]
    10. Missing Encryption of Sensitive Data [mitre.org]
    11. Use of Hard-coded Credentials [mitre.org]
    12. Buffer Access with Incorrect Length Value [mitre.org]
    13. Improper Control of Filename for Include/Require Statement in PHP Program ('PHP File Inclusion') [mitre.org]
    14. Improper Validation of Array Index [mitre.org]
    15. Improper Check for Unusual or Exceptional Conditions [mitre.org]
    16. Information Exposure Through an Error Message [mitre.org]
    17. Integer Overflow or Wraparound [mitre.org]
    18. Incorrect Calculation of Buffer Size [mitre.org]
    19. Missing Authentication for Critical Function [mitre.org]
    20. Download of Code Without Integrity Check [mitre.org]
    21. Incorrect Permission Assignment for Critical Resource [mitre.org]
    22. Allocation of Resources Without Limits or Throttling [mitre.org]
    23. URL Redirection to Untrusted Site ('Open Redirect') [mitre.org]
    24. Use of a Broken or Risky Cryptographic Algorithm [mitre.org]
    25. Race Condition [mitre.org]
    • Re: (Score:3, Informative)

      What's sad is that SQL injection and good old primitive buffer overflow still top the list...

      Regarding #2, I'm inclined to blame PHP for that thing being so high up there. Its standard library way of handling parameters in SQL statements has long been lacking - and while it's definitely possible to get right, and there are frameworks which make it easier, too much "HOWTO" and "learn in 24 seconds" PHP code out there is written without any regard to injection possibility, and it gets blindly copied over and

  • Improper Sanitization of Special Elements used in an OS Command

    The best solution is not "sanitization" (which people usually perform by blocking or editing out what THEY think are dangerous metacharacters) but proper encapsulation. In addition, there's a misleading section here:

    For example, in C, the system() function accepts a string that contains the entire command to be executed, whereas execl(), execve(), and others require an array of strings, one for each argument. In Windows, CreateProcess() only accepts one command at a time. In Perl, if system() is provided with an array of arguments, then it will quote each of the arguments.

    Execl() is not a "C" API, it's a UNIX API. It doesn't involve quoting. On a UNIX system, you can safely take advantage of this mechanism to pass parameters and bypass either shell or application quoting inconsistencies. On Windows, even if your program is in Perl and you pass system() an array of arguments, Perl is still at the mercy of the called program to correctly parse the quoted string it gets from CreateProcess()... *unless* you are operating under the POSIX subsystem or a derivitive like Interix.

    In addition, whether you quote your arguments, use execl(), or use a smart wrapper like Perl's system(), you still need to ensure that COMMAND level metacharacters (like the leading dash (on UNIX) or slash (on Windows) of an option string) are properly handled.

    This latter problem may remain even if you pass the command arguments through a configuration file to avoid the possibility of shell metacharacters being exploited.

    Whitelists can't be simplistic. You can't ban the use of "-" in email addresses, for example. Encoding is better.

  • Lol @ Dangerous (Score:3, Informative)

    by JustNiz (692889) on Wednesday February 17, 2010 @11:32PM (#31179958)

    I work as a software developer in the avionics industry.
    This list is ridiculous.
    There's nothing any website programmer could do that is even remotely dangerous compared to what we could screw up yet all I see in the list are website programming bugs.

  • by nick_davison (217681) on Wednesday February 17, 2010 @11:48PM (#31180062)

    "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,"

    And, as a consumer, you have the power to influence vendors to provide better employment and buying practices by letting them know that they are important to you.

    Meanwhile, the vast majority of America continues to shop at Walmart whilst every competitor goes out of business.

    "Does it get the job done? Now what's the cheapest I can get it for?" is most people's primary motivation.

    Sellers, who listen to them saying, "I want security!" and deliver that, at the expense of greater cost, are then left wondering why the competitor who did just enough to avoid standing out on security but otherwise kept their product slightly cheaper is selling many times more copies.

    So, yes, people can influence sellers with their actions. The problem is, it needs to be their actions, not their words. Even worse, they're already successfully doing just that - unfortunately, their actions are screaming something quite different to any words about, "Security is truly important to me."

  • by Animats (122034) on Wednesday February 17, 2010 @11:48PM (#31180064) Homepage

    Been there, done that, in an aerospace company. Here's what it's like.

    First, the security clearance. There's the background check before hiring, which doesn't mean much. Then, there's the real background check. The one where the FBI visits your neighbors. The one where, one day, you're sent to an unmarked office in an anonymous building for a lie detector test.

    Programming is waterfall model. There are requirements documents, and, especially, there are interface documents. In the aerospace world, interface documents define the interface. If a part doesn't conform to the interface document, the part is broken, not the document. The part gets fixed, not the documentation. (This is why you can take a Rolls Royce engine off a 747, put on a GE engine, and go fly.)

    Memory-safe languages are preferred. The Air Force used to use Jovial. Ada is still widely used in flight software. Key telephony software uses Erlang.

    Changes require change orders, and are billable to the customer as additional work. Code changes are tied back to change orders, just like drawing changes on metal parts.

    In some security applications, the customer (usually a 3-letter agency) has their own "tiger teams" who attack the software. Failure is expensive for the contractor. NSA once had the policy that two successive failures meant vendor disqualification. (Sadly, they had to lighten up, except for some very critical systems.)

    So that's what it's like to do it right.

    A real problem today is that we need a few rock-solid components built to those standards. DNS servers and Border Gateway Protocol nodes would be a good example. They perform a well-defined security-critical function that doesn't change much. Somebody should be selling one that meets high security standards (EAL-6, at least.) It should be running on an EAL-6 operating system, like Green Hills Integrity.

    We're not seeing those trusted boxes.

  • by sigma (53086) on Thursday February 18, 2010 @01:57AM (#31180762)
    if (alert_code = red)
       launch_missles ();
    • Re: (Score:3, Funny)

      by geminidomino (614729)

      //Fixed.

      void le_nap(void)
      {
                sleep 500;
      }

      if (alert_code = red)
      {
            if (le_tired) le_nap;
            launch_missles ();
      }

  • Wrong approach. (Score:3, Interesting)

    by malkavian (9512) on Thursday February 18, 2010 @08:45AM (#31182906) Homepage

    By all means, accountability is great.
    But saying the developer is at fault is ridiculous. It opens the door for companies to mismanage projects as per usual, and clueless HR departments to hire people who don't know what they're doing, and fire people arbitrarily every time they have a complaint from someone that the software doesn't work.
    Start the responsibility with the company. If the company sends a flawed product and are to be made accountable, then the organisation needs to prove:

    * It has proper QA processes in place to test the product, and that the staff are suitably qualified.
    * The project management was performed to allow for proper specification, design and development within the normal working hours of a day, taking holidays and time lost due to usual unforeseen circumstances.
    * Training, or self learning time is allocated to enable staff to keep current with developments and issues with languages/compilers/methods they use.

    If you're going to hold a developer responsible, then it should be absolutely certain that everyone in the dependancy chain for that person is responsible. Did HR hire someone who wasn't fit for purpose? Their job is to ensure that doesn't happen. They're the start of the problem chain.
    Did management provide the logistics necessary to complete the job to a quality? If not, they should be liable.
    Did the sales team (if it's bespoke software) make impossible promises (if so, and developer opinion was overturned such that a 'broken' system was arrived at from spec, then the salesman should be accountable).
    Did the producer of the spec introduce a design flaw that resulted in the error? If it wasn't the developer, then the specifier/designer was at fault.
    Pretty much whichever way you look at it, management and HR should carry the can first, leaking down to the developer, if you're going to be sensible about it. If a place is well run, well managed then sure, have developer liability, but expect to have raised costs to cover developer's professional liability insurance.

  • by metamatic (202216) on Thursday February 18, 2010 @03:55PM (#31189434) Homepage Journal

    1. PHP.
    2. Visual BASIC.
    3. Perl.
    4. C.
    5. C++. ...better stop there before I get modded into oblivion.

"Regardless of the legal speed limit, your Buick must be operated at speeds faster than 85 MPH (140kph)." -- 1987 Buick Grand National owners manual.

Working...