Although many people don’t consider code maintenance to be design work, our experience is that the way maintenance is carried out can make or break the security of a design. Similar to retrofitting security enhancements onto existing software, maintaining code should be handled with due care, again applying the same level of design scrutiny and attention that you would to new code.

Opportunities for missteps abound. Here are some more common mistakes we generally do:

- Race conditions introduced because a maintainer decided to store intermediate results in a temporary file in a world-writeable directory.

- Database passwords hard-coded into a program (opening it to sniffer and memory-analysis attacks) during maintenance, because it seemed “too risky” to code up an encrypted, protocol-based authentication exchange.

- Resource exhaustion attacks suddenly facilitated by the introduction of a large new cluster of data in memory.

How can you avoid such mistakes? We know of only one method, and that is to treat it as a (possibly) miniature software development effort and follow these steps:

1. Do your best to understand the security model and measures that are in place already.

2. Take the time to learn how the program you are maintaining actually works. Track its operation with profiling software. Find out what files it opens, how much memory it uses, and how it handles errors.

3. Armed with that knowledge, proceed carefully as best you can along the lines of the original designer’s intent.

This approach can be quite useful in another context, too. Suppose you have been charged with folding existing library code or third-party packages into your application. It’s a good idea to find out how that software actually works. Remember: setting aside the mentality and assumptions of a program’s users is an important step in design.

Similarly, here are two key errors that we would recommend taking great care to avoid:

Don’t violate the spirit of the design

Unfortunately, this is easy to do. For example, many security issues we’ve observed in web software have arisen because web authors have grafted mechanisms that require the keeping of “state” information onto a stateless design.

Don’t introduce a new trust relationship

Another mistake that we have often seen is to compromise security by introducing, during maintenance, a new trust relationship. For example, suppose that you are working in Unix and need to execute a system-related function, such as setting the access permissions on a file. Sure, you can look up the arguments and return codes for the chmod library call, but you’d find it a lot easier just to spawn the program itself or maybe use a command shell. Taking this route, however, now means that your program has to “trust” the spawned program as well. You may have introduced a new implementation-time, design-level risk that the original designers never contemplated.

Related Ipad Games Articles