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

Background checks are awful and stupid

[Anonymous Coward]

I am a competent and trustworthy programmer in his late 30s who will fail a background check because I was convicted of something in my mid 30s, something I did when I was a teenager (and still a minor).

I have, over the years, been given many responsibilities and opportunity to abuse the authority required to discharge those responsibilities. I never once have abused that authority. If you ask previous co-workers if they consider me honest and trustworthy they will unanimously tell you that I'm one of the most trustworthy people they know.

I strongly resent the growing prevalence of background checks. I wasn't convicted of any sort of fraud or theft, but I am rejected anyway. The sad part is half the time I end up having to tell someone exactly what I was convicted of and why, and they wring their hands over their policy being so stupid but follow it anyway.

Background checks lead to stupid behavior. The criminal justice system is only a mediocre to poor arbiter of who is and isn't trustworthy. Like lie detector tests, you can never pass, only fail.

Re:Yeah, right.

[0x000000]

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!

Just Show Me the List!!

[QuantumG]

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]

Sanitization is a worrying term to use.

[argent]

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.

Re:Sanitization is a worrying term to use.

[russotto]

In general, introducing complicated languages (like shell script, or SQL) is a good way to absolutely fuck yourself. God damn SQL for making it so freaking hard to just STICK DATA INTO A DATABASE SAFELY.

Use prepared statements. A prepared "INSERT INTO FOO (BAR, BAZ, BIFF) VALUES (?, ?,?)", along with parameters from the user, is safe from SQL injection attacks, no matter the parameters.

Unfortunately there are a few cases you can't do that. No way to use a prepared statement for an "IN" clause, for instance.

Lol @ Dangerous

[JustNiz]

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.

Re:Just Show Me the List!!

[QuantumG]

Typically such a flaw appears in web applications. As such, the attacker does not have access to the local machine, and such an attack gives him information would could aid him in gaining access (usernames).

Re:Background checks are awful and stupid

[Ethanol-fueled]

I post anonymously, even though I hate doing that because it makes it impossible for me to read any responses.

Click on your post number, then bookmark that page. Works great for keeping track of troll^W posts.

Re:Just Show Me the List!!

[shutdown -p now]

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 over.

Still, that crap is regularly seen in Java and .NET apps as well. Which is really sad, because there's absolutely no excuse to get it wrong there - all you need to do is to use parametrized statements (PreparedStatement in JDBC, the usual DbStatement in ADO.NET). Always. No exceptions. Period.

Buffer overflow? God, how long this has been around? Still in top #3...

Well, for one thing, it shows just how much software is still being written in C & C++ rather than managed languages. For another, it shows that a lot of software written in C++ ignores the higher-level features of the language, and uses old-style code littered with strcpy and the likes.

I would have hoped we can do better in 2010...

Re:Yeah, right.

[the_enigma_1983]

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.

I don't get why CVS/SVN/etc even should deal with security. They're source control/management systems. For public pull/fetch/get-only servers, no password is required. For situations where security, is required, set up SSH access, or some other secure access (and use an ssh keyagent if you don't like typing your password in heaps).

Re:Therac-25

[slimjim8094]

Yes and no. The problem was that the software could get into an inconsistent state - this shouldn't happen, but it shouldn't be a problem. And it wasn't, because the first generation had hardware interlocks that made it fail safely (beam wouldn't activate).

Cutting corners was the biggest problem. Had they not removed the interlocks for cost reasons, nothing bad could have happened. It would have been physically impossible.

Another couple of deaths due to the profit motive. I don't mean to suggest that the profit motive is always bad, but I don't want the company making my radiation machine to be concerned exclusively with making money.

Re:zero risk

[Noughmad]

Only a Sith deals in absolutes.

Re:Yeah, right.

[Antique Geekmeister]

_Allow_ svn+ssh. Too many sites have managers unwilling to do so, and insistent on using HTTP with the user's own system passwords used in clear-text via HTTP, and stored in clear-text on build servers, because they cannot be bothered to allow competent managers to _enable_ svn+ssh.

The problem isn't that servers won't allow svn+ssh access, it's that managers for such sites won't allow the "svn" user to be configured and used in such circumstances. I've run into exactly that situation on several occastions: I've set up git->svn translation systems for use in such locations, because such sites are usually so stupid they do all their work in "trunk", anyway, and the gateway works fine there.

Re:Yeah, right.

[Anonymous Coward]

Since at least 1.6, Subversion uses the relevant keystore sub-system on all major OSs - e.g. KWallet on KDE, GNOME Keyring on GNOME, etc. Prior to 1.6 I believe only Windows and OSX used native keystores. Regardless, the password was stored in the user's home directory - which, with proper/normal permissions is inaccessible to anyone other than the user and root.

This article [linuxforu.com] is Linux-focussed, but discusses Subversion's use of Linux keystores.

Incidentally, CollabNet aren't the maintainers. They originally developed it, continue to provide devs for the project, but Subversion is an Apache project. Even before coming under the ASF umbrella it was its own project. Describing it as a CollabNet project is like describing Linux as a project of Linus' current employer.

Re:Yeah, right.

[daid303]

Brute forcing a 256bit key is impossible in this universe with the laws of physics as we know them

RSA keys up to 768bit have been broken: http://en.wikipedia.org/wiki/RSA_Factoring_Challenge [wikipedia.org]

The RSA-100 challange, which had a strength of 300 bits: "It takes four hours to repeat this factorization using the program Msieve on a 2200 MHz Athlon 64 processor."
http://en.wikipedia.org/wiki/RSA_numbers#RSA-100 [wikipedia.org]

Re:Yeah, right.

[Deus777]

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 some names have punctuation in them like . or ' or -. Eventually it got to the point where I was even allowing () because the name field was being used to distinguish between different people with the same name.

The lesson I learned from this is that if you don't have to interpret the data, you are better off just escaping any special characters and working with it that way. Aside from limiting the maintenance you may have to go through, it allows the users to enter whatever they want without arbitrary restrictions on characters.

Preventing buffer overruns in compiler

[dmhayden]

I believe that most buffer overrun exploits work by overwriting a function's return address on the stack. These could be largely avoided by the compiler using either of two techniques. First, it could grow the stack into higher numbered addresses and store the return address first. Now if the code allows a buffer overrun, it will overrun the local variables and spill into the available stack space. In both cases, the chances of finding a function pointer are small. In contrast, if you grow the stack into smaller numbered addresses, then a buffer overrun has pretty much 100% chance to overwrite a code pointer (the return address).

The other technique is to use two stacks, one for the return addresses and another for the parameters/return values. Same idea though: move the return address out of the way of the overflowed buffer.

Re:Background checks are awful and stupid

[Anonymous Coward]

Fact: child molesters have the lowest recidivism rate of all convicts. I don't know how you define "too high", though. Perhaps it's any rate > 0%? I also enjoy punishing the majority for the mistakes of the minority. It's kind of "my thing".

- Despot