Oracle database firewall

In a recent blogpost I touched the subject of deep application boundary validation and made a statement about the fact that when you implement deep application boundary validation you should not only look at the software created on an application level, you should also look at a database level and make sure that all functions, stored procedures etc etc are equipped with a boundary validation part. In essence this comes down to the fact that every package or function should hold code to validate the incoming data. Incoming data is commonly parameters used to call the code however can also be the values coming from a return set from a select statement. When implementing boundary validation you should think of everything coming into your code as data (parameter, return sets...) are coming from an unused source and are in need of  heckling if it is valid.

The example I used in the previous blogpost was that of a web application. Another good way to strengthen the security of your application and to protect your database is to implement an Oracle database firewall. One of the interesting features of the Oracle database firewall is the option for white-listing.

What white-listing is essence is doing is creating a list of SQL statements which you consider to be safe and which can be executed from the application tier on the database tier. for example if you have build an application to track shipments this application will hold a certain number of queries that can be executed against the database (all with different values, for example the tracking number). Those queries are considered safe and can be placed on the whitelist.

When a query is executed by the application server and send to the Oracle database the database firewall will. Check the query against the whitelist. If the query is on the whitelist it will allow the query to pass to the database server to be executed, in case the query is not on the whitelist the database firewall will drop the query and it will not be send to the database server.

Implementing a oracle database firewall will help you protect against, for example, SQL injection attacks against your application server. When an attacker finds a way to insert additional SQL code into your application via the GUI the statement will never reach the database server, the statement will be dropped by the Oracle database firewall.

Secondly it will protect you against attacks which make use of stolen credentials from the application server or a compromised application server. Your application server will need login credentials to your database server to be able to communicate. In case someone is able to steal the login credentials from the application server they would be able to connect to the database and start freely querying the data. When you have a Oracle database firewall in place all statements that are not on the whitelist will be dropped and by doing so the attacker having the database login credentials from your application server be very limited in his attempt to exploit this.

There are however some more nice features about the Oracle database firewall. We have just stated you can drop (block) a statement to be send to the database however there are some more options you can do. You will have the allow options and the block options, however you also have; log, alert and substitute.

Log is quite straight forward, a log entry will be made stated a certain statement has been send and executed. This can be handy in case you do want certain actions to be logged for example in cases where you have to be able to trace certain things or you have to be compliant with a certain legal or internal rule.

Alert will send a alert directly to a system, this is handy in case you are tracking a certain behaviour or when you any other need for alerting where we will not go into at this moment in this post.

Specially interesting is the substitute, substitute will allow you to catch a certain statement and rewrite it with another. This can be for example if you catch a certain attack characteristic and you do not want to block the attacker however you want to feed him with incorrect information or in some cases this can be handy to trick packaged software to which you do not have the source code to interact in a different way with your database. This can also be used (however not promoted) to port a application written for one database version (or vendor) to another.