Where Exceptions Occur

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.