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.'"
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.
tasks(723) drafts(105) languages(484) examples(29106)
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.
Dear Academic Language Elitists Who Have Never Used The Languages They Are Criticising:
Slashdot is coping just fine with "only" Perl 5 and DBI. Wikipedia doesn't have a problem using PHP and PDO. Reddit serves a million users a day with Python code. Show us your code or kindly get bent.
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.
It is unfortunate that it's necessary to try to overload an existing term with a new, slightly different definition, but that's what has happened here.
Capabilities in a capability based system (cabsec for short) are fine grained access rights to things like single files, a directory, etc. They are explicitly granted at run time to a process, they are not persistent.
This is in contrast to the Access Control List permissions of VAX/VMS, inherited by Windows, and the User/Group/World permissons of Unix/Linux, both of which are geared towards restricting the rights of a user, and are generally persistent.
For example, if you give a process write access to a log file, and I/O access to the internet, and 1% of total cpu use....it could watch something on the net, and log the results. It could not access anything other than the log file, no matter what... this means a buffer overflow bug, or any other fault could not cause data to leak from the system.
In a permissions/ACL based system, the administrator decides the rights of users, and the programs they run, without distinction
With cabsec capabilities, the user decides which of their rights they wish to delegate to a process or program. This frees the user from the need to trust a given program with all of their rights. This also frees the system administrator from having to set up extra accounts with limited permission for each new service or daemon that needs to be run.
I see cabsec as a very useful extension to the existing user permissions systems. Combined you get the best of both worlds.