Computer experts from more than 30 organizations worldwide have released a consensus list of the 25 most dangerous programming errors that lead to security breaches. The list, which was spearheaded by the National Security Agency, is the first time a broad cross-section of the world's computer scientists have reached formal …
It only took how long to come up with a list like this?
The number one programming error
getting involved with a project on a low budget :)
It is people, not systems, that create a security problem, always will be, always has been.
@AC (low budget)
What the hell are you on? The budget has nothing to do with it. Mostly it's crappy management, followed closely by programmers that don't give a damn (often because of crappy management), that allow these types of errors to get through.
The list sounds familiar. Most if not all of these were covered as serious errors in many of the programming classes I took for my degree. Maybe programs that continue to have these errors can now be returned as being "unsuitable for the purpose".
once per year?
Maybe this list could be refined every couple of years. Now that there is an officially sanctioned list, if software development groups - especially paid groups - are still making these errors in a year or two perhaps those groups, as a whole, should be simply fired for cause. That or allow them to be sued for the damage caused by the inclusion of such errors in the code, regardless of what the weasel-worded EULA might say.
It took -20 years to come up with a list like this
All very welcome, but...
Having scanned through the list, most of these are items that I can recall being covered from my University days in one way shape or another.
Any computer science/programming course worth its salt should cover these (and more) by default. If it doesn't then it isn't worth squat.
Although, having the list formalised is a welcome development since, as the article states, it might begin to bind software developers to tighter contractual restrictions for delivering secure code.
The problem, as has already been stated by AC@02:18 is that projects on tight budgets/timescales lead to buggy software, although I would also posit that developers who have learnt their craft themselves without going through a decent, formal course are also (frequently) at fault (it's amazing also how often I see outsourced development teams on projects who have no idea of how to write good quality code or how to analyse a problem and develop a suitable algorithm)
AC since I don't want to put anyones nose out of joint from my current project (in case they're reading this)...
Mine is the heavy one with all three volumes of Knuth's 'The Art of Computer Programming' in the pockets...
A benchmark to compare from
Now that we have it, let's evaluate...
OS X and linux both brag about how few vulns affect each respective OS (and apps written for each OS.)
Redmond replies that it's just a user-share thing -- Windows has a bigger install base and therefore a bigger target.
Now that we have agreed-on standards. Let's compare, yes?
That might require actually looking at some code. Which would violate draconian EULAs, DRMs, and Gates-only-knows what-else. I don't think Jobs-Almighty would be too keen, either.
I guess we'll just have to TRUST the companies that won't open their source code. :-(
So what's new?
None of those things are a mystery to an experienced programmer.
It is nice to get them all in one place though.
They missed one
The number one programming error...
"getting involved with a project on a low budget " is a programmer's error, not a programming error. Anyway, no matter how well funded a project is, there will always be programming errors - so I really appreciate such a list of errors.
But most enjoyably is, and there is nothing to do against, if senior managers force a programme into production against all odds, i.e. project manager says 'no', developers say 'no', testers say 'no' etc. Now that was fun!
a fool with a tool is still a fool
I heard that motto a long time ago, when GUI development tools were becoming popular and MS and Borland promised that it meant any old programmer could write a sophisticated program. Of course, a bad programmer would simply write a bad program more quickly, with a glossier UI.
Paris, because she knows men with tools can be fools.
This is a very odd list; it's a mixture of stuff that's genuinely worth pointing out e.g. 'validate your inputs', with stuff that a well-designed operating system and underlying security model shouldn't let you do anyway - I mean, making sure you don't violate memory bounds? If you told the OS in advance the size of the memory, should it not just throw an error if you try? I'm no modern OS expert, but I'd expect stuff like that out of the box.
I'd like to see an alternative list which gives 25 most useful tips for making programs useful, maintainable - "don't hard-code values from your data", "define things once", "put in adequate comments", "write the documentation" (gasp!).
all your code are belong to them.
No, really, this is in one of the recommendations.
Eating your own dog food
This is an excellent list for code reviews, thanks for highlighting it. I shall go home and review my software immediately!
don't use malloc()
Dynamic Memory Allocation screws up eventually. If you can write the program without using Dynamic Memory Allocation then it will run for years without a reboot.
Who's going to pay for that?
I can foresee how it's going to work: customer asks for guarantee that the software is free of the "25 errors", dev tells him that the software is then going to cost twice as much, customer changes his mind.
'Sunny day' mindset
Most programmers still program for the 'Sunny Day' case. They design and code systems assuming that nothing will go wrong and then bolt on error checking almost as an afterthought. A proper system needs to be designed assuming that things can and will go wrong. Unfortunately designing robust applications is time consuming and expensive, two things that management don't want to hear. The situation is not helped by universities who don't seem to teach robust programming.
The whitepaper link actually takes you to an article about email... not programming :P
Irony - oh yeah
So, I presume they chose their top 25 based on peer-reviewed publications based on tests conforming to the scientific method, yes?
oh they mean
WEB programming errors
Not real programming errors
Can we get those 25 errors...
...translated into detectors for FindBugs and the like?
Oh, I knew where I have seen it...
...It's the Redmond's best-seller "Top 25 programming techniques for Windows, Office, IE7 and Vista" with another name.
Mine is the one below the 5 million pages of code of the Windows kernel labeled "To review and rename as Windows 8, then 9, then X".
The #1 programming error
Is using an underspecified, unsafe language like C. Many common errors could be fixed if you avoided unsafe casts, null-pointers, manual memory deallocation, unchecked array access, unchecked pointer arithmetic and returning pointers to data in the local frame from function calls.
These things are incredibly easy to fix in language and compiler design, and the runtime cost is minimal. So there is no reason to stay with C (or even C++, which inherits most of C's weaknesses).
Re: don't use malloc()
''If you can write the program without using Dynamic Memory Allocation then it will run for years without a reboot.''
If you can write a program without using dynamic memory allocation - then it is probably solving a simple problem - that is why it will run for years.
Hard coded passwords
So, that takes mySQL off the internet then - how many eCommerce sites use mySQL as a back end and use a single (private) username/password to store orders etc. Any I don't believe mySQL is modular enough in it's security to allow individual users to lock out only their records.
Nice idea but all are really just common sense which will get overridden by timescales/budgets etc.
Paris - I can think of 25 videos, er mistakes she's made.....
re: The number one programming error
A tautology. Since people are the ones IMPLEMENTING the system, if the system they implement is broken, then people are responsible.
But you can't blame the higher ups, so we blame the system. It's then Somebody Else's Problem.
There's always 25
I love these lists. These guys can stay in employment indefinitely - even assuming the unbelievable happens and we get an ISO standard (or something similar) that ensures they are dealt with, there's still a top 25 - it's basically numbers 26-50 at the moment.
re: don't use malloc()
So what do you use? free()? That uses malloc. Garbage collection of Jave? That uses malloc. Managed C# code? That uses malloc.
How else do you manage Memory ALLOCation without using malloc?
How much is down to M$?
Back in the 70s, a globally renowned UK mainframe company used a high level language for the OS development because anyone could write or support it, unlike assembler languages.
They found that to be a fallacy. Given that anyone could write the code, but the results were not impressive: just as well it was easy to maintain due to the high number of bugs!
A radical rethink and programmer culling took place followed by a major rewrite and then things started to take off.
M$ and their ilk are just repeating the original mistakes, but do not have the intelligence to locate the major flaw and rectify it.
What appears to be worse is that because M$ are who they are, and have published training material on how to do programming and projects badly, the rest of the world's numpties have sat up and, in their very finite wisdom, taken the garbage as their bible. One cannot get a local programming job here unless you are qualified to make the same mistakes!
@Vladimir, Tom Cooke
Vladimir: I suppose you could always download the open source parts of OS X, such as the kernel and the HTML rendering code - that'd give you a pretty good insight into the bits that most people and applications are likely to touch irrespective of whether Jobs wants you to.
Tom Cooke: yeah, I noticed that. It's probably slightly misleading to say that the list has been formalised; the problems that are part of the list have been formalised, the list itself is written in parts in a broken 13-year old's blog English.
your useful programming tips are not coding errors though, they are simply coding standards. If you are outsourcing work without a decent coding standards document you are in trouble!
I wrote our teams standards and went down to a stupid degree of detail, ie what sort of things needed to go in comments, that they had to be gramatically correct UK English. that meaningful numeric values had to be defined, that subroutines shoudl be used instead of duplicating code, etc. The majority of it is just normal programming practice for any reasonably competant developer, but if you don't specify it, you don't get it from most outsourcing companies. Now its all in an official document that we hand over as part of our agreement and it lets us point to it and reject any code that doesn't meet the standard.
The bigger the budget ...
... the more scope there is for bloat, unnecessary garbage (like animations that don't contribute to functionality) and general "lets do what looks good instead of what is needed".
NSA Discovers OWASP. Movie at 11.
Top scientists and the NSA have come together and realized that regular application code monkeys can be as dumb as web skiddies.
>If you told the OS in advance the size of the memory, should it not just throw an error if you try?
Depends on the underlying hardware, once you've got an address and try write to it, either the OS must be notified and then validate the write (every single memory write!) or the hardware must have some kind of notification of where you are allowed to write and where you aren't (bit like NX bits but more extensive) and finally you need to establish overwrites that hit valid allocations - accidentally writing to another allocated address space.
>Dynamic Memory Allocation screws up eventually. If you can write the program without using
>Dynamic Memory Allocation then it will run for years without a reboot.
Very true, but that requires allocating all the memory you're going to need for years at program launch and that means other programs you might want to run in the intervening years won't have that memory available. So your shell, grep, maybe the odd ftp or ssh session, perhaps you'll want to run an image processing job, they aren't going to happen because all the memory was allocated in 1995 by the web server...
Also, C of course generally (and Pascal doesn't have to, and if you do they're slower) doesn't have bounds checked arrays so even your statically allocated memory could be overrun.
>WEB programming errors
>Not real programming errors
Like buffer overflows, not validating input and output, generous error messages and race conditions?
It doesn't matter how good your programmers are.
If your project management are idiots, you don't stand a chance.
"Most programmers still program for the 'Sunny Day' case"
That's because most programmers don't have an aptitude for it and don't actually enjoy it. They simply plod along being barely adequate, waiting for their pay check. That's where the errors come from.
Those who write programs because they enjoy the creativity, the logic and the aesthetics [of a well-written program] are far more useful. They enjoy their jobs, produce better code and just see the pay check as a bonus, instead of a goal. Unfortunately, they necessarily take longer over it , which short-sighted employers see as a disadvantage, until the errors start to pile up.
my uni course
taught me COBOL and dBase, drinking and basketball. I think a refresher is in order
And those languages are written in C.
The "unsafe" C is only unsafe if you are slack in your programming. If you are careful in your programming, you are much better off than using a "managed" system where if something still goes wrong, you have NO CLUE how to fix it because "the language knows better than you".
@The number one programming error
I'm sorry AC. - Blaming a low budget for your poor code is not on.
If the project is release ready then the code must be free of bugs (the major ones like these 25) otherwise it doesn't get out of Alpha/Beta.
If it will cost more than management are willing to spend then they can either open source the project & hope someone will fix it for free or leave it in beta & risk it in a production environment.
Release software should not have these errors regardless of budget. End of.
@ User Error
Perhaps clicking on the right link (http://www.sans.org/top25errors/) would be more beneficial ;)
When would you like it?
When I was coding SMS messaging systems for a premium rate co some years ago we'd always be badgered by the Sales Director saying 'is new feature xxx ready yet? Remember we sold this idea to a customer and told them they could have it online in a week!'
To which I'd answer 'Well, you can have it now, if you like. Or you can have it working...'
He always wanted it now....
@drunk.smile : The number one programming error
>Release software should not have these errors regardless of budget. End of.
The decision on whether or not to release something isn't generally for the programmers though. It's a higher level business decision.
Bodging something together in half a day is always going to be flakier than if you had a few weeks to do a proper design and testing of it. A few weeks costs money.
>Unfortunately designing robust applications is time consuming and expensive, two things that >management don't want to hear.
As someone in the middle tier, I'd disagree - management often hear, and managers often know what best practice is, but at the end of the day, companies have these things called budgets, which tend to be set by how much you can sell (or how much money support services bring in if you're open source).
Unfortunately, the reality is that customers have rewarded cheap shonky systems and code over well engineered ones. That is how Windows became dominant over the Unix desktop. Every time you bid for work, you're being played off against a cheaper competitor, which forces you to cut costs to compete. Both of you can even be ISO certified, seeing as the certification only covers repeatable process, not actual code quality.
(The corollary of this is that at the real cost of doing the job properly, a lot of IT projects would not go ahead, or at least not until the components were cheaper - i.e. you can now assemble a web store using off-the-shelf components and services).
I guess certification could be a good starting point - i.e. having external code reviewers come in and review code for quality, in the same way that other parts of businesses are audited. That would help produce a level playing field, in that customers would then know if a supplier was grade A, B, C, etc. Right now, the only real feedback they get is the number of bugs they find after they've made their business dependent on the system.
The other thing that strikes me is how many of these errors have occurred due to the shift back from tools that made typed data entry fields easy to browser based apps where everything is a string. Again, that's a customer driven technology choice - I can understand that it solved a lot of deployment problems for firms . . . but now it turns out that security problems are the new deployment problems.
@CWE-259 - Adrian
Hard CODED password. Don't put your password in the CODE where it can't be changed; that's what the phrase 'hard coded' means.
Move your passwords into your CML configuration or properties files and they are no longer hard coded, you can change them and then restart your server. If you're using Java (as I do) then you put that property file in a very, very private directory on the server and simply include it on the classpath. This means that the content of the file cannot be inadvertantly served up due to some programming or runtime error. In addition, whenever I work with passwords in code, I try to ensure that the 'retention period' is as short as possible, and that the password is only accessible from parameters or method scope properties - that are automatically removed when the method completes.
And why did The Register leave "the list" out of the article?
@ the Anti-MS brigade
Prehaps you should take a look at the number of updates released for OSX and Ubuntu before you start pointing the finger solely at Microsoft.
Over 100 updates between November and today on my Ubuntu VM. Yet programming errors only happen to closed source...?
Yes, very good idea. Personally I create a 100k byte array once, right at the start, and put all my variables in there. Somewhere.
We have a copy of "The Pragmatic Programmer" in our bookshelf here at work - much more useful than these 25 items. We've got a copy of Joel On Software as well. Everyone should have read through that.
But this 25 points? Shit throughout.
These 25 points start off crap -"Improper Input Validation" - i mean what the hell does that mean? Does that mean "Validate according to the functional specification of the user's requirement"? Does that mean "Validate all data that could be entered into your program over the next 25 years?" Does that mean "Use your telepathic powers to translate the phrase in the requirements "Enter User Name" into 50 pages of detailed technical specification then code it."?
I see no way that someone could sign a piece of paper saying that their software complied to this point. Its so fucking vague you might as well just have the one item: "Write the program right in the first fucking place."
Fucking pissants. Next we'll get "Top 25 spelling errors" and we'll have to burn any book that commits them.
@Norman Andrews & @ Geoff Spick
Norman - Conversely, if your programmers are rubbish then the best Project Managers won't make much difference either.
Development is a team effort and needs great analysts, developers, testers, project managers - oh, and a good client, to deliver a successful product.
Geoff - which bit needs a refresher?? The coding or the drinking?!
> Like buffer overflows, not validating input and output, generous error messages and race conditions?
Don't get a lot of those on AS/400 RPG-ILE
'not validating input' is not a programming error, it's a systems requirements omission