Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
Programming Bug

The Most Dangerous Programming Mistakes 213

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.'"
This discussion has been archived. No new comments can be posted.

The Most Dangerous Programming Mistakes

Comments Filter:
  • Better link (Score:5, Informative)

    by Chris Mattern ( 191822 ) on Friday July 01, 2011 @09:38AM (#36632870)

    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: []

    • Re:Better link (Score:5, Insightful)

      by frinkster ( 149158 ) on Friday July 01, 2011 @09:43AM (#36632916)

      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: []

      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.

      • by fnj ( 64210 )

        Slashdot is busted as usual. Cut and paste.

      • Re:Better link (Score:4, Insightful)

        by baKanale ( 830108 ) on Friday July 01, 2011 @10:10AM (#36633182)
        Switch back to the Classic Discussion System.
    • No list is complete without Therac-25 []

      • It's a listing of generic errors for the past year, not specific disasters across history. Not "Therac-25" and "the AT&T switch network crash", but "SQL injections" and "buffer overflows".

      • Ya, that's a classic.I love how the company gets all the blame for that but the people who are truly at fault are only ever glossed over.

        Machine: "Hi, I'm operating so completely out of allowed parameters I'm going to completely stop functioning. Here's a 'MALFUNCTION' warning to make sure you get me serviced before you continued."

        Operator: "How annoying. The stupid machine is trying to prevent me from dosing massive levels of radiation. Oh well, its just radiation and they're not my loved one. I'll just ig

    • Re:Better link (Score:4, Insightful)

      by tepples ( 727027 ) <tepples@gmail.BOHRcom minus physicist> on Friday July 01, 2011 @11:22AM (#36633960) Homepage Journal
      Obviously, not all mitigations on the list [] apply to all situations. Here are some examples where they wouldn't apply so easily:

      Where possible, avoid implementing custom authentication routines and consider using authentication capabilities as provided by the surrounding framework, operating system, or environment.

      This can prove cost prohibitive when the authentication capabilities provided by the surrounding operating system are marketed for use only by privileged employees, not by the public. Consider the case of an operating system that charges per user account. (Microsoft calls this the "client access license" model.) One might be tempted to use or create an authentication and authorization library that runs independently of the operating system's own auth facility, so that one needs to buy a system user account for only the web server, not for each member of the public who creates a user account on the web site.

      For outbound authentication: store passwords, keys, and other credentials outside of the code in a strongly-protected, encrypted configuration file or database that is protected from access by all outsiders

      Say I encrypt the keys that a web server uses to communicate with other web services, such as the key used to communicate with a payment processor. Now how do I store the key to decrypt those keys?

      For inbound authentication: Rather than hard-code a default username and password, key, or other authentication credentials for first time logins, utilize a "first login" mode that requires the user to enter a unique strong password or key.

      So how do we prevent an attacker from attacking a system while it is still in "first login" mode?

      Clearly specify which data or resources are valuable enough that they should be protected by encryption.

      Firesheep shows that this includes users' passwords and cookies containing authenticated session tokens. But with StartSSL having suspended operations and Internet Explorer on Windows XP still not supporting Server Name Indication, how can hobbyist web developers get the certificate and dedicated IPv4 address needed to host an SSL site?

      If possible, create isolated accounts with limited privileges that are only used for a single task.

      Please see my comment above about the CAL pricing model.

      Generate a unique nonce for each form, place the nonce into the form, and verify the nonce upon receipt of the form.

      If you've ever seen errors about a "form key" on Slashdot, Slashdot is doing exactly this.

      Do not use the GET method for any request that triggers a state change.

      Is a hit counter a state change?

      Use a built-in path canonicalization function (such as realpath() in C)

      According to this page []: "The realpath() function is not described in the C Standard." It's available only in UNIX, not in Windows.

      Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a username is valid or not.

      Does this mean don't bounce messages to nonexistent users but instead treat them as delivered and discard them? That would provide a bad user experience for people attempting to contact these users.

      Use code signing technologies such as Authenticode.

      How does a hobbyist afford the certificate for Authenticode?

      For all configuration files, executables, and libraries, make sure that they are only readable and writable by the software's administrator.

      Writable I agree with, but readable I'm not so sure. If configuration files are readable only by the adm

  • Hopefully the increased use of frameworks that write sql will decrease that problem

    • Or, move to PICK and never worry about it again.
  • by ThosLives ( 686517 ) on Friday July 01, 2011 @09:47AM (#36632958) Journal

    ...Those are system design mistakes.

    A programming mistake is one where you meant to type x+1 and instead you write x-1. Missing something like authentication or checking is a requirements or design problem, not a programming problem.

    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.

    (Yes, I don't consider "programming" to include the design aspects; I consider "programming" to mean "conversion of requirements into computer code." The errors about which this article talks are mostly requirements problems, not implementation problems.

    • Wait, wait: Are you saying that "programmer", "software engineer", and "computer scientist" aren't actually synonyms?
    • I disagree. Sticking with cars (as is appropriate here), I'd consider it a design error if the stereo volume control knob was a SPST switch, a manufacturing error if it was installed connected to the seating controls, and a programming error if it caused the drivers seat to fold completely flat, then completely fold forward, three times a second.
      • Yes, that's a much better car analogy... I was having a tough time thinking of one, sadly.

        • Yes, that's a much better car analogy... I was having a tough time thinking of one, sadly.

          Yeah, I need a car analogy on making car analogies.

    • You obviously didn't read the article then. Many of the things listed are in fact *programming* mistakes(among them integer overflows, uncontrolled format strings, and tons about not trusting inputs). My favorite of the list is "CWE-676: Use of Potentially Dangerous Functions" It's amazing how many programmers just totally brush aside compiler warnings, and while not all warnings have security implications, many do....

      But ultimately here's a hint people, the compiler isn't warning you for kicks, there's
    • 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.

      • You seem to be advocating a distinction of responsibility of knowledge where programmers should not need knowledge of design.

        Hrm. That was not my intent. Basically what I was saying is that there is a difference in types of errors between design errors which persist even if you program them correctly versus the type of errors which are due to writing code that doesn't match the design.

        Personally, I do agree that there is a more hazy line between "software engineering" and "programming" than just "implement

    • by DragonWriter ( 970822 ) on Friday July 01, 2011 @10:56AM (#36633612)

      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.

      • Another type of mistake or error that should be considered is the attempt to program or write code for something at all. I remember watching a lecture about this topic at some point and I cannot find the link anymore. The general message was that no programs are bug-free, and in some circumstances it's unethical to even attempt to program for certain devices because undetected coding errors could end up killing many people. An example would be an automated missile defense system in which someone out there h
    • As the CTO of a small startup. My first programming mistake would be to hire someone who would build a car with no lock because the original drawing had no dot where the assumed lock would go. My old boss would love you. He thought 'programming' meant writing a thousand page Word document that got debated and revised over several months of meetings and finally coded by a 'clerk typist' with a degree in languages. Our department was disbanded because in a year, we did not manage to produce anything but 5

    • I half agree. Some of the items in the list are indeed design mistakes, but others really are programmer mistakes.

      The SQL injection one is the primary one I'm thinking is really a programmer error. Take this case from Drupal/PHP:

      db_query("SELECT * FROM {foo} WHERE bar='" . $_GET['bar'] . "'");

      That is totally incorrect and SQL can easily be injected into the statement from outside. When the API is used *correctly* this is not an issue:

      db_query('SELECT * FROM {foo} WHERE bar="%s"', $_GET['bar']);

      The differenc

      • I don't like "subtle" code. I prefer to just make it very obvious what you're doing, and why:

        db_query("SELECT * FROM {foo} WHERE bar = '" . addslashes($_GET['bar']) . "';");

        • Well, sure, and that's why in more recent Drupal versions they switched to using PHP's PDO, which is much more explicit about what you need to do.

          The point was, the tool works if you use it correctly. Using the car lock analogy from above, the place for the lock was there but the developer failed to put a lock in the hole.

    • Only 3 of the 25 deal with missing requirements or design. The rest are implementation details. Sure, you can make a design that makes writing code vulnerable to SQL injection more difficult, but it's still something the programmer has to watch out for. Also, I expect programmers to bring up glaring omissions in the requirements or design, just like I would hope a worker on a car manufacturing floor would bring issues to the attention of engineering. They are on the front lines and see things designers

  • Summary of Article (Score:2, Insightful)

    by Anonymous Coward

    "Java and C# are better than PHP" wrapped in buzzwords and it mentions "SQL Injection attacks" (yawn).

    The whole thing is insulting to read for everyone more competent than management. As usual.


  • by macraig ( 621737 )

    This data type/structure is big enough; why would I need more to store larger values than I can anticipate right now? Keeping It Simple Stupid saves some bytes, too. Why would we ever need to store a four-digit year, anyway? What could possibly go wrong?

  • More Testers / QA is needed and stop the overtime working 80+ hour weeks just leads to more errors and bugs.

    Also don't get me started on rush jobs that just become try to work around the bugs and not take the time to fix them.

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

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

  • by spoonist ( 32012 ) on Friday July 01, 2011 @10:09AM (#36633178) Journal

    The Therac-25 [] had some "Dangerous Programming Mistakes".

    I wonder if the nudie scanners [] have any similar mistakes.

  • tl;dr (yet)

    But I do have something to say about the immediate response of "QA". These are design issues (as has been mentioned). QA is not where you test out that sort of thing. Up-front design (not necessarily Big) should be the first response. Now is not the time to slack off on design, just because a lot of the components have already been written.

  • Missing a Big One (Score:4, Interesting)

    by Salamander ( 33735 ) <> on Friday July 01, 2011 @10:46AM (#36633512) Homepage Journal

    The Mitre list does include "Use of a Broken or Risky Cryptographic Algorithm" but in my experience that's far less common than improper use of a perfectly good algorithm. Many algorithms and modes have known weaknesses that require specific generation/handling of keys and initialization vectors to maintain good security. Most algorithms and modes that are secure against unauthorized *reading* of data still require an extra MAC step to prevent unauthorized *modification* of that data (including targeted bit-flips). Developers often take shortcuts in these areas because doing all of "the right things" adds a lot of extra complexity and can absolutely kill performance. Look at recent events involving Dropbox and Jungledisk for examples. I don't think the Mitre list adequately conveys that cryptographic security requires not just good low-level algorithms like AES or Blowfish but also good higher-level (usually domain-specific) algorithms governing how the low-level algorithms and their inputs are used.

  • Not a shocker. I've heard time and time again from NoSQL fans that it's ok to put your database on the public internet over HTTP with no locks. In fact, early versions of CouchDB didn't have security.

    Another problem is that many novice programmers forget to secure their AJAX endpoints.. when you have 20 calls happening all over returning json, you often forget to check session or ensure authentication + authorization.

    During my computer science courses, very few times did security come up. I had one profe

  • Here is the the actual list [].
  • CWE is about "weaknesses", i.e. security. Does anyone know of a similar group or research into classifying and ranking common software errors? For example:

    - dereferencing null pointers
    - memory leaks
    - stack corruption via buffer overflow
    - out-by-one errors
    - errors in error handling code that is infrequently run
    - deadlock/resource contention
    - faults characteristic of concurrency
    - use of globals and code with side-effects

    etc. All the stuff you learnt about at university, and then went on to rediscover in your

  • by ka9dgx ( 72702 ) on Friday July 01, 2011 @11:37AM (#36634190) Homepage Journal

    Using a system where the program has to be trusted to do its job correctly is the bigger mistake. When you hand your car keys to a valet, you don't also give him power of attorney to sell your house, liquidate your stocks, savings, etc... but every operating system out there does something like that when you tell it to run a program. The program you run can do anything you are authorized to do. The default assumption is that it should have permission to do anything, no matter how stupid, dangerous, or downright evil.

    This practice needs to end, about 10 years ago it should have ended... and we'll probably have to wait 10 more years because it's so freaking hard to get this idea across, nobody seems to be ready for it yet, by the way things seem to be going.

    A user should be able to decide exactly which and how much of the resources they are authorized to use will be allowed to be accessed by a program they choose to run. If you want to run a program with read/write access to /sandbox, and the ability to read from the internet using a filtered http driver (one that doesn't allow puts, for example), you should be able to do so, without having to do any fancy footwork.

    If put in to place, this type of system, which explicitly states what access things get, make it almost trivial to never get a virus or worm ever again. It's time to stop trusting programs, and only have to trust the hardware and OS to enforce our wishes.

    I impatiently await the arrival of capability based security.

    • by Sl0vi ( 1994584 )
      Android sort of does this. Applications have to request the permissions they need at install time and the user has to grant them.

No extensible language will be universal. -- T. Cheatham