Slashdot Mirror
The Most Dangerous Programming Mistakes
snydeq writes "Fatal Exception's Neil McAllister discusses the most dangerous programming mistakes, and what can be done to avoid them. 'Even more than input validation errors, this year's list is rife with application security blunders of all kinds. Some of them sound fairly esoteric, such as "inclusion of functionality from untrusted control sphere." But of all such errors, the highest-ranking one on the list is "missing authentication for critical function" — in other words, the attacker was able to gain access because there was no lock on the door to begin with,' McAllister writes. 'With the pace of Internet attacks accelerating, now is not the time to cut QA staff or skimp on testing and code review.'"
If you'd like to read what the mistakes *are*, instead of a fluff piece that amounts to "oh, they're so awful! And people make them all the time, too!", here's the actual original article: http://cwe.mitre.org/top25/index.html
...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.
"There are a dozen opinions on a matter until you know the truth. Then there is only one." - CS Lewis (paraprhase)
it's-probably-fine,-we'll-test-it-live
Could describe every "upgrade" to slashdot that has happened since ... well probably ever.
Damn_registrars has no butt-hole. Damn_registrars has no use for a butt-hole.
To work around Slashdot's brokenness, did you try double right-click, then open in new tab? It appears to work for me in Firefox 5.
Dear Web Developers,
Stop using toy languages. A strongly typed language that only accepts type "SanitizedString" as an SQL function parameter will end this problem forever.
No sig today...
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.
Slashdot - News for Herds. Stuff that Splatters.
While TFS and TFA call them "programming" mistakes, the actual source refers to them as the "Top 25 Most Dangerous Software Errors".
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.
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.
Microsoft's Visual C++ compiler will throw a huge number of warnings for things like strcpy, telling you to use strncpy_s or something like that.
You shouldn't even be using strcpy(). std::string has been around for more than ten years now.
Similarly arrays: Don't use them, use std::vector instead. Visual C++ vector even does range checking by default so this throws an exception instead of corrupting memory:
std::vector foo(10); // Will throw an exception in VC++...
foo[11] = 123;
A few basic changes in programming style can make C++ as safe as Java (but with none of the drawbacks). If you're still writing C code with your C++ compiler you're Doing It Wrong.
No sig today...
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.
Because you can doesn't mean that everyone should.
You cited a few shining examples of people doing the right thing. Unfortunately, those languages make it so damn easy to do the wrong thing and that is precisely the problem.
Bull. 2 out of those three examples make it easy to do the right thing.
Perl has DBI, which does parametrised queries very well, and in fact makes quoting a pain, because all the nice functions like binding variables to query results do not work well (if at all) with quoted queries. And if DBI is too low-level, there is always the DBIx::Class ORM.
Python's DB-API 2.0 is the standard to do databases in Python, and it too makes parametrised queries a lot simpler than quoting. And on top of that you can use SQLAlchemy.
I agree with PHP being bad. Sure it has parametrised query support in various libraries, but the default is still to use MySQL as backend and use the various mysql_yes_really_quote_it_correctly_this_time() functions. Given that until recently even the maintainers of the language didn't have clue as to how to do security right, PHP is by far the most unsuitable language to do secure web programming in.
Mart
"I know I will be modded down for this": where's the option '-1, Asking for it'?
In Perl this is easy. Let's say that @args holds your argument list. Then it goes like this:
my $query = "select * from table where column in (";
# Use $#args to get the index value of the last member of the array @args. This gives us a loop that's one iteration shorter than the lenght of the argument list.
for (1..$#args) { $query .= ' ?, '}
$query .= '? )';
my $sth = $dbh->prepare($query);
$sth->execute(@args);
# Bind result columns with $sth->bind_col
while ($sth->fetch) {
# Do something with the results.
}
Mart
"I know I will be modded down for this": where's the option '-1, Asking for it'?