Web application security

Hi all,

I am about to start work on a web application and one of our main concerns is database security. The web application will be hosted in a DMZ and separated from the database server by a firewall. It was also suggested to use RMI to give another layer of separation between the web server and database. Would using RMI help make the database more secure? What are the current best practices for web applications?

I think RMI would be overkill. Make sure the DB account used to by the web server is locked down to the minimum permissions. You could use stored procs only, thereby disallowing that account the rights to execute raw (and arbitrary) SELECT statements.

Some good starting points are here: http://www.coderanch.com/how-to/java/SecurityFaq#web-apps.

No RMI brings nothing to the table here. Actually, RMI rarely brings anything useful to Java programs, but that is a separate topic.

Just use the usual JDBC connection. If you want, you can use a different port than the usual 3306, or whatever your RDBMS wants. Its only security through obscurity, but it can help a bit against a non-skilled hacker.

A fundamental question that you need to address relate to:

What do you mean by security?
What threat are you protecting against?
What is the engineering tradeoff you have made for development hassle, testing problems, operational issues, and hard dollar costs against each of the threats that you are trying to protected against?

What we need to protect is some extremely sensitive data that we will have in the database. The kind of data where we don't mind taking every and any step needed to safeguard the access to it. It seems like eliminating the direct connection from the web server to the database by using RMI would provide an additional layer of protection on top of whatever else we will be doing such as encryption. As was stated in the previous reply, one of the things we can do is change the port number the database uses. Wouldn't using RMI be better then that since it will remove any direct communication to the database?

Richard Golebiowski wrote: Wouldn't using RMI be better then that since it will remove any direct communication to the database?

Again, why do you think RMI brings anything to the table? I have very specific problems with RMI, there are many other ways to send messages between servers that don't suffer from RMI's problems.

You could, if you insisted, invent your own equivalent to JDBC, have your client code use this to talk to a daemon on the DBMS server machine, and then it could translate to JDBC. Its possible. Its possible using RMI or many other protocols. I just don't see that it adds real security, and it adds a lot of engineering effort.

Your statement "don't mind taking every and any step needed" is simply too vague to allow engineering decisions to be made.

Richard Golebiowski wrote:Wouldn't using RMI be better then that since it will remove any direct communication to the database?

How would it do that? There'd still be a direct connection between the two servers, and RMI adds no security features to that. I agree with Pat that you should define what attacks you're trying to guard against before you rush into anything.

What we are trying to protect against is the worst case scenario where the web server is hacked and is totally compromised and someone now has access to that server. If you are using JDBC then you have a port open between the web server and the database sever that could be used to query the database directly. If you set up the access between the web server and the database server where you do not use JDBC and instead use something else (does not have to be RMI) where the only way the web server could receive data from the database server is by sending requests to a application on the database server instead of to the database directly then the database cannot get queried directly from the web server if the web server gets hacked.

Richard Golebiowski wrote:What we are trying to protect against is the worst case scenario where the web server is hacked and is totally compromised and someone now has access to that server.

If that is your real concern, you are worrying about the wrong thing.

First, don't let someone totally compromise your front end server. Period.

This reminds me of a consulting gig I had with a US Federal Agency. They wanted to engineer for the worse case, which for them was a Russian nuclear exchange that vaporized Washington DC. I responded that if that happened, their time and attendance tracking system was not really going to be a priority for the US Government.

If someone has root access to the public server and has totally compromised it, do you think a bit of security by obscurity is really going to solve your major problems?

What you could do is try to separate the security relevant parts of the running code and possibly the database itself. Make the target as small and well managed as possible. Make sure you manage those serivces well (e.g. software updates if security issues are found in any of the server applications).

Then you might want to think about encrypting the info in the database (e.g. public key in the front end, private key in the backoffice) - so that database compromise does not automatically lead to loss of confidentiality of the data. This is complex and should only be attempted after all the other security "holes" have been plugged.

Note: I'm a security professional, but this is only a fast reply on your question, there are many other things to consider as well.