Software Development

25 most dangerous programming errors

Computer security organizations the world over have come together to produce a list of the 25 "most dangerous" programming errors. If you do any programming, it's time to sit up and take notice.

I've interrupted my planned schedule of upcoming articles to bring you something I think should be brought to the attention of any programmers in my audience sooner, rather than later.

The SANS Institute has explanations of the 25 most dangerous programming errors, according to security experts from all over the world working for a number of different computer security organizations. As pointed out early in the article:

The impact of these errors is far reaching. Just two of them led to more than 1.5 million web site security breaches during 2008 - and those breaches cascaded onto the computers of people who visited those web sites, turning their computers into zombies.

The 25 errors, organized by type, are:

Insecure Interaction Between Components

  • Improper Input Validation
  • Improper Encoding or Escaping of Output
  • Failure to Preserve SQL Query Structure
  • Failure to Preserve Web Page Structure
  • Failure to Preserve OS Command Structure
  • Cleartext Transmission of Sensitive Information
  • Cross-Site Request Forgery
  • Race Condition
  • Error Message Information Leak

Risky Resource Management

  • Failure to Constrain Operations within the Bounds of a Memory Buffer
  • External Control of Critical State Data
  • External Control of File Name or Path
  • Untrusted Search Path
  • Failure to Control Generation of Code
  • Download of Code Without Integrity Check
  • Improper Resource Shutdown or Release
  • Improper Initialization
  • Incorrect Calculation

Porous Defenses

  • Improper Access Control
  • Use of a Broken or Risky Cryptographic Algorithm
  • Hard-Coded Password
  • Insecure Permission Assignment for Critical Resource
  • Use of Insufficiently Random Values
  • Execution with Unnecessary Privileges
  • Client-Side Enforcement of Server-Side Security

More information about the list as a whole, and about each of the individual vulnerabilities, can be found at the CWE/SANS Top 25 Most Dangerous Programming Errors page. This is, in short, a syllabus for one of several secure programming courses that should be taught to everybody looking to pursue a career as a programmer. If you're a software developer, you should start learning about these vulnerability types, and how to avoid them, without delay.

Special thanks to Sterling Camden, of TechRepublic's own IT Consulting Weblog, for inspiring me to write this article.

About

Chad Perrin is an IT consultant, developer, and freelance professional writer. He holds both Microsoft and CompTIA certifications and is a graduate of two IT industry trade schools.

15 comments
Justin James
Justin James

I caught this one yesterday, and planned to mention it, thanks for beating me to the punch. :) I spoke to Microsoft's Chief Security Officer, my post on that should be coming out next week. This is something we talked a lot about. It is really sad that so many Web sites and applications still have things like SQL injection attacks, sepite the fact that in most languages, it is now harder to program in a way that allows them than in a safer way! J.Ja

admin
admin

Improper input validation is the number one listed error? There are limits to how much validation should be applied, though. Excess paranoia creates inconvenience for some users, when it comes to input validation. Take your email address validation routine for example. I am unable to use my standard email address to register here at TechRepublic. administrator@..... is detected as an invalid entry, while admin@..... seems to work just fine. You'd think a tech site wouldn't be so picky....

yeoman
yeoman

Thank you, Chad. As a dinosaur era programmer I groan when I see young programmers making the same mistakes we made 20, 30, 40 years ago. "Buffer overflow". Zune's leap year problem. etc., etc. Why do we love to reinvent the same old mistakes (painted, of course, in new colours)? This should be compulsory reading, and your programmer's licence taken away if you commit any of these crimes.

Sterling chip Camden
Sterling chip Camden

... that have many manifestations in the wild. I can't get over how many buffer overrun vulnerabilities I still encounter. You'd think Microsoft would have worn that one out by now. I hope you'll expand on some of these in the future. I should mention that Stu Savory pointed me to the original article.

seanferd
seanferd

I'm given to understand a lot of SQL injection vulnerabilities are due to improper configuration of the databases. Some amount of those config errors seem to be due to bad default settings, particularly for a public-facing database, that are never looked at and reset. I wonder what what percentage of vulnerabilities are due to configuration error rather than a coding error on the part of those vending a database solution or those creating a database.

Tony Hopkinson
Tony Hopkinson

generic email address validation routine, where some calls to it might justify that level of paranoia. Improper code re-use should have been on the list, maybe.....

apotheon
apotheon

I (Chad Perrin), personally, am not in charge of any of the site development at TechRepublic.

hlhowell
hlhowell

There are so many possibilities of errors, compounded by the re-use of code that is "good", especially C++ with its objects and obscured code in the background. To me one of the top errors is the propagation of the myth of "self documenting code". Its code, not language, and even if it were language, if sufficiently advanced, code needs explanation for someone following getting their first (or first few) exposures to the advanced algorithm, and over time, the "out moded" algorithm no longer commonly used. Any sufficiently significant bit of code contains errors (debugging, remember). And older code that was robust at the time may no longer be so due to changes in system structure or implementation. A lot depends on the language and language implementation, in addition to the past errors. I read a lot about programming, and while buffer overflow, date manipulation, stack overflows, and stack underflows all pose their risks, some of the methods to exploit those risks on older systems won't work with new compilers and/or libraries. Also, today there are literally hundreds of "20 pound" books on programming, but few of them emphasize the "why" of doing things in a certain way. Either the author doesn't know or simply doesn't want to commit another 20 lbs of paper to explanation. Regardless the reason, missing the why means that when a new programmer discovers another perhaps faster way, would he be remiss in using it? No one knows what they don't know. Regards, Les H

dinosaur_z
dinosaur_z

The reason so many legacy mainframes are still running the core of most of the Fortune 500's business, is because a lot of these problems were solved 20, 30, 40 years ago. (I admit Y2K uncovered a bunch of these).

Sterling chip Camden
Sterling chip Camden

Any field that a user can enter that is used within a query has to be filtered for escapes. No amount of configuration will prevent those from doing harm, unless your framework somehow completely prevents you from constructing queries with string concatenation.

Tony Hopkinson
Tony Hopkinson

and generated it wrong. :( As the kid who ate basket of unripe fruit said 'Sh1t happens'

Justin James
Justin James

Something I've been very, very leary of, particularly in this world of SOA, n-tier architecture, Web services, etc. is data that "my application generated". There are, unfortunately, no guarantees that your application generated it. :( J.Ja

Sterling chip Camden
Sterling chip Camden

If you didn't generate it, don't trust it. And sometimes you can't even trust the data you generate.

seanferd
seanferd

I wasn't thinking about that at the moment. Probably a much bigger deal than config.

Justin James
Justin James

Yeah, people *still* are not not nearly paranoid enough about input! A few years ago, I was writing a quickie utility to do some searching/filtering on some Web server logs. I discovered along the way, that someone out there was setting their user agent string to contain a JavaScript redirect to their page. This was clearly an attempt to subvert Webmasters using Web-based log analysis tools. It taught me a real lesson: just because someone didn't manually type it, and the data is *supposed* to have been automatically generated, does not mean that it is safe! J.Ja

Editor's Picks