Key concepts in this chapter are:
Understanding where exceptions occur
Implementing exception handling
Determining what information to give when an exception occurs
No one is perfect. No matter how well organized, pre-prepared, and appropriately equipped a person is, things invariably, inevitably, and commonly go wrong. Put it down to lack of perfection, and make this the excuse for why we miss airplane flights, wear inappropriate clothes to social functions, and buy the wrong birthday presents for our spouses. Interestingly, we often expect others to be perfect. This illustrates the old saying, "We judge ourselves by our intentions and others by their actions." As with other areas of life, the users of computer software are not perfect. Some will enter wrong passwords, attempt to open badly formatted files, and unknowingly delete essential resources from the hard disk. If, after they do any or all of these things, your program doesn’t work as expected, users will blame the software. A term you’ll see throughout this chapter is grace. Just as people should gracefully accept life’s ups and downs, computer software should also handle unforeseen situations with grace.
As developers, we create our software in a friendly environment where everything is set up to work perfectly. However, users will ultimately run software in a less-than-perfect environment where anything can and will go wrong and flaws in your software will be exposed. From a security perspective, software flaws are not only an annoyance; they are vulnerabilities that can be exploited by an intruder to attack the software or the system it’s running on. Designing software to handle exceptions gracefully serves two purposes: it protects against attacks and makes for a more robust and satisfying user experience. Secure software is robust software. Chapter 7 discussed verifying user input and, where possible, preventing exceptions from happening. This chapter discusses what to do when an exception does occur. Unless handled correctly, exceptions cause application errors. Both divide by zero and file not found errors are examples of exceptions.
Exceptions can occur anywhere in code, but most commonly they show up when a situation occurs that the developer didn’t originally anticipate and that the program logic doesn’t handle with grace. Let’s look at the example of a user entering her user name and password into the employee management system logon form. The most common thing that can go wrong is the user entering an invalid user name and password. Another problem is when a user name contains characters that cause a SQL-injection attack, as seen in Chapter 7. Both problems can be handled by careful input validation, but there are still other potential problems that can cause an exception. If the database is located on a server, a network outage will cause the system to malfunction. If the database is located on the local machine, the user might delete the database or open it exclusively in another application. Obviously, you can’t protect against everything. An advanced alien civilization landing on earth with the intention of corrupting data in the employee management system will probably remain an unhandled exception. However, there are some common situations you should always design your applications to detect and gracefully handle:
Bad input. As discussed in Chapter 7, if the system doesn’t trap for unexpected input—such as a too-long-string or a number outside of the expected range—the input can cause an exception. This also applies to information that is passed from an external system—if you don’t have control over the incoming data, it might be corrupt. Does your application ensure that all incoming data is scrubbed? The best practice is to assume all input is invalid until proven otherwise.
Multiuser conflicts. When two users of the system try to open and lock the same file or write to the same record in a database, one or both of these actions will fail. Does your system detect for and recover from multiuser conflicts? A good practice is to look for the places where resources (for example, files, databases, ports, or hardware devices) are first opened or accessed, and write code to detect whether the resource is already in use.
Network outages. If a server is inoperable, a network cable is unplugged, or an Internet service is not available, an exception will be generated in your application. Will your application handle network outages gracefully? The important things to ensure are that a network outage does not corrupt data, does not lose details of a transaction, and the system gracefully recovers when it comes back online.
Corrupt or missing files. If a file is deleted, corrupt, or simply in a different format than expected, your application might produce unexpected results. Many things can cause the corruption of data, including installing an older version of the application that reads or writes files in a different format, or a user intentionally or unintentionally changing the contents of a resource file. Does your application perform input validation of files the same way that user input is validated?
Crashes. Similar to a network outage, if a client computer crashes in the middle of processing (for example, because of an electricity outage), will the client and any server components recover gracefully after the crash?
Stress. What happens if the machine the application is running becomes stressed and runs out of disk space or memory, or the processor becomes busy with another program? These are hard problems to detect because they can happen without warning. The best option is to test the application on a machine under stress and ensure the application behaves acceptably.
The reason these are security issues is because if an intruder finds that the application is vulnerable in any of these areas, he might cause one of these conditions to occur. For example, he might turn off the computer or network in the middle of credit card processing. Will this cause a state in which an intruder has ordered merchandise but the credit card is unbilled? You should ensure that the system handles this and each of the other situations with grace. Each of these situations are similar in that they refer to the application interfacing with an external resource or stimuli. This is where you should ensure that exceptions are detected and handled—where the system interfaces with the rest of the world. In security terms, your interface with the rest of the world is known as the attack surface. The best practice is to minimize the attack surface by reducing the number of places where input is taken from the user or external systems. Any input that is accepted should be validated, and exception checking should be placed around the relevant code.