When a Square is not a Rectangle!

Or how the Liskov Substitution Principle extends basic substitutability

The square vs. rectangle problem is a frequently used example of a class inheritance problem found throughout object-oriented programming. If you are not familiar with the problem, it addresses the issue of deriving a square shape from a rectangle. Mathematically a square is a rectangle. On the surface, modeling that relationship in OOP is simple, but when you drill down it gets a lot more complicated.

The Right Tool for Every Job

My grandfather was a carpenter from the old world. He, and then my father taught me some carpentry when I was a youngster. They always told me to use the "right tool for the job." About once a year, maybe more, I catch an article in IEEE Computer or the Communications of the ACM by some college professor telling me that object-oriented programming is a bad approach to software development. First I have a "huh?" moment. Then I think about using a bigger hammer, because clearly that is the best tool for every job!

Seriously, I learned a long time ago in school that the computer vendors like Digital Equipment Corporation were practically giving away their equipment to universities. Why? Because when students learn to use their computers in school, then after they leave they push for their employers to use the same systems too. When you have a favorite tool you want to use it everywhere. It's the old adage: "when your favorite tool is a hammer, every problem looks like a nail!"

Protect the Melon, er, the Database!

Little Bobby Tables comic used with permission from xkcd.com.

In the related article Encrypting JDBC Connection Strings I explored one technique to externalize an encrypted username, password, and connection string. Here I want to explore some advanced methods to protect the data source, starting SQL injection attacks and moving forward.

SQL Injection Attacks

Consider the following Groovy&Grails example (it's a lot like Java), where the user is prompted for a student id and an SQL statement is constructed to retrieve that row from the students table. In Grails the form fields arrive at the method as a map of name=value pairs, and Groovy has cool parameter-substitution in strings. It is pretty clear how the student ID ends up in the SQL string:

Encrypting JDBC Connection Strings

Authentication between an public-facing web application and a data source is always difficult because of the possibility that the information may be compromised at the application server. There are two primary approaches: simple user names and passwords or RSA public-private keys to identify the application. We are interested in the first case because it is commonly used.

Our assumption is that the application server has already been breached, so what can we do to protect the data servers behind the application? We need to use a defense-in-depth approach: multiple layers of security using different technologies frustrates attackers: that forces them to have exploits to circumvent every device used.

Defense-in-depth of the data includes protecting the database from SQL injection attacks and limiting access to the database from a small set of computers. These defenses are discussed in other posts, our immediate focus is on protecting the credentials for authentication.