Top 25 Programming list Thoughts and Notes.

Welcome everyone from East Carolina and OWASP - NC! I am putting together something for a joint meeting between OWASP and ISSA in Raleigh that revolves around the recent SANS Top 25 Programming errors that came out in early January 2009 : http://www.sans.org/top25errors/.

SANS worked with the MITRE organization whose Common Weakness Enumeration (CWE) details over 700 additional programming and architecture errors and recommendations on how to avoid and mitigate them.

The main goal of 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."

Here are some notes:

1. Programming errors in this list relate mostly to security

2. Could also be renamed to Top 25 Web Programming errors since many of the items on the list are not applicable to non web programmers. However at least all but 2 of the 25 relates to any software if not all of them.

• Web applications are starting to dominate mainstream computing.


• Web applications are accessible from anywhere in the world whereas desktop applications mostly require physical presence to interact.

3. How does this list compare, duplicate, enhance other similar type lists?

• Michael Howard’s “19 Deadly sins of software security” - 19 Deadly Sins of Software Security (Security One-off)
  


• Steve McConnell’s – Classic Development Process mistakes - http://www.stevemcconnell.com/rdenum.htm and accompanying case study - http://www.stevemcconnell.com/rdmistak.htm
  

4. Old software proverb: “The first 90 % of the work takes 10% of the time and the other 10% takes 90% of the time”.

• Security sadly is not at the forefront of development cycle and therefore is relegated to the last 10% of the time. Therefore, a lot of the times, security is not gotten around to implement.


• Succeeding in software is more of getting EVERYTHING right and less of not doing a few things wrong. One bug especially those found by the customer can fail a project.


• You can help your project success along the way by simply recognizing what errors you can make and that is where lists like these can help your project success rate.

5. Can these 25 items be reduced to 12?

• Improper Input Validation ... path , user input, download without integrity check
  
• Untrusted Source ... similar data validation, but checks on more "human" level, untrusted seach path
  
• Failure to Fullfil Constrains ... buffer overflow


• Improper Initialization or Relase of Resource .... unitialized data,


• Failure to Preserve Proper Structure ... encoding or escaping of textual data, SQL, html, control generation of code


• Client-Side Enforcement of Server Side Security


• Revealing Potentially Misused Infromation .... os calls in text file, cleartext transmission of sensitive data - hard coded passwords, error message information leak


• Giving Privilegies to Access Potentially Misused Information (& their executing)... data critical to keep valid state of program, external file names,


• Race Condition


• Incorrect Calculation


• Insufficent Random Values


• Use of Weak Cryptographic Algorightms

6. Or maybe the list can be boiled down into 3 categories?:

• Insecure Interaction Between Components (9 errors)


• Risky Resource Management (9 errors)


• Porous Defenses (7 errors)

7. A good idea for a hands on project would be to build a website that demonstrates a use and example for each error in the list for reference.

8. What is a “Race condition”? – a race condition is merely a synch issue where properly timed inputs and program execution can lead to unexpected state of the program.

9. Can a tool like Codepro be modified to check against this list? It would be much better to have a best practice of “I ran my code against this tool and it came back clean” rather than nothing at all.

10.Amazing thing is that people are noticing and reacting to this list where these issues have been around and noted for awhile.

11.Will some kind of regulations or government action result in this list? Think Sarbanes Oxley.

12.A lot of the items on the list are programming “errors” per se. They could be considered exploitable loopholes. The fact is that software will work fine in a world without hackers

13.Website with 25 errors categorized: http://naveedslote.blogspot.com/2009/01/top-25-most-dangerous-programming_13.html

More to come later - Fred