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

Resources» Rationale for TR 24731 Extensions to the C Library Part I: Bounds-checking interfaces.http://www.open-std.org/JTC1/SC22/WG14/www+/docs/n1173.pdf.» See guideline: INT05-C. Do not use input functions to convert character data if they cannot handle allpossible inputs [CERT C Secure Coding Standard 2010].» See guideline: FIO12-C. Prefer setvbuf() to setbuf() [CERT C Secure Coding Standard 2010].» See guideline: FIO07-C. Prefer fseek() to rewind() [CERT C Secure Coding Standard 2010].Do Not Use Filenames in an Improper MannerMost programs deal with files (e.g., opening, reading, creating a file). Naturally, dealing with files in an improper way can lead toserious security vulnerabilities such as race conditions, unauthorized disclosure or modification of the file’s contents, and so on.One way to cause race conditions is by referring to a file by its name more than once in the same program. Don’t check to see ifthe file exists before opening it; instead, attempt to open files directly, then react to errors.Once a file is opened, it should be given a file handle and referred to only by that file handle for the rest of the program. Referringto a file by its name more than once in a program gives the attacker a chance to alter the file between references and trick theprogram into trusting information that should not be trusted [Graff and van Wyk 2003].Referring to a file with a relative filename can cause unauthorized disclosure or modification of a file’s contents. Filenamesshould be fully qualified, meaning it starts with a device name such as “C:\Documents and Settings\Desktop\text.txt.” Using arelative filename gives an attacker an opportunity to change the working directory and access files that the attacker should nothave access to [Graff and van Wyk 2003].Resources» Secure Coding Principles & Practices. Graff, Mark G., and Kenneth R. Van Wyk. Sebastopol, CA:O’Reily. June 2003.Questions to Ask Software DevelopersThe following are questions managers could ask their development teams or acquirers of software services could ask theirsuppliers. These questions highlight the major coding considerations for assuring secure applications. Intended to raiseawareness of the content of this Guide, they are not a complete set of questions. A more comprehensive set of questions can befound in the Pocket Guides for “Software Assurance in Acquisition and Contract Language” and “Software Supply Chain RiskManagement & Due-Diligence.”» What input and output protection mechanisms are implemented within the application?» What measures are taken to ensure that users only have access to that which they are allowed to view?» How are user passwords stored?» How are connection strings stored?» What cryptographic functions are implemented within the application, and what considerations went into selecting this overothers?» What tasks are included in each phase of the software development life cycle to identify and address security concerns?» Who is involved in the code review process and how is it reviewed?» If any, which third-party libraries are used, and how is it checked to ensure it does not contain malicious code orvulnerabilities?» What type of auditing is done to keep track of changes made to database records?Software Assurance Pocket Guide Series:Development Volume VI – Version 2.0, , May 18, 2012Secure Coding25