I recently found a document, stating it contains the most dangerous programming errors. The layout of this article is very … let’s say technical so I was about to close this one because it’s not very much fun to read it. But the first few lines took me in and I read the whole thing. I wonder if it has the same impact on you:
Today in Washington, DC, experts from more than 30 US and international cyber security organizations jointly released the consensus list of the 25 most dangerous programming errors that lead to security bugs and that enable cyber espionage and cyber crime. Shockingly, most of these errors are not well understood by programmers; their avoidance is not widely taught by computer science programs; and their presence is frequently not tested by organizations developing software for sale.
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.
If you are a programmer and have the urge to make a perfect application you have to admit that this excerpt teases you. You want to know if you are better than these guys who messed up epically.
Let’s see, which errors could you have made?
Well, of course, we have the three regulars SQL Injection, Cross Site Scripting and OS Command Injection. These three are still very common although there are a various number of best practises available to prevent them.
So if you have one of these in your application you would be in good company but you will have ignored some basic rules like “Don’t trust user input!“.
Ok, moving on. What else is there password- and cryptographie-related errors are often a source of fun or blank horror. There are the ones where you should have watched the newspages like “Use of a Broken or Risky Cryptographic Algorithm“, things you should know to avoid like “Hard-Coded Password” and “Client-Side Enforcement of Server-Side Security” and things you could have tested properly like “Execution with Unnecessary Privileges” or “Improper Access Control (Authorization)“.
I know, i know – you would have done (or not done) all these things if you just had enough time for it. Well, I know the clients and I know that they don’t have the feeling for tasks like “testing”. They can’t possibly understand why such a task is taking so much time. But as reality shows it is wise to invest a big chunk of your development time into it.
So it is your tasks to make sure the client (or your boss for that matter) understands the need for testing and making “unnecessarry” code for checking user input etc. It is in both his/her interest and yours to produce an application holding up against real world scenarios and bored high school kids.