Secure Programming HOWTO
PrevNext

Chapter 7. Design Your Program for Security

 

Like a city whose walls are broken down is a man who lacks self-control.

 Proverbs 25:28 (NIV)
Table of Contents
7.1. Follow Good Security Design Principles
7.2. Secure the Interface
7.3. Separate Data and Control
7.4. Minimize Privileges
7.4.1. Minimize the Privileges Granted
7.4.2. Minimize the Time the Privilege Can Be Used
7.4.3. Minimize the Time the Privilege is Active
7.4.4. Minimize the Modules Granted the Privilege
7.4.5. Consider Using FSUID To Limit Privileges
7.4.6. Consider Using Chroot to Minimize Available Files
7.4.7. Consider Minimizing the Accessible Data
7.4.8. Consider Minimizing the Resources Available
7.5. Minimize the Functionality of a Component
7.6. Avoid Creating Setuid/Setgid Scripts
7.7. Configure Safely and Use Safe Defaults
7.8. Load Initialization Values Safely
7.9. Minimize the Accessible Data
7.10. Fail Safe
7.11. Avoid Race Conditions
7.11.1. Sequencing (Non-Atomic) Problems
7.11.1.1. Atomic Actions in the Filesystem
7.11.1.2. Temporary Files
7.11.2. Locking
7.11.2.1. Using Files as Locks
7.11.2.2. Other Approaches to Locking
7.12. Trust Only Trustworthy Channels
7.13. Set up a Trusted Path
7.14. Use Internal Consistency-Checking Code
7.15. Self-limit Resources
7.16. Prevent Cross-Site (XSS) Malicious Content
7.16.1. Explanation of the Problem
7.16.2. Solutions to Cross-Site Malicious Content
7.16.2.1. Identifying Special Characters
7.16.2.2. Filtering
7.16.2.3. Encoding (Quoting)
7.17. Foil Semantic Attacks
7.18. Be Careful with Data Types
7.19. Avoid Algorithmic Complexity Attacks

Some program designs are relatively easy to secure; others are practically impossible. If you want a secure application, you’ll need to follow good security design principles. In particular, you should minimize the privileges your program (and its parts) have, so that the inevitable mistakes are much less likely to become security vulnerabilities.

PrevHomeNext
Other Languages Follow Good Security Design Principles