The end of a matter is better than its beginning, and patience is better than pride. | |
| Ecclesiastes 7:8 (NIV) |
Designing and implementing a truly secure program is actually a difficult task. The difficulty is that a truly secure program must respond appropriately to all possible inputs and environments controlled by a potentially hostile user. Developers of secure programs must deeply understand their platform, seek and use guidelines (such as these), and then use assurance processes (such as inspections and other peer review techniques) to reduce their programs’ vulnerabilities.
In conclusion, here are some of the key guidelines in this book:
Validate all your inputs, including command line inputs, environment variables, CGI inputs, and so on. Don’t just reject “bad” input; define what is an “acceptable” input and reject anything that doesn’t match.
Avoid buffer overflow. Make sure that long inputs (and long intermediate data values) can’t be used to take over your program. This is the primary programmatic error at this time.
Structure program internals. Secure the interface, minimize privileges, make the initial configuration and defaults safe, and fail safe. Avoid race conditions (e.g., by safely opening any files in a shared directory like /tmp). Trust only trustworthy channels (e.g., most servers must not trust their clients for security checks or other sensitive data such as an item’s price in a purchase).
Carefully call out to other resources. Limit their values to valid values (in particular be concerned about metacharacters), and check all system call return values.
Reply information judiciously. In particular, minimize feedback, and handle full or unresponsive output to an untrusted user.