From the course: Programming Foundations: Secure Coding

Error handling

From the course: Programming Foundations: Secure Coding

Start my 1-month free trial Buy for my team

Error handling

“

- Error handling is an important part of application development. It allows the developer to prevent the application from abnormal termination while also providing a great place for troubleshooting break points when issues do arise. But what makes it powerful for developers also makes it attractive for bad actors. One of the most frequent vulnerabilities comes from information disclosure through error messaging. In these vulnerabilities, the application raises an error that produces an error status. This error status usually results in a message like a 404 or a redirect in the web world. The vulnerability arises when that error message discloses information such as a stack trace or a database dump. This information can be very valuable for an attacker, trying to gain entry into your system. Even the disclosure of your internal error codes can be used to attack you. How you raise an error can provide an attack vector as well. One of the most common issues that I've seen in applications of every type is in user authentication flows. Often developers will provide different error messages if the user doesn't exist versus if they entered the wrong password. This level of disclosure can provide a bad actor a brute force vector into your system because you are confirming that a user exists. All of these situations are very easy to prevent, however. We must first accept that error conditions will always exist. We need them to exist in our applications for flow control and to protect us from crashing. The fix isn't to prevent the errors, it's to accept them and make conscious decisions about what information we display. In our invalid login case or a password reset case, the developer should only disclose that the situation exists, not which case we're in. The language should be consistent so a valid user can take appropriate action, but a bad actor won't be given too much information. It takes some time to get good at using consistent language, but often it's just a matter of taking the time to document those messages. Review the text and make sure that errors don't disclose internal system information. In the former case, trapping the error and returning a generic error page usually allows you to provide logging in the trap while displaying a generic error state to your users, again, preventing leaking of information. Code reviews and documentation can help a bunch in these cases. But an even better model is to actually test your error states. When you do so, you can provide guidance through the test about what text should be displayed and what shouldn't be. All too often developers focus only on the positive cases in their tests, and that leads to issues like information disclosure. So I highly recommend testing positive, negative, and error states. This can also be a great exercise to ensure your error messages are consistent, valuable, and don't disclose sensitive information.

Contents