Securing Java code – Exceptions

Here’s a little tip to improve security of your software. One little issue that is often overlooked. It is pretty well known that you need to validate your inputs. It’s also clear that you need to be careful with your output, so to not expose any sensitive information. However, one area that is commonly ignored or not understood in the context of security is exceptions. I often heard people say we need to put more information in exceptions to make debugging problems easier. For example, when a FileNotFoundException occurs, put the file that hasn’t been found into the exception message or such. In the context of software security, you need to understand that exceptions are a common attack vector and one of the most valuable sources of information for the attacker. Feed bogus input into the application until it crashes with an exception, then analyze this exception to find useful information about the application or the system that it’s running on.

As an example, I recently wanted to order something in an online shop. For some reason, after entering my address, etc, and clicking submit, I was presented with an exception. It was a PHP exception, but that doesn’t really matter. The exception message gave me the following information:

  • The location of the PHP script that failed
  • The name and table where the script tried to insert data
  • The exact query that failed (e.g. insert into order (customer_name, ..) values (‘Roman Kennke’, …), essentially telling me the structure of that table
  • The name of the function that failed (pg_query … from which I can guess that it must be a PostgreSQL database)

From this point, crafting a little SQL injection shouldn’t be that difficult, for example, I could enter “Roman’,…); SELECT * FROM order; –“, if the input validation is as crappy as I expect, this would dump me the whole orders table.

Takeaway lesson: when you want to put some interesting information in an exception to make your debugging life easier, think really hard to restrict the amount of information as much as necessary and to not expose any information that could be used by an attacker. It might be just as useful to use a debugger. Ah and while I’m at it, don’t ever expose sensitive information like account  numbers or passwords or similar in exceptions. Exceptions are one of the most important windows into your application, at least from an attacker’s point of view.


2 Responses to Securing Java code – Exceptions

  1. cowwocGili says:

    My advice: local exceptions locally and return an opaque SERVER_ERROR to web clients (perhaps with a unique id to link the two together through logs).

  2. cowwocGili says:

    Err, I meant *log* exceptions locally 🙂

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: