The 25 Most Dangerous Programming Errors

Hugh Pickens writes "The Register reports that experts from some 30 organizations worldwide have compiled 2010's list of the 25 most dangerous programming errors along with a novel way to prevent them: by drafting contracts that hold developers responsible when bugs creep into applications. The 25 flaws are the cause of almost every major cyber attack in recent history, including the ones that recently struck Google and 33 other large companies, as well as breaches suffered by military systems and millions of small business and home users. The top 25 entries are prioritized using inputs from over 20 different organizations, who evaluated each weakness based on prevalence and importance. Interestingly enough the classic buffer overflow ranked 3rd in the list while Cross-site Scripting and SQL Injection are considered the 1-2 punch of security weaknesses in 2010. Security experts say business customers have the means to foster safer products by demanding that vendors follow common-sense safety measures such as verifying that all team members successfully clear a background investigation and be trained in secure programming techniques. 'As a customer, you have the power to influence vendors to provide more secure products by letting them know that security is important to you,' the introduction to the list states and includes a draft contract with the terms customers should request to enable buyers of custom software to make code writers responsible for checking the code and for fixing security flaws before software is delivered."

Comments

Re:Yeah, right.

[0x000000]

Holding programmers accountable for their coding errors should happen inside of the corporation as they are working on the project. I don't remember which company had this, but if a developer broke the build it failed to pass a test a lava lamp at their cubicle would turn on, and until the developer fixed the build the lava lamp would stay on, which generally meant you had a certain amount of time to fix the issue before it would actually start bubbling. This way there is an incentive not to break the build, and a bit of competition between the various programmers to have the least amount of bugs or build breakages.

Having programmers imagine every way that their program may be attacked is impossible. There will always be new attacks that take advantage of that one that the programmer had not thought of. Just like the security systems that are in place at airports around the world. If the good guys could come up with every single scenario that an attacker could take airports would be much safer, as every single scenario had already been thought about.

I agree with you, don't put all the blame on me as a programmer.

Oh, if I had mod points, you sir would have them!

Just Show Me the List!!

[QuantumG]

So much shit. So much commentary. Just gimme the list? Here it is:

1. Failure to Preserve Web Page Structure ('Cross-site Scripting')
2. Improper Sanitization of Special Elements used in an SQL Command ('SQL Injection')
3. Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
4. Cross-Site Request Forgery (CSRF)
5. Improper Access Control (Authorization)
6. Reliance on Untrusted Inputs in a Security Decision
7. Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
8. Unrestricted Upload of File with Dangerous Type
9. Improper Sanitization of Special Elements used in an OS Command ('OS Command Injection')
10. Missing Encryption of Sensitive Data
11. Use of Hard-coded Credentials
12. Buffer Access with Incorrect Length Value
13. Improper Control of Filename for Include/Require Statement in PHP Program ('PHP File Inclusion')
14. Improper Validation of Array Index
15. Improper Check for Unusual or Exceptional Conditions
16. Information Exposure Through an Error Message
17. Integer Overflow or Wraparound
18. Incorrect Calculation of Buffer Size
19. Missing Authentication for Critical Function
20. Download of Code Without Integrity Check
21. Incorrect Permission Assignment for Critical Resource
22. Allocation of Resources Without Limits or Throttling
23. URL Redirection to Untrusted Site ('Open Redirect')
24. Use of a Broken or Risky Cryptographic Algorithm
25. Race Condition