Web application security

[Richard Golebiowski]

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?

[Ulf Dittmer]

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: https://coderanch.com/how-to/java/SecurityFaq#web-apps.

[Pat Farrell]

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?

[Richard Golebiowski]

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?

[Pat Farrell]

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.

[Ulf Dittmer]

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.

[Richard Golebiowski]

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.

[Pat Farrell]

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?

[Maarten Bodewes]

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.

[albert stephen]

The Web Application Security Consortium (WASC) is 501c3 non profit made up of an international group of experts, industry practitioners, and organizational representatives who produce open source and widely agreed upon best-practice security standards for the World Wide Web.

http://www.labortimetracker.com/roadmap.cfm

[paul nisset]

I realize this thread is from some time ago but in case anybody comes across it this is my two bits.
In this situation ,look into encrypting your database and pass data back and forth to the web app via ssl.
It will be slow but at least if your case scenario happens the data should still be encrypted by the time the hacker gets to it.

[Pat Farrell]

paul nisset wrote:In this situation ,look into encrypting your database and pass data back and forth to the web app via ssl.
It will be slow but at least if your case scenario happens the data should still be encrypted by the time the hacker gets to it.

Actually, for most DBMS access, the overhead of encryption is lost in the time taken to do a three way join. Many DBMS packages offer link
encryption, its easy to turn on.

The more serious problem with this approach is that the client/front-end server must have the key to the cipher used to talk
to the back end. Where do you keep this key?

If you keep it in a file on the front-end server, then the bad guy can read the file and know the key. Boom, your protection is gone.
If you keep it in the Java code, the bad guy can read the JAR file and get the key. Boom again.
If you make an operator type it in each time the web server/application starts, someone will be very grumpy
when they have to get up at 3AM to enter the key.