14
Secure Software Coding Operations
In this chapter you will
• Learn how code reviews can improve security
• Learn basic tools used in building software
• Discover how static and dynamic code analysis can improve code
• Examine antitampering mechanisms that can improve integrity
• Explore the use of configuration management with source code and versioning
When coding operations commence, tools and techniques can be used to assist in the assessment of the security level of the code under development. Code can be analyzed either statically or dynamically to find weaknesses and vulnerabilities. Manual code reviews by the development team can provide benefits both to the code and the team. Code quality does not end with development, as the code needs to be delivered and installed both intact and correctly on the target system.
Code Analysis (Static and Dynamic)
Code analysis is a term used to describe the processes to inspect code for weaknesses and vulnerabilities. It can be divided into two forms: static and dynamic. Static analysis involves examination of the code without execution. Dynamic analysis involves the execution of the code as part of the testing. Both static and dynamic analyses are typically done with tools, which are much better at the detailed analysis steps needed for any but the smallest code samples.
Code analysis can be performed at virtually any level of development, from unit level to subsystem to system to complete application. The higher the level, the greater the test space and more complex the analysis. When the analysis is done by teams of humans reading the code, typically at the smaller unit level, it is referred to as code reviews. Code analysis should be done at every level of development, because the sooner that weaknesses and vulnerabilities are discovered, the easier they are to fix. Issues found in design are cheaper to fix than those found in coding, which are cheaper than those found in final testing, and all of these are cheaper than fixing errors once the software has been deployed.
Static
Static code analysis is when the code is examined without being executed. This analysis can be performed on both source and object code bases. The term source code is typically used to designate the high-level language code, although technically, source code is the original code base in any form, from high language to machine code. Static analysis can be performed by humans or tools, with humans limited to the high-level language, while tools can be used against virtually any form of code base.
Static code analysis is frequently performed using automated tools. These tools are given a variety of names, but are commonly called source code analyzers. Sometimes, extra phrases, such as binary scanners or byte code scanners, are used to differentiate the tools. Static tools use a variety of mechanisms to search for weaknesses and vulnerabilities. Automated tools can provide advantages when checking syntax, approved function/library calls, and examining rules and semantics associated with logic and calls. They can catch elements a human could overlook.
Dynamic
Dynamic analysis is performed while the software is executed, either on a target or emulated system. The system is fed specific test inputs designed to produce specific forms of behaviors. Dynamic analysis can be particularly important on systems such as embedded systems, where a high degree of operational autonomy is expected. As a case in point, the failure to perform adequate testing of software on the Ariane rocket program led to the loss of an Ariane V booster during takeoff. Subsequent analysis showed that if proper testing had been performed, the error conditions could have been detected and corrected without the loss of the flight vehicle.
Dynamic analysis requires specialized automation to perform specific testing. There are dynamic test suites designed to monitor operations for programs that have high degrees of parallel functions. There are thread-checking routines to ensure multicore processors and software are managing threads correctly. There are programs designed to detect race conditions and memory addressing errors.
Code/Peer Review
Code reviews are a team-based activity where members of the development team inspect code. The premise behind peer-based code review is simple. Many eyes can discover what one does not see. This concept is not without flaws, however, and humans have limited abilities to parse into multilayer obfuscated code. But herein lies the rub—the objective of most programming efforts is to produce clean, highly legible code that works not only now, but also, when it is updated later, the new developer can understand what is happening, how it works, and how to modify it appropriately. This makes the primary mission of code review to be shared between finding potential weaknesses or vulnerabilities and assisting developers in the production of clean, understandable code.
The process of the review is simple. The author of the code explains to the team, step by step, line by line, how the code works. The rest of the team can look for errors that each has experienced in the past and observe coding style, level of comments, etc. Having to present your code to the team and actually explain how it works leads developers to make cleaner, more defendable code to the group. This then has the benefits of the code being more maintainable in the long run. By explaining how it works, this also helps others on the team understand how it works and provides for backups if a developer leaves the team and someone else is arbitrarily assigned to modify the code.
Code walkthroughs are ideal times for checking for and ensuring mitigation against certain types of errors. Lists of common defects, such as the SANS Top 25 and the OWASP Top 10, can be checked. The list of previous errors experienced by the firm can be checked, for if it happened once, it is best not to repeat those issues. Unauthorized code elements, including Easter eggs and logic bombs, are much harder to include in code if the entire team sees all the code. A partial list of errors and how they can be caught with walkthroughs is shown in Table 14-1.
Table 14-1 Issues for Code Reviews
Another advantage of code reviews is in the development of junior members of the development team. Code walkthroughs can be educational, both to the presenter and to those in attendance. Members of the team automatically become familiar with aspects of a project that they are not directly involved in coding, so if they are ever assigned a maintenance task, the total code base belongs to the entire team, not different pieces to different coders. Treating the review as a team event, with learning and in a nonhostile manner, produces a stronger development team as well.
Build Environment
Creating software in a modern development environment is a multistep process. Once the source code is created, it must still be compiled, linked, tested, packaged (including signing), and distributed. There is typically a tool or set of tools for each of these tasks. Building software involves partially applying these tools with the correct options set to create the correct outputs. Options on elements such as compilers are important, for the options can determine what tests and error checks are performed during the compiling process.
Organizations employing a secure development lifecycle (SDL) process will have clearly defined processes and procedures to ensure the correct tools are used and used with the correct settings. Using these built-in protections can go a long way toward ensuring that the code being produced does not have issues that should have been caught during development.
 | EXAM TIP Compilers can have flag options, such as Microsoft’s /GS compiler switch, which enables stack overflow protection in the form of a cookie to be checked at the end of the function, prior to the use of the return address. Use of these options can enhance code security by eliminating common stack overflow conditions. |
Determining the correct set of tools and settings is not a simple task. Language dependencies and legacy issues make these choices difficult, and yet these are essential steps if one is to fully employ the capabilities of these tools. Microsoft’s SDL guidelines have required settings for compilers, linkers, and code analysis tools. Enabling these options will result in more work earlier in the process, but will reduce the potential for errors later in the development process, where remediation is more time consuming and expensive.
In addition to the actual tools used for building, there is an opportunity to define safe libraries. Approved libraries of cryptographic and other difficult tasks can make function call errors a lesser possibility. Create a library of safe function calls for common problem functions such as buffer overflows, XSS, and injection attacks. Examples of these libraries are the OWASP Enterprise Security API project and the Microsoft Anti-Cross Site Scripting Library for .NET.
Integrated Development Environment (IDE)
Automated tools can be built into the integrated development environment, making it easy for the developer to do both forms of static and dynamic checking automatically. Integrated development environments have come a long way in their quest to improving workflow and developer productivity. The current version of Microsoft’s Visual Studio integrates from requirements to data design to coding and testing, all on a single team-based platform that offers integrated task management, workflow, code analysis, and bug tracking.
A wide array of IDEs exists for different platforms and languages, with varying capabilities. Using automation such as a modern IDE is an essential part of an SDL, for it eliminates a whole range of simple errors and allows tracking of significant metrics. Although using an advanced IDE means a learning curve for the development team, this curve is short compared to the time that is saved with the team using the tool. Each daily build and the number of issues prevented early due to more efficient work results in saved time that would be lost to rework and repair after issues are found, either later in testing or in the field.
Antitampering Techniques
An important factor in ensuring that software is genuine and has not been altered is a method of testing the software integrity. With software being updated across the Web, how can one be sure that the code received is genuine and has not been tampered with? The answer comes from the application of digital signatures to the code, a process known as code signing.
Code signing involves applying a digital signature to code, providing a mechanism where the end user can verify the code integrity. In addition to verifying the integrity of the code, digital signatures provide evidence as to the source of the software. Code signing rests upon the established public key infrastructure. To use code signing, a developer will need a key pair. For this key to be recognized by the end user, it needs to be signed by a recognized certificate authority.
Automatic update services, such as Microsoft’s Windows Update service, use code signing technologies to ensure that updates are only applied if they are proper in content and source. This technology is built into the update application, requiring no specific interaction from the end user to ensure authenticity or integrity of the updates.
| | EXAM TIP Code signing provides a means of authenticating the source and integrity of code. It cannot ensure that code is free of defects or bugs. |
Code signing should be used for all software distribution, and is essential when the code is distributed via the Web. End users should not update or install software without some means of verifying the proof of origin and the integrity of the code being installed. Code signing will not guarantee that the code is defect free; it only demonstrates that the code has not been altered since it was signed and identifies the source of the code.
Steps to Code Signing
1. The code author uses a one-way hash of the code to produce a digest.
2. The digest is encrypted with the signer’s private key.
3. The code and the signed digest are transmitted to end users.
4. The end user produces a digest of the code using the same hash function as the code author.
5. The end user decrypts the signed digest with the signer’s public key.
6. If the two digests match, the code is authenticated and integrity is assured.
Configuration Management: Source Code and Versioning
Development of computer code is not a simple “write it and be done” task. Modern applications take significant time to build all the pieces and assemble a complete functioning product. The individual pieces all go through a series of separate builds or versions. Some programming shops do daily builds slowly, building a stable code base from stable parts. Managing the versions and changes associated with all these individual pieces is referred to as version control. Sometimes referred to as revision control, the objective is to uniquely mark and manage each individually different release. This is typically done with numbers or combinations of numbers and letters, with numbers to the left of the decimal point indicating major releases, and numbers on the right indicating the level of change relative to the major release.
As projects grow in size and complexity, a version control system, capable of tracking all the pieces and enabling complete management, is needed. Suppose you need to go back two minor versions on a config file—which one is it, how do you integrate it into the build stream, and how do you manage the variants? These are all questions asked by the management team and that are handled by the version control system. The version control system can also manage access to source files, locking sections of code so that only one developer can check out and modify pieces of code at a time. This prevents two different developers from overwriting each other’s work in a seamless fashion. This can also be done by allowing multiple edits and then performing a version merge of the changes, although this can create issues if collisions are not properly managed by the development team.
Configuration management and version control operations are highly detailed, with lots of recordkeeping. Management of this level of detail is best done with an automated system that removes human error from the operational loop. The level of detail across the breadth of a development team makes automation the only way in which this can be done in an efficient and effective manner. A wide range of software options are available to a development team to manage this information. Once a specific product is chosen, it can be integrated into the SDL process to make its use a nearly transparent operation from the development team’s perspective.
Chapter Review
In this chapter, you were acquainted with the tools and techniques employed in the actual creation of software. The use of code analyzers, both static and dynamic, to ensure that the pieces of software being constructed is free of weaknesses and vulnerabilities was covered. An examination of the advantages of code walkthroughs was presented, along with a list of typical errors that should be uncovered during such an exercise.
An examination of the build environment, the tools, and processes was presented. Compilers should be properly configured with the specific options associated with the type of program to ensure proper error checking and defensive build elements. Using tools and compilers to do bounds checking and to create stack overflow mitigations provides significant benefit to the overall code resilience. The use of integrated development environments to automate development and manage testing functions was also covered.
Software is built from many smaller pieces, each of which requires tracking and versioning. The advantages of automated version control systems were presented, along with version tracking methodologies. The use of antitampering mechanisms and code signing was presented as a method of extending control from the development team to the operational team upon installation.
Quick Tips
• Code should be inspected during development for weaknesses and vulnerabilities.
• Static code analysis is performed without executing the code.
• Dynamic code analysis involves examining the code under production conditions.
• Code walkthroughs are team events designed to find errors using human-led inspection of source code.
• Software development is a highly automated task, with many tools available to assist developers in efficient production of secure code.
• Integrated development environments provide a wide range of automated functionality designed to make the development team more productive.
• Compilers and tools can be configured to do specific testing of code during the production process, and they need to be integrated into the SDL environment.
• Code can be cryptographically signed to demonstrate both authenticity and integrity.
• The management of the various elements of code, files, and settings requires a configuration management/versioning control system to do this efficiently and effectively.
Questions
To further help you prepare for the CSSLP exam, and to provide you with a feel for your level of preparedness, answer the following questions and then check your answers against the list of correct answers found at the end of the chapter.
1. Code signing cannot provide which of the following to the end user?
A. Proof of integrity of the code
B. Authentication of the source
C. Assurance that the code is free of vulnerabilities
D. Assurance that the code is authentic
2. Verifying that code can perform in a particular manner under production conditions is a task managed by:
A. Static code analysis
B. Dynamic code analysis
C. Production testing
D. Code walkthroughs
3. To ensure that the end user is receiving valid code, which of the following methodologies is employed?
A. Code signing
B. Version control
C. Configuration management
D. Revision control
4. The /GS compiler switch is used to:
A. Manage memory leaks
B. Prevent buffer overflows
C. Prevent XSS attacks
D. Control for stack overflows through the use of a cookie
5. Code walkthroughs are effective for checking for all of the following except?
A. Deprecated library calls
B. Stack pointer overflows
C. Nonapproved cryptographic functions
D. Logic bombs
6. At what level should code analysis be performed?
A. Unit level
B. Subsystem level
C. System level
D. At all levels
7. Static analysis can be used to check for:
A. Approved function/library calls, examining rules and semantics associated with logic, and thread performance management
B. Syntax, approved function/library calls, and race conditions
C. Syntax, approved function/library calls, and memory management
D. Syntax, approved function/library calls, and examining rules and semantics associated with logic and calls
8. Automated testing has the following advantages over manual code review except:
A. Detection of unsafe or deprecated function calls
B. Identification of obfuscated routines
C. Speed of analysis
D. Integration into the IDE
9. Compiler options should be:
A. Not relied upon, as they can provide errant information
B. Limited to key checks for efficiency
C. Left to developer discretion to enable efficient production
D. Predefined as part of the SDL
10. What are the major elements of code signing?
A. Encrypted source code
B. File integrity checks
C. Public key cryptography and hash functions
D. Controlled distribution channels such as SSL
11. Managing the versions and changes associated with all these individual pieces of a software project is referred to as:
A. Version control
B. Secure development process
C. Configuration management
D. Source code repository
12. Version control is best performed by:
A. A manual, structured process with checks
B. An automated, transparent process
C. Each developer taking responsibility
D. The project manager or lead developer to ensure consistency
13. The use of only approved libraries of functions enables:
A. Faster development
B. Use of lower skilled developers
C. Lower error rates from unknown issues
D. Cheaper development
14. Libraries of safe function calls are used to address the following issues except:
A. Stack overflow
B. XSS attacks
C. Buffer overflows
D. Injection attacks
15. Code reviews are performed using:
A. Static analysis tools
B. Dynamic analysis tools
C. Compilers with special flag options
D. Human examination of code
Answers
1. C. Code signing can provide no information as to the degree to which code is free of errors or defects.
2. B. Testing of code while executing in a production-like environment is referred to as dynamic code analysis.
3. A. Code signing can provide information as to source validity and integrity.
4. D. The /GS compiler switch enables stack overflow protection in the form of a cookie to be checked at the end of the function prior to the use of the return address.
5. B. Stack overflows are difficult to specifically detect and need to be coded for using compiler options.
6. D. Code analysis should be performed at all levels of development.
7. D. Static code analysis cannot test runtime issues such as thread performance, memory management, or race conditions.
8. B. Automated analysis has issues identifying clean, readable code. This is better done with code walkthroughs.
9. D. Compilers can provide a wide array of defensive efforts if properly employed, and should be a defined part of the SDL.
10. C. Code signing depends upon hash functions and public key cryptography.
11. A. The managing of the versions and changes of all the components of a project is referred to as version control.
12. B. Configuration management and version control operations are highly detailed operations, with lots of recordkeeping. Management of this level of detail is best done with an automated system that removes human error from the operational loop.
13. C. Unknown and untested libraries bring additional testing burdens to a project and introduce unknown risks.
14. A. Stack overflows are best protected by compiler options that enable stack canaries or cookies.
15. D. Code reviews involve the human examination of code in a manual presentation to the development team by the code author.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.