Well, back in 2009 SANS published its list. It was going to be regularly revised. In 2010, there was a revsion, and an archive of the 2009 version was retained on line along with the new (2010) version. In 2011 there was another revision, and the 2010 version was archived, so now there was a current version and two archived versions online; and the current version contained the statement "The TOP 25 Errors List will be updated regularly and will be posted at both the SANS and MITRE sites"; that was June 27th, 2011. There has been no update to the SANS site since. Is that because there are no new mistakes to be made, or because the world has not learnt anything so that all the old mistakes are still being made just as much as before? Do they think it's a perfect list (if so they are nuts)? The 2011 page at the MITRE site (http://cwe.mitre.org/top25/[/url] has a discussion of each error and a whole pack of advice on how to avoid these errors - the SANS site doesn't even have a decent description of what the errors mean (the 2010 and 2009 verson were better in that respect) let alone advice on avoidance. The Mitre page was being updated up to september 2011, presumably to provide all the material that SANS doesn't have. Although it is two years out of date, just as the SANS page is, it is an infinitely more useful page than the one at SANS.

I look at their insecure interaction category, and see that it includes SQL Injection, OS Command Injection, Cross-site scripting, Unrestricted upload of file with dangerous type (that one makes me wonder how the type is to be determined, and which types are considered dangerous, but never mind), Cross-site request forgery, and redirectipn to untrusted site. Well, apparently if there are several components of the application all running on the same server it doesn't much matter of they pass each-other rubbish instead of what they should pass; if one application component unintentionally is such that now and again it will effectively do an injection attack against not SQL server and not the OS but against another application component, that doesn't matter; it isn't important for each application component to validate all its parameters - oh, it has to validate strings (and their lengths) and if it's taking a security decision it mustn't rely on untrusted inputs, and a critical function must authenticate its users (you might guess that's what CWE-306 is about if you read the SANS page; but you won't know unless you read the Mitre page); but one component validating parameters (other than strings) passed by another - failue to do that isn't a sufficiently serious error to be on the list, while validating strings is on at least twice (once as check the length and once as check the format; presumably the OS command injection issue will mean checking the content, so maybe it's three times; SQL injection should be avoided by allowing only calls to stored procedures and ensuring that those calls are seen from application level as parametrised calls where the command part consists only of the procedure name, a technique which is as old as the hills, so that won't include ding validation of string content beyond the format and length issues). To me this seems wrong - put strings in once - validate that they will fit the input buffer before copying them into it and ensure that teh format is valid, and mentionvalidation of other parameters too as another thing whose very common omission can be a big and unpleasant error.

I would recommend everyone to look at the cwe websites front page, not just the top 25 page, and see which other parts of the site they might find useful to read; in my view we would have far fewer bugs if all developers read and inwardly digested the whole site, but that's probably asking too much.

Steve expressed concern about the way software development is taught, about dumbed down examples, doing it the easy way without regard to best (or even great) practises, and keeping things simple by avoiding robust error checking, error handling, and security practices. I share that concern. I would go so far as to say that people are usually not taught to do software development or to be software engineers; they are taught something about a couple of programming languages and how to do some clever tricks in those languages, but nothing about error management or the design of something that would take the average student more than eighty hours to design and write. Universities should be teaching error management, code verification techniques, designing modular systems with clear boundaries and tight and narrow interfaces, as declarative a programming style as possible, how to estimate computational complexity, how to design for testability, how to test, and how to distinguish good practise from bad. Some universities/colleges/training companies do try to teach all of this to their students, others attempt some of it, and yet others teach none of it and instead concentrate on how to write code using C++ or Java or some other fairly awful but very fashionable language without any regard to error management, security, modularity, or declaritiveness. It's the developers educated (if you can call it that) by this last group that are the cause for concern; fortunately they usually can be taught despite the bad habits there education has instilled in them.