Secure programming is a huge issue and it’s the lack of it that causes all the problems we have with vulnerabilities and the exploits associated with them. If everywhere developers followed secure programming practices we wouldn’t have buffer overflow issues or unsanitized parameters leading to SQL Injection.
The NSA (National Security Agency), working with MITRE, SANS, and dozens of industry experts from many other organizations, has published a valuable list of the top 25 most dangerous programming errors.
I hope more companies take notice of this and train their developers properly, rather than squeezing maximum efficiency and LOC out of them – teach them to code properly and securely too!
The 2009 CWE/SANS Top 25 Most Dangerous Programming Errors is a list of the most significant programming errors that can lead to serious software vulnerabilities. They occur frequently, are often easy to find, and easy to exploit. They are dangerous because they will frequently allow attackers to completely take over the software, steal data, or prevent the software from working at all.
The list is the result of collaboration between the SANS Institute, MITRE, and many top software security experts in the US and Europe. It leverages experiences in the development of the SANS Top 20 attack vectors (http://www.sans.org/top20/) and MITRE’s Common Weakness Enumeration (CWE) (http://cwe.mitre.org/). MITRE maintains the CWE web site, with the support of the US Department of Homeland Security’s National Cyber Security Division, presenting detailed descriptions of the top 25 programming errors along with authoritative guidance for mitigating and avoiding them. The CWE site also contains data on more than 700 additional programming errors, design errors, and architecture errors that can lead to exploitable vulnerabilities.
The main goal for the Top 25 list is to stop vulnerabilities at the source by educating programmers on how to eliminate all-too-common mistakes before software is even shipped. The list will be a tool for education and awareness that will help programmers to prevent the kinds of vulnerabilities that plague the software industry. Software consumers could use the same list to help them to ask for more secure software. Finally, software managers and CIOs can use the Top 25 list as a measuring stick of progress in their efforts to secure their software.
It’s good to see such a comprehensive project being published on the Internet for free, the aim behind this is just to make more secure code. There’s no hidden commercial agenda or aim to sell services or software packages on the back of this.
If you know anyone in the development field I suggest you forward the list to them and tell them to send it to anyone involved in software development (same goes for commercial and non-commercial projects).
There’s no excuse for insecure code!
The Top 25 list was developed at the end of 2008. Approximately 40 software security experts provided feedback, including software developers, scanning tool vendors, security consultants, government representatives, and university professors. Representation was international. Several intermediate versions were created and resubmitted to the reviewers before the list was finalized. More details are provided in the Top 25 Process page
To help characterize and prioritize entries on the Top 25, a threat model was developed that identifies an attacker who has solid technical skills and is determined enough to invest some time into attacking an organization. More details are provided in Appendix B.
Weaknesses in the Top 25 were selected using two primary criteria:
- Weakness Prevalence: how often the weakness appears in software that was not developed with security integrated into the software development life cycle (SDLC).
- Consequences: the typical consequences of exploiting a weakness if it is present, such as unexpected code execution, data loss, or denial of service.
Prevalence was determined based on estimates from multiple contributors to the Top 25 list, since appropriate statistics are not readily available.
It’s assumed the attacker has some strong technical skills, is intent on data theft or theft of resources and is willing to spend an estimate 20 hours per software module. This is not realistic and in a blackhat situation you could bet they would be willing to spend much more than 20 hours.
Even if you aren’t directly involved in software development, it’s an interesting study and for people doing pen-tests/code audits and web application assessments it’s a goldmine of information to research further on.
If you get your techniques down on each of these 25 vulnerabilities you should be able to pretty much break anything open.