aspose file tools*
The moose likes Security and the fly likes Web application security Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Security
Bookmark "Web application security" Watch "Web application security" New topic
Author

Web application security

Richard Golebiowski
Ranch Hand

Joined: May 05, 2010
Posts: 213

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
Marshal

Joined: Mar 22, 2005
Posts: 39548
    
  27
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.


Ping & DNS - updated with new look and Ping home screen widget
Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4637
    
    5

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
Ranch Hand

Joined: May 05, 2010
Posts: 213

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
Rancher

Joined: Aug 11, 2007
Posts: 4637
    
    5

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
Marshal

Joined: Mar 22, 2005
Posts: 39548
    
  27
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
Ranch Hand

Joined: May 05, 2010
Posts: 213

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
Rancher

Joined: Aug 11, 2007
Posts: 4637
    
    5

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
Greenhorn

Joined: Aug 04, 2011
Posts: 14
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
Greenhorn

Joined: Jun 26, 2012
Posts: 2
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
Ranch Hand

Joined: May 13, 2009
Posts: 158
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
Rancher

Joined: Aug 11, 2007
Posts: 4637
    
    5

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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Web application security
 
Similar Threads
policy tool
Application Security
Congratulations - Joe McGuire
Image display problem
Tomcat vs. Glassfish