{"id":683,"date":"2009-02-28T10:20:23","date_gmt":"2009-02-28T15:20:23","guid":{"rendered":"http:\/\/www.coresecuritypatterns.com\/blogs\/?p=683"},"modified":"2020-08-08T03:46:24","modified_gmt":"2020-08-08T03:46:24","slug":"top-25-most-dangerous-programming-errors","status":"publish","type":"post","link":"https:\/\/websecuritypatterns.com\/blogs\/2009\/02\/28\/top-25-most-dangerous-programming-errors\/","title":{"rendered":"Top 25 Most Dangerous Programming Errors"},"content":{"rendered":"

\"\"<\/a>Few weeks ago, US Dept. of Homeland security (National Cyber Security Division) in collaboration with SANS Institute\/MITRE teams worked together and released a list of 25 dangerous programming errors as common security flaws, which opens doors for easy exploitation. My first look at this list, I thought it is a old wine in a new bottle as the document sounded a bit more high-level without applied countermeasures and reality checks. The list did go extra mile highlighting the mitigation strategies and countermeasures. For those follow OWASP Top 10 (Most compelling)<\/a>, the CWE Top 25 list is a bit more augmented to include the weakest links of security in target resource and client\/server environment. At the outset, the Top 25 list certainly helps our budding developers on understanding the potential weaknesses and vulnerabilities arise due to poor coding practices.<\/p>\n

Here is the list of SANS\/MITRE’s Top 25 Most Dangerous Programming Errors<\/a>, in no particular order…<\/p>\n

1. Improper Input Validation
\n2. Improper Encoding or Escaping of Output
\n3. Failure to Preserve SQL Query Structure (SQL Injection)
\n4. Failure to Preserve Web Page Structure (Cross-site Scripting)
\n5. Failure to Preserve OS Command Structure (OS Command Injection)
\n6. Cleartext Transmission of Sensitive Information
\n7. Cross-Site Request Forgery (CSRF)
\n8. Race Condition
\n9. Error Message Information Leak
\n10. Failure to Constrain Operations within the Bounds of a Memory Buffer
\n11. External Control of Critical State Data
\n12. External Control of File Name or Path
\n13. Untrusted Search Path
\n14. Failure to Control Generation of Code (Code Injection)
\n15. Download of Code Without Integrity Check
\n16. Improper Resource Shutdown or Release
\n17. Improper Initialization
\n18. Incorrect Calculation
\n19. Improper Access Control (Authorization)
\n20. Use of a Broken or Risky Cryptographic Algorithm
\n21. Hard-Coded Password
\n22. Insecure Permission Assignment for Critical Resource
\n23. Use of Insufficiently Random Values
\n24. Execution with Unnecessary Privileges
\n25. Client-Side Enforcement of Server-Side Security<\/p>\n

\"\"<\/a>It is an impressive list…that leaves me with some hard questions, when it comes to how to implement the required safeguards and countermeasures – Yes, the Devil is always in the Implementation details<\/strong><\/em> as there is No Magic Silver Bullet<\/strong><\/em> and it becomes critical to the developer to choose, adopt and practice the appropriate “Security Design and Best Practices” that identifies the safeguard and helps proactively defend against those known errors.  As a developer – in the first place you must understand – how to bake-in security in your application choosing the relevant “Security patterns, Best practices, Pitfalls and Reality checks”…for your target application development and deployment environment.<\/p>\n

This gives me another opportunity for my shameless book promotion (is here)<\/a>, especially for those who is interested in knowing the security patterns and require implementation guidance for securing Java\/J2EE\/Web Services environments.<\/p>\n","protected":false},"excerpt":{"rendered":"

Few weeks ago, US Dept. of Homeland security (National Cyber Security Division) in collaboration with SANS Institute\/MITRE teams worked together and released a list of 25 dangerous programming errors as common security flaws, which opens doors for easy exploitation. My first look at this list, I thought it is a old wine in a new bottle as the document sounded… Read more »<\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[20,21,6,9],"tags":[36,37,40,52,53,62,76],"class_list":["post-683","post","type-post","status-publish","format-standard","hentry","category-java-ee","category-java-security","category-main","category-security","tag-inputvalidation","tag-j2ee","tag-java-security","tag-owasp","tag-patterns","tag-security","tag-xss"],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/websecuritypatterns.com\/blogs\/wp-json\/wp\/v2\/posts\/683","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/websecuritypatterns.com\/blogs\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/websecuritypatterns.com\/blogs\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/websecuritypatterns.com\/blogs\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/websecuritypatterns.com\/blogs\/wp-json\/wp\/v2\/comments?post=683"}],"version-history":[{"count":1,"href":"https:\/\/websecuritypatterns.com\/blogs\/wp-json\/wp\/v2\/posts\/683\/revisions"}],"predecessor-version":[{"id":2827,"href":"https:\/\/websecuritypatterns.com\/blogs\/wp-json\/wp\/v2\/posts\/683\/revisions\/2827"}],"wp:attachment":[{"href":"https:\/\/websecuritypatterns.com\/blogs\/wp-json\/wp\/v2\/media?parent=683"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/websecuritypatterns.com\/blogs\/wp-json\/wp\/v2\/categories?post=683"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/websecuritypatterns.com\/blogs\/wp-json\/wp\/v2\/tags?post=683"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}