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

thrown during testing or operation. Exception handling should be proactively designed to the greatest extent possible, throughcareful examination of code constraints as they occur during the concept and implementation phases of the life cycle.The developer should list all predictable faults (exceptions and errors) that could occur during software execution and define howthe software will handle each of them. In addition, the developer ought to address how the software will behave if confronted withan unanticipated fault or error. In some cases, potential faults may be preempted in the design phase, particularly if the softwarehas been subjected to sufficiently comprehensive threat modeling. In others, developers could preempt additional faults duringpseudo-coding by cautiously examining the logical relationships between software objects and developing “pseudo” exceptionhandling routines to manage these faults.Table 1, below, lists several common software errors and suggests remediation methods for those errors at the design andimplementation levels.Table 1 -- Software Errors and Suggested Remediation MethodsExpected ProblemHow Software Should Handle the ProblemInput contains anomalous content.The execution environment differs significantly from theenvironment for which the software was designed.There are errors in the results returned by calledfunctions.The software contains vulnerabilities that were notmitigated or detected before the software was deployed.IMPLEMENTATION: Restrict the possible inputwhenever possible. Also validate all input.DESIGN: Recognize all explicit and implicitassumptions COTS and OSS components have abouttheir environment. Design to mitigate vulnerabilitiescreated by mismatch between componentassumptions and actual environment. Design also tominimize external exposure ofcomponent/environment interfaces.DESIGN: Design for resilience.IMPLEMENTATION: Anticipate all likely errors andexceptions, and implement error and exceptionhandling to explicitly address those errors/exceptions.DESIGN: Include measures that isolate un-trusted,suspicious, and compromised components, and thatconstrain and recover from damage.IMPLEMENTATION: Measures that reduce exposureof un-trusted and vulnerable components to externallysourced attack patterns (e.g., using wrappers, inputfilters, etc.).The exception-handling block should log when and why an exception was thrown; auditors can review this log later. Theexception-handling block should also be written to include messaging code that will automatically send an alert to the systemadministrator when an exception requires human intervention.Above all, the software should never throw exceptions that allow it to crash, dump core memory, or expose its caches, temporaryfiles, and other transient data exposed. To find ways to prevent data being exposed from error messages, see the mitigations forCWE 209 “Error Message Information Leak” in the Key Practices for Mitigating the Most Egregious Exploitable SoftwareWeaknesses pocket guide.Practices for implementing effective error and exception handling are described below.Software Assurance Pocket Guide Series:Development Volume VI – Version 2.0, , May 18, 2012Secure Coding22