Secure Coding SwA Pocket Guide - Build Security In - US-CERT

o Filter and Sanitize Output and Callouts .............................. 16o Minimize Retention of State Information ............................ 16o Do Not Allow Unauthorized Privilege Escalation ................ 17o Leverage Security through Obscurity Only as anAdditional Deterrence Measure ................................. 17o Use Strongly Typed Parameterized Queries ...................... 17o Incorporate Interprocess Authentication ............................. 17o Leverage Attack Patterns ................................................... 18o Implement Encryption and Hashing ................................... 18o Protect Sensitive Information ............................................. 19o Disable Debugging Tools Prior to Deployment .................. 19» Secure Memory and Cache Management ................................ 20o Limit Persistent Memory Caching ....................................... 20o Allocate Memory and Other Resources Carefully .............. 21» Secure Error and Exception Handling ....................................... 21o Integrate Anomaly Awareness ........................................... 23o Incorporate Runtime Error Checking and SafetyEnforcement .............................................................. 23o Use Event Monitors ............................................................ 23o Fail Securely ....................................................................... 23» What to Avoid ............................................................................ 24o Do Not Use Deprecated or Insecure Functions .................. 24o Do Not Use Filenames in an Improper Manner .................. 25» Questions to Ask Software Developers .................................... 25» Conclusion ................................................................................ 27Preparing to Write Secure CodeBefore writing code, the development team must first determine how they plan to accomplish their assigned task. It is importantto remember that writing secure code needs the support of secure requirements, architecture, and design. To find more on thesetopics, reference “Requirements and Analysis for Secure Software” and “Architecture and Design Considerations for SecureSoftware.” Both of these documents are part of the SwA Pocket Guide Series.Choose a Language with Security in MindThe choice of a programming language is an important factor in software security. In many cases, legacy code, the available skillsets, or customer requirements, including the environment, may restrict programming language options. When evaluating andselecting the programming language(s), you should ask these key security-relevant questions:» Which languages have your programmers used? Programmers are likely to make more errors when developing inlanguages they have little experience using.» Does the language help or inhibit the development of secure code?» What secure coding standards are available for the language (if any)?» What security issues exist in the language? What mitigation strategies exist? How effective are they?Weighing language choices: In many situations, the choice of language can directly affect the system’s security. The mostprominent example is the effect of array bounds checking, which Java provides but C does not. Although most modern Ccompilers support runtime bounds checking, this feature (or lack thereof) has left a legacy of buffer-overflow-based vulnerabilitiesin web servers, operating systems, and applications. Java is without these specific vulnerabilities, but may not be appropriate forSoftware Assurance Pocket Guide Series:Development Volume VI – Version 2.0, , May 18, 2012Secure Coding4